DNS Tracing

[Kevin Darcy]

BIND doesn't really have a tracing tool like that (although I understand
that the "dnscache" package from Dan Bernstein does have such a tool).
With BIND, the "trace" options are basically: 1) turn on named's debugging
and interpret the output, or 2) do some queries using a command-line tool
like "dig" and inspect the output. I just did (2), and everything looks to
be in order: all 3 nameservers for the zone give the correct answer, the
NS records appear to be correct.

My guess is that there is some record out there in the Internet DNS, e.g.
a CNAME, MX, NS or PTR, pointing to ecs1.altamente.com, in some other
domain which is hosted by a machine which *used* to be a slave for
altamente.com. If your server happens to query that server for the record,
the other server may "helpfully" return the stale A record for
ecs1.altamente.com in the Additional Section of the response, which could
enter your cache if you didn't happen to already have a more-credible
entry for the name in your cache at the time.

If this guess alone isn't enough to identify the culprit, you may consider
turning on the "host-statistics" global option. This causes significant
memory consumption, but once you get the bad record in your cache, you
should be able to dump the database, and then the source of the bad record
should be in the dump.

A workaround would be to make your nameserver a slave for the
altamente.com zone, which would prevent cache pollution.


- Kevin

wallp at earthlink.net wrote:

> Are there any good tools out there that will tell me where a record is
> coming from and what path it is following to get that record?
>
> problem I am having is if I do a standard lookup for ecs1.altamente.com
> I am supposed to get back 209.12.244.241, but alot of times I get
> 209.12.224.11 which is it's really old IP address.
> My DNS provider swears it's not coming from them and they have no idea
> where it is coming from. I personally think it is
> Where gets wierd is if you attach directly to their servers using
> nslookup you get the correct answer every time. If you use a
> non-authorititave server to do a normal style lookup up you get a bad
> record. Command and Output examples follow.
>
> bad record output
> dnsquery ecs1.altamente.com -n 209.12.224.6
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57670
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3
> ;;      ecs1.altamente.com, type = ANY, class = IN
> ecs1.altamente.com.     1d23h19m1s IN A  209.12.224.11
> altamente.com.          1d23h19m1s IN NS  NS1.ESPIRE.NET.
> altamente.com.          1d23h19m1s IN NS  NS2.ESPIRE.NET.
> altamente.com.          1d23h19m1s IN NS  NS1.OLSS.NET.
> NS1.ESPIRE.NET.         8h24m21s IN A   206.222.97.82
> NS2.ESPIRE.NET.         8h24m21s IN A   206.222.97.50
> NS1.OLSS.NET.           16h1m9s IN A    209.12.255.34
>
> correct output
> dnsquery ecs1.altamente.com -n ns1.espire.net
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53794
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3
> ;;      ecs1.altamente.com, type = ANY, class = IN
> ecs1.altamente.com.     1D IN A         209.12.244.241
> altamente.com.          1D IN NS        ns1.olss.net.
> altamente.com.          1D IN NS        ns1.espire.net.
> altamente.com.          1D IN NS        ns2.espire.net.
> ns1.olss.net.           1D IN A         209.12.255.34
> ns1.espire.net.         1D IN A         206.222.97.82
> ns2.espire.net.         1D IN A         206.222.97.50
>
> I can eventually flush the cache on 209.12.224.6 enough times that it
> will get the right record. But I really need to know where it is coming
> from so I know who to yell at. :)
> Any ideas?
>
> Philip Wall