Lookup weirdness
Barry Margolin
barmar at alum.mit.edu
Sat Nov 20 01:45:05 UTC 2004
In article <cnlflf$2hbl$1 at sf1.isc.org>,
"Mike B" <toastyhamster at hotmail.com> wrote:
> Ok, this has me baffled.
>
> I'm running a primary/secondary DNS server, neither are able to resolve
> anything in the 152.158 domain (the example I am using is
> 152.158.16.48). Everywhere else on the 'Net I have tried can. The only
> anomaly I can find is that www.dnsstuff.com occasionally shows a bad
> delegation, this is a fault of one of the ARIN servers, which is
> delegating it to a now decommissioned ibm.net server. However, my
> queries on this subnet never leave the local DNS server (proven by
> tcpdump and firewall logs). Forward lookups for ns.uk.prserv.net work
> intermittently, as do queries on all the AT&T DNS servers in that
> subnet.
>
> I have tried to restart BIND, with no luck. This started earlier this
> week after a faulty BGP route led the path to 152.158. through a broken
> ISP router interface, however this has no been fixed. on config changes
> have been made recently.
>
> I can telnet to 152.158.16.48 on port 53. I can even use the server
> command in nslookup to query it (after the initial lookup has timed
> out). I have turned on full logging and can see the query hitting the
> logs. I have dumped the cache and compared against a working machine I
> can see the reverse lookup cache is missing for that subnet. I have used
> nslookup -d2 and dog +trace, neither leave the local machine, even after
> immediately starting BIND. I have replicated the config on another DNS
> pair outside of the subnet and it works perfectly. With tcp 53 and udp
> 53 access proven though I don't know why BIND will not at least query
> the root name servers for the answer. There are no entries for 152.x in
> named.conf. BIND version is 9.2.1.
There's a potential problem with the prserv.net servers:
$ dig prserv.net ns @ns1.us.prserv.net +norec
; <<>> DiG 9.2.2 <<>> prserv.net ns @ns1.us.prserv.net +norec
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41956
;; flags: qr aa ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 3
;; QUESTION SECTION:
;prserv.net. IN NS
;; ANSWER SECTION:
prserv.net. 86400 IN NS ns3.us.prserv.net.
prserv.net. 86400 IN NS ns4.us.prserv.net.
prserv.net. 86400 IN NS ns1.us.prserv.net.
;; ADDITIONAL SECTION:
ns3.us.prserv.net. 14400 IN A 165.87.201.243
ns4.us.prserv.net. 14400 IN A 165.87.201.244
ns1.us.prserv.net. 14400 IN A 165.87.194.244
;; Query time: 404 msec
;; SERVER: 165.87.194.244#53(ns1.us.prserv.net)
;; WHEN: Fri Nov 19 20:42:16 2004
;; MSG SIZE rcvd: 133
Notice that the TTLs of the A records are shorter than those of the NS
records. When the A records expire, the NS records will point to names
that can't be resolved, because they're in the domain of the NS records.
--
Barry Margolin, barmar at alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
More information about the bind-users
mailing list