On 29 Nov 2012, at 10:49, Ralf Hildebrandt <r...@sys4.de> wrote: > I'm seeing a DNS problem I cannot fathom: > > # host 65.171.152.29
Well, there's part of your problem right there. Never, ever use host or nslookup to query the DNS. Use dig. [Or drill if you're into debugging DNSSEC.] Accept no substitutes. dig shows you what's actually in the DNS packets. host and nslookup don't/can't do that. Which mean they're mostly useless for DNS debugging. In some cases, nslookup is actually a hindrance. Too bad you edited out the dig output which showed the DNS header info. That would have shown the aa bit (Authoritative Answer) wasn't set on replies that should have had this. BTW, a dig +trace is an easy way of finding where a DNS delegation is broken. It uses the same resolving code BIND9 uses, so this pretty much mimics what your name server would be doing. RFC2317-style delegation is being used for the reverse DNS entry for this IP address. 29.152.171.65.in-addr.arpa is a CNAME which points at 65.171.152.29.cust.bosto3.sprintlink.net. However the delegation for cust.bosto3.sprintlink.net was broken. None of the name servers it's delegated to were answering authoritatively for that zone. This is why you got SERVFAILs. Your resolving name server was saying "I give up on this lookup because something is badly broken". Something or someone at sprintlink.net has goofed. It looks to have been a transient error because the name servers in question are now behaving properly. I re-checked the sprintlink servers just before posting this and found that the broken delegation had been repaired. You may want to flush the cache and/or restart your resolving name server to get rid of its memory of the SERVFAILs instead of waiting for that to expire from the cache.
