Incorrect DNSBL evaluation - SpamAssassin

This is a discussion on Incorrect DNSBL evaluation - SpamAssassin ; Karsten Bräckelmann wrote: > On Mon, 2008-07-21 at 23:17 +0200, Matthias Leisi wrote: > >> Yves Goergen schrieb: >> > > >>> What do you mean? My mail server uses the DNS servers of the computing >>> centre. What SpamAssassin ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 39 of 39

Thread: Incorrect DNSBL evaluation

  1. Re: Re: Incorrect DNSBL evaluation

    Karsten Bräckelmann wrote:
    > On Mon, 2008-07-21 at 23:17 +0200, Matthias Leisi wrote:
    >
    >> Yves Goergen schrieb:
    >>

    >
    >
    >>> What do you mean? My mail server uses the DNS servers of the computing
    >>> centre. What SpamAssassin does, I don't know. The IP addresses are:
    >>>

    >
    > The same as everyone else... Sic.
    >
    >
    >>> # cat /etc/resolv.conf
    >>> nameserver 213.133.100.100
    >>> nameserver 213.133.99.99
    >>> nameserver 213.133.98.98
    >>> nameserver 213.133.98.97
    >>>

    >> Ah, Hetzner. I had a lot less problems since I started to run my own:
    >>
    >> main:~> cat /etc/resolv.conf
    >> nameserver 127.0.0.1
    >>

    >
    > Every Hetzner customer using the same DNS by default? Yeah, that indeed
    > looks like these DNS servers are being blocked by the BL operators (see
    > my previous post). Most likely not only URIBL, but every major BL out
    > there...
    >


    I have looked, and there are no ACLs on 213.133.0.0/16 whatsoever, so
    its not coming from the uribl mirror side.

    Could those DNS servers be monetizers? Have you (Yves) even tried manual
    lookups to see how the ISP DNS server is responding? Do this and report
    your results..

    $ dig @213.133.100.100 unclassified.de.multi.uribl.com A

    Those NS IPs are not reachable from here, so I cant test to see how they
    respond.

    --
    Dallas Engelken
    dallase@uribl.com
    http://uribl.com


  2. Re: Incorrect DNSBL evaluation

    On 22.07.2008 06:28 CE(S)T, Dallas Engelken wrote:
    >> Every Hetzner customer using the same DNS by default? Yeah, that indeed
    >> looks like these DNS servers are being blocked by the BL operators (see
    >> my previous post). Most likely not only URIBL, but every major BL out
    >> there...


    No, there are those NS addresses and I guess many customers have turned
    them around in the past as there were problems with the DNS servers'
    reliability. They seem to be solved for some time.

    > I have looked, and there are no ACLs on 213.133.0.0/16 whatsoever, so
    > its not coming from the uribl mirror side.
    >
    > Could those DNS servers be monetizers? Have you (Yves) even tried manual
    > lookups to see how the ISP DNS server is responding? Do this and report
    > your results..
    >
    > $ dig @213.133.100.100 unclassified.de.multi.uribl.com A


    ; <<>> DiG 9.2.4 <<>> @213.133.100.100 unclassified.de.multi.uribl.com A
    ;; global options: printcmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 57701
    ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

    ;; QUESTION SECTION:
    ;unclassified.de.multi.uribl.com. IN A

    ;; Query time: 149 msec
    ;; SERVER: 213.133.100.100#53(213.133.100.100)
    ;; WHEN: Tue Jul 22 19:53:07 2008
    ;; MSG SIZE rcvd: 49

    I don't know what this output means, as it looks all like commented out.
    Does it say anything at all?

    --
    Yves Goergen "LonelyPixel"
    Visit my web laboratory at http://beta.unclassified.de


  3. Re: Incorrect DNSBL evaluation

    On 21.07.2008 23:36 CE(S)T, Karsten Bräckelmann wrote:
    > OK, I told you to check previously received mail for the same broken
    > URIBL hit pattern. So you could just have a look at the X-Spam headers
    > using your MUA. Probably the easiest method anyway, just to spot a few
    > other mails showing the same pattern.


    I found out that I can search for messages containing a certain term in
    a certain mail header, connected with AND, in Thunderbird. So did I. And
    I found 13 messages with all three matches for several unrelated domains
    (ebay.de is among them, in ham) since 2008-07-01.

    What does that tell us? It's broken for 3 weeks now and it doesn't come
    from my domain.

    --
    Yves Goergen "LonelyPixel"
    Visit my web laboratory at http://beta.unclassified.de


  4. Re: Incorrect DNSBL evaluation

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1


    Yves Goergen schrieb:

    |> $ dig @213.133.100.100 unclassified.de.multi.uribl.com A
    |
    | ; <<>> DiG 9.2.4 <<>> @213.133.100.100 unclassified.de.multi.uribl.com A
    | ;; global options: printcmd
    | ;; Got answer:
    | ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 57701

    The status "NXDOMAIN" says that the name does not exist.

    | ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

    This says: 1 Query section (this is normal -- that's what you asked
    for), but neither an answer was returned, nor an authoritative section
    (which would redirect to another nameserver under specific
    circumstances), nor an additional section (with eg IP addresses for
    names returned in the answer section) have been returned.

    The dig output (or host -d) then lists all the section, here only the
    QUESTION section:

    | ;; QUESTION SECTION:
    | ;unclassified.de.multi.uribl.com. IN A

    The last part is the stats of the request (who did you ask, how long did
    it take, ...).

    | ;; Query time: 149 msec
    | ;; SERVER: 213.133.100.100#53(213.133.100.100)
    | ;; WHEN: Tue Jul 22 19:53:07 2008
    | ;; MSG SIZE rcvd: 49

    - -- Matthias
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (Darwin)

    iD8DBQFIhiG7xbHw2nyi/okRAsseAKCKWfOHDQhJT2MjJWhwuyDqAfyowwCbBUTr
    +M3d3VgC2qo0Xi/6MUuQ2XU=
    =buCV
    -----END PGP SIGNATURE-----


  5. Re: Incorrect DNSBL evaluation

    Thank you for the explanation of the output.

    Basically it says the same as the host command before, if I understand
    this right, and doesn't explain the observed SA behaviour.

    --
    Yves Goergen "LonelyPixel"
    Visit my web laboratory at http://beta.unclassified.de


  6. Re: Incorrect DNSBL evaluation

    On 23.07.2008 10:03 CE(S)T, Dirk Bonengel wrote:
    > Just a thought, but could you install a local nameserver (bind9) to act
    > as a caching nameserver?
    > AFAIK, at least in Debian you just need to 'apt-get install' bind.
    > Default config is OK


    This is Debian 3.1, it's pretty likely to be out of date. I'm currently
    in the process of preparing the upgrade, but it will take some time.

    --
    Yves Goergen "LonelyPixel"
    Visit my web laboratory at http://beta.unclassified.de


  7. Re: Incorrect DNSBL evaluation

    From: "Yves Goergen"
    Sent: Wednesday, 2008, July 23 09:05


    > On 23.07.2008 10:03 CE(S)T, Dirk Bonengel wrote:
    >> Just a thought, but could you install a local nameserver (bind9) to act
    >> as a caching nameserver?
    >> AFAIK, at least in Debian you just need to 'apt-get install' bind.
    >> Default config is OK

    >
    > This is Debian 3.1, it's pretty likely to be out of date. I'm currently
    > in the process of preparing the upgrade, but it will take some time.


    Since you are experiencing a DNS problem and there is an exploit
    for the Kaminsky DNS bug that was fixed in a massive multi-vendor
    roll out, are you patched or are you sure you are not getting your
    DNS spoofed?

    {^_^}


  8. Re: Incorrect DNSBL evaluation

    On 23.07.2008 19:28 CE(S)T, jdow wrote:
    > Since you are experiencing a DNS problem and there is an exploit
    > for the Kaminsky DNS bug that was fixed in a massive multi-vendor
    > roll out, are you patched or are you sure you are not getting your
    > DNS spoofed?


    I'm not running a DNS server.

    --
    Yves Goergen "LonelyPixel"
    Visit my web laboratory at http://beta.unclassified.de


  9. Re: Incorrect DNSBL evaluation

    From: "Yves Goergen"
    Sent: Wednesday, 2008, July 23 15:24


    > On 23.07.2008 19:28 CE(S)T, jdow wrote:
    >> Since you are experiencing a DNS problem and there is an exploit
    >> for the Kaminsky DNS bug that was fixed in a massive multi-vendor
    >> roll out, are you patched or are you sure you are not getting your
    >> DNS spoofed?

    >
    > I'm not running a DNS server.


    That begs the question, "Do you know if the DNS server you are using
    is properly patched?"

    (And if you're running an "'ix" operating system - why aren't you running a
    DNS server. That's one of the first "hairy chested 'ix things" I ever
    learned
    back in the very early SVR4 era - on an Amiga running UNIX. And, no, it
    didn't grow hair on my chest. I'm hormonally challenged for that feature.)

    {^_-} Joanne


  10. Re: Incorrect DNSBL evaluation

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1


    jdow schrieb:

    | (And if you're running an "'ix" operating system - why aren't you
    running a
    | DNS server. That's one of the first "hairy chested 'ix things" I ever

    Since operating a sizeable DNS infrastructure, I came to prefer to
    people using a shared/common/ISP-provided nameserver.

    Since many mailservers will query the same DNS-related information (eg
    DNSxL lookups on widely-used mailservers like eg from Yahoo, or from the
    same botnets), traffic savings through caching are _considerable_.

    - -- Matthias

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (Darwin)

    iD8DBQFIiBmjxbHw2nyi/okRAomOAJ97E48sV5mHupP7DVZ2Oni5DmX2rACff/Kr
    Zcv1FEUIoO4KYSEXhNhM8TM=
    =f3iY
    -----END PGP SIGNATURE-----


  11. Re: Incorrect DNSBL evaluation

    Matthias Leisi wrote:
    >
    > jdow schrieb:
    >
    > | (And if you're running an "'ix" operating system - why aren't you
    > running a
    > | DNS server. That's one of the first "hairy chested 'ix things" I ever
    >
    > Since operating a sizeable DNS infrastructure, I came to prefer to
    > people using a shared/common/ISP-provided nameserver.
    >
    > Since many mailservers will query the same DNS-related information (eg
    > DNSxL lookups on widely-used mailservers like eg from Yahoo, or from the
    > same botnets), traffic savings through caching are _considerable_.


    True, but you can also run a caching DNS server that forwards to your
    ISP one and gain a double-benefit traffic wise. You're still using your
    ISP's servers and their cach, but you're also caching locally.


  12. Re: Incorrect DNSBL evaluation

    On 24.07.2008 08:32 CE(S)T, Matt Kettler wrote:
    > Matthias Leisi wrote:
    >> Since many mailservers will query the same DNS-related information (eg
    >> DNSxL lookups on widely-used mailservers like eg from Yahoo, or from the
    >> same botnets), traffic savings through caching are _considerable_.

    >
    > True, but you can also run a caching DNS server that forwards to your
    > ISP one and gain a double-benefit traffic wise. You're still using your
    > ISP's servers and their cach, but you're also caching locally.


    I see no use in that. Maybe in times when there's trouble with the ISP's
    servers, but it's rarely the case. And if, I know some other DNS servers
    to set in the configuration for awhile.

    I'm forwarding this issue to the Hetzner support team now. It seems that
    some other customers have the same problem.

    --
    Yves Goergen "LonelyPixel"
    Visit my web laboratory at http://beta.unclassified.de


  13. Re: Incorrect DNSBL evaluation

    On Thursday 24 July 2008 22:33:25 Yves Goergen wrote:

    > I'm forwarding this issue to the Hetzner support team now. It seems that
    > some other customers have the same problem.


    hetzner dns is broken since forver. as well as their dhcp and their swicthes
    and.... don't get me started. just don't use it.


    --
    mit freundlichen Grüßen / best regards
    Arvid Ephraim Picciani


  14. Re: Incorrect DNSBL evaluation

    Yves Goergen wrote:
    > On 24.07.2008 08:32 CE(S)T, Matt Kettler wrote:
    >> Matthias Leisi wrote:
    >>> Since many mailservers will query the same DNS-related information (eg
    >>> DNSxL lookups on widely-used mailservers like eg from Yahoo, or from
    >>> the
    >>> same botnets), traffic savings through caching are _considerable_.

    >>
    >> True, but you can also run a caching DNS server that forwards to your
    >> ISP one and gain a double-benefit traffic wise. You're still using
    >> your ISP's servers and their cach, but you're also caching locally.

    >
    > I see no use in that.

    Actually, you really should. Using a local cache has the exact same
    benefits as using the ISPs nameservers, and it all boils down to
    bandwidth and latency. The local cache saves bandwidth on your local
    link, while the ISP nameserver saves bandwidth on the ISP's peering
    links. Using both together via a caching forwarder nets both benefits.

    Of course, it wouldn't fix your problem here, because a forwarder is
    still almost completely dependent on the ISP nameserver it forwards to.
    However, it's still very worthwhile as it lowers local bandwidth usage.
    They're also trivial to administer since they merely forward everything
    to the ISP and cache the results.

    This kind of localized caching is particularly helpful in SpamAssassin
    situations, where there's no real effort inside SA to cache DNS results
    from message to message. It would be silly to do so, as you'd
    essentially be writing an application-specific caching forwarder, when
    such tools already exist and can be used system wide. With no local
    cache, if 3 different messages get sent from the same IP, that IP gets
    checked against all the RBLs 3 times, once per message.
    ..

    > Maybe in times when there's trouble with the ISP's servers, but it's
    > rarely the case.

    Actually, a local caching forwarder wouldn't help you much if the ISPs
    servers were down. I'm sorry if you got the implication that this could
    fix your DNS problems.. I was merely pointing it out as a performance
    tweak you should look into.
    > And if, I know some other DNS servers to set in the configuration for
    > awhile.

    Which you'd still have to do with a local forwarder anyway.
    >
    > I'm forwarding this issue to the Hetzner support team now. It seems
    > that some other customers have the same problem.
    >

    Aye, you might also want to directly ask them if they're taking over
    NXDOMAIN responses and redirecting them to a search page. Verizon in the
    USA does this, and it causes bogus DNSBL results all the time.


  15. Re: Incorrect DNSBL evaluation

    On 20.07.2008 16:18 CE(S)T, Yet Another Ninja wrote:
    > This could be a DNS problem returning a .2 (positive response) for all
    > queries.


    I have done some further tests and it seems that one of the four
    nameservers (the .100.100) sometimes returns NXDOMAIN and sometimes
    127.0.0.255, which obviously is bogus because URIBL says on their
    website that they only return .14 or the single bits of it. The fact
    that it only returned .255 sometimes (not always) could explain that so
    few of my incoming e-mails had this rule matched. I didn't count them
    but I feel like I received more than 13 messages in three weeks
    (excluding mailing lists) that contained URIs and thus have been put
    through the URIBL rules.

    The other three nameservers didn't show this misbehaviour in a few short
    tests. So I moved the .100.100 to the end of resolv.conf and enabled the
    rules in SpamAssassin again. Let's see what will happen.

    --
    Yves Goergen "LonelyPixel"
    Visit my web laboratory at http://beta.unclassified.de


  16. Re: Incorrect DNSBL evaluation

    Matthias Leisi wrote:
    >
    > jdow schrieb:
    >
    > | (And if you're running an "'ix" operating system - why aren't you
    > running a
    > | DNS server. That's one of the first "hairy chested 'ix things" I ever
    >
    > Since operating a sizeable DNS infrastructure, I came to prefer to
    > people using a shared/common/ISP-provided nameserver.
    >


    you can still use a local caching dns (like a proxy). while this adds a
    piece of software, it also brings some valuable advantages.

    > Since many mailservers will query the same DNS-related information (eg
    > DNSxL lookups on widely-used mailservers like eg from Yahoo, or from the
    > same botnets), traffic savings through caching are _considerable_.
    >


    If you're happy with that, we're happy for you

    if you have a reliable DNS service, it's good for you. but if you are
    not sure it is protected enough (if it gets poisoned, you are poisoned
    too. and it gets easier to DDoS the whole network, ...). and there are
    other problems, as this thread shows.

    BTW. do we have numbers on how many ISPs did update their bind
    implementations (or have "safe" workarounds) after the recent bug
    disclosure?


  17. Re: Incorrect DNSBL evaluation

    On 25.07.2008 21:43 CE(S)T, mouss wrote:
    > BTW. do we have numbers on how many ISPs did update their bind
    > implementations (or have "safe" workarounds) after the recent bug
    > disclosure?


    According to a Heise.de article, in Austria 2/3 of all ISPs did not yet
    patch their recursive DNS servers. In US/CA, the major ISPs AT&T, BT,
    Time Warner and Bell Canada also haven't upgraded yet. Kaminsky said,
    according to his tests, 52% are vulnerable. Doesn't seem like the
    industry is taking this very serious.

    Source:
    http://www.heise.de/newsticker/Erste...meldung/113366

    --
    Yves Goergen "LonelyPixel"
    Visit my web laboratory at http://beta.unclassified.de


  18. Re: Incorrect DNSBL evaluation

    From: "Yves Goergen"
    Sent: Friday, 2008, July 25 13:39


    > On 25.07.2008 21:43 CE(S)T, mouss wrote:
    >> BTW. do we have numbers on how many ISPs did update their bind
    >> implementations (or have "safe" workarounds) after the recent bug
    >> disclosure?

    >
    > According to a Heise.de article, in Austria 2/3 of all ISPs did not yet
    > patch their recursive DNS servers. In US/CA, the major ISPs AT&T, BT,
    > Time Warner and Bell Canada also haven't upgraded yet. Kaminsky said,
    > according to his tests, 52% are vulnerable. Doesn't seem like the
    > industry is taking this very serious.


    They might when the first new victim of this spoofing attack sues their ISP
    for not updating their DNS servers.

    {^_^}


  19. Re: Incorrect DNSBL evaluation

    On 24.07.2008 22:33 CE(S)T, Yves Goergen wrote:
    > I'm forwarding this issue to the Hetzner support team now. It seems that
    > some other customers have the same problem.


    I had to keep telling them that it's their fault or at least not mine,
    they finally confirmed me that one node in their load-balanced system
    was returning .255 for the hostname in question. They have now disabled
    it so that the nameserver .100 with the observed behaviour should now
    work correctly again.

    --
    Yves Goergen "LonelyPixel"
    Visit my web laboratory at http://beta.unclassified.de


+ Reply to Thread
Page 2 of 2 FirstFirst 1 2