wrong reverse dns answer, corrupted cache

[Kevin Darcy]

"Jeremy C. Reed" wrote:

> I noticed that the reverse (in-addr.arpa) mapping of an IP didn't
> always work.
>
> dig -x 209.102.25.210
>
> This usually reported SERVFAIL. (I tried from different name servers
> running different versions of BIND on different networks.)
>
> But it appeared to be set up properly:
>
> The root-servers point to arin.net's servers. Then arin.net's
> servers point to Savvis.net's two nameservers. (I checked all of
> arin's servers.)
>
> Then both of these two savvis.net server's point to the ISP's two servers.
> And they both have a PTR record for the IP.
>
> Then I use dnstrace and saw:
>
>  dnstrace -c 210.25.102.209.in-addr.arpa
>  Tracing to 210.25.102.209.in-addr.arpa via 127.0.0.1, timeout 15 seconds
>  127.0.0.1 (127.0.0.1)
>   |\___ ipdns2.hinet.net (168.95.1.14)
>    \___ ipdns1.hinet.net (168.95.192.14)
>
> I learn from reading numerous news.admin.net-abuse.email and
> comp.protocols.dns.bind newsgroup postings that hinet.net causes some
> cache problems. Can someone explain this? (How can hinet.net cause
> this problem for so many nameservers?)

hinet.net is claiming to be authoritative for in-addr.arpa. This would be
kind of like me claiming to be the U.S. Postal Service. Some gullible people
may give me their outgoing snail mail, instead of sending it through
legitimate channels. Similarly, when hinet.net claims to be authoritative for
in-addr.arpa, some gullible nameservers may believe it and start sending
their in-addr.arpa queries there.

> I understand that I could use the named server statement with bogus
> to fix the problem for my own nameservers. But what about other
> servers?

Modern versions of BIND tend to be immune from this form of cache poisoning
because they keep good track of "credibility" and won't overwrite data of
high credibility (e.g. the delegation from arpa to in-addr.arpa) with data of
low credibility (e.g. hinet.net's outrageous claims of in-addr.arpa
authoritativeness). However, older versions of BIND, and non-BIND nameserver
software, may still get poisoned.

> Also, what dns tools can I use that recursively show each server
> asked plus the queries and responses? (Before I used dnstrace, I
> couldn't figure out why I couldn't get the PTR record for the IP.)

You could use a generic tool like "dig", but -- in older versions at least --
you'd have to run it multiple times in order to trace the entire delegation
path. The BIND 9 version of dig has a "trace" option, but I haven't played
much with it...


- Kevin