Lookup weirdness

[Barry Margolin]

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 ***