Reasons for not resolving
Kevin Darcy
kcd at chrysler.com
Thu Oct 29 17:04:17 UTC 2009
Alans wrote:
> Kevin,
>
> Thanks for your explanation, yarnandwaste.com cannot be resolved, below is
> dig +trace result:
> [root at ns2 ~]# dig yarnandwaste.com +trace
>
> ; <<>> DiG 9.4.2 <<>> yarnandwaste.com +trace
> ;; global options: printcmd
> . 437569 IN NS B.ROOT-SERVERS.NET.
> . 437569 IN NS C.ROOT-SERVERS.NET.
> . 437569 IN NS D.ROOT-SERVERS.NET.
> . 437569 IN NS E.ROOT-SERVERS.NET.
> . 437569 IN NS F.ROOT-SERVERS.NET.
> . 437569 IN NS G.ROOT-SERVERS.NET.
> . 437569 IN NS H.ROOT-SERVERS.NET.
> . 437569 IN NS I.ROOT-SERVERS.NET.
> . 437569 IN NS J.ROOT-SERVERS.NET.
> . 437569 IN NS K.ROOT-SERVERS.NET.
> . 437569 IN NS L.ROOT-SERVERS.NET.
> . 437569 IN NS M.ROOT-SERVERS.NET.
> . 437569 IN NS A.ROOT-SERVERS.NET.
> ;; Received 500 bytes from xx.xx.xx.xx #53(xx.xx.xx.xx) in 0 ms
>
> com. 172800 IN NS F.GTLD-SERVERS.NET.
> com. 172800 IN NS M.GTLD-SERVERS.NET.
> com. 172800 IN NS H.GTLD-SERVERS.NET.
> com. 172800 IN NS A.GTLD-SERVERS.NET.
> com. 172800 IN NS L.GTLD-SERVERS.NET.
> com. 172800 IN NS B.GTLD-SERVERS.NET.
> com. 172800 IN NS D.GTLD-SERVERS.NET.
> com. 172800 IN NS G.GTLD-SERVERS.NET.
> com. 172800 IN NS E.GTLD-SERVERS.NET.
> com. 172800 IN NS J.GTLD-SERVERS.NET.
> com. 172800 IN NS C.GTLD-SERVERS.NET.
> com. 172800 IN NS K.GTLD-SERVERS.NET.
> com. 172800 IN NS I.GTLD-SERVERS.NET.
> ;; Received 506 bytes from 198.41.0.4#53(A.ROOT-SERVERS.NET) in 158 ms
>
> yarnandwaste.com. 172800 IN NS maa.durgamatamandir.com.
> yarnandwaste.com. 172800 IN NS mata.durgamatamandir.com.
> ;; Received 119 bytes from 192.42.93.30#53(G.GTLD-SERVERS.NET) in 225 ms
>
> ;; connection timed out; no servers could be reached
>
>
> Does that mean it's a connectivity problem?
>
>
>
Yes, it appears to be a connectivity problem of some sort. The next step
in the resolution chain for yarnandwaste.com would be the nameservers at
96.31.75.113 & 96.31.75.114 and I can resolve just fine from those. What
happens if you try to resolve yarnandwaste.com directly from
96.31.75.113/96.31.75.114?
Those IPs look like they might be on the same subnet; possibly one or
more Single Points of Failure might cause the whole domain to become
unresolvable for some period of time.
> Also another issue is with gegreklam.com which have different results when
> dig +trace and without +trace, kindly check below results:
>
> - without +trace
> [root at ns2 ~]# dig gegreklam.com
>
> ; <<>> DiG 9.4.2 <<>> gegreklam.com
> ;; global options: printcmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2418
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0
>
> ;; QUESTION SECTION:
> ;gegreklam.com. IN A
>
> ;; ANSWER SECTION:
> gegreklam.com. 13940 IN A 208.43.100.50
>
> ;; AUTHORITY SECTION:
> gegreklam.com. 85940 IN NS dns4.rawshen.com.
> gegreklam.com. 85940 IN NS dns3.rawshen.com.
>
> ;; Query time: 0 msec
> ;; SERVER: xx.xx.xx.xx#53(xx.xx.xx.xx)
> ;; WHEN: Thu Oct 29 08:07:01 2009
> ;; MSG SIZE rcvd: 93
>
> - with +trace
>
>
> [root at ns2 ~]# dig gegreklam.com +trace
>
> ; <<>> DiG 9.4.2 <<>> gegreklam.com +trace
> ;; global options: printcmd
> . 436613 IN NS E.ROOT-SERVERS.NET.
> . 436613 IN NS F.ROOT-SERVERS.NET.
> . 436613 IN NS G.ROOT-SERVERS.NET.
> . 436613 IN NS H.ROOT-SERVERS.NET.
> . 436613 IN NS I.ROOT-SERVERS.NET.
> . 436613 IN NS J.ROOT-SERVERS.NET.
> . 436613 IN NS K.ROOT-SERVERS.NET.
> . 436613 IN NS L.ROOT-SERVERS.NET.
> . 436613 IN NS M.ROOT-SERVERS.NET.
> . 436613 IN NS A.ROOT-SERVERS.NET.
> . 436613 IN NS B.ROOT-SERVERS.NET.
> . 436613 IN NS C.ROOT-SERVERS.NET.
> . 436613 IN NS D.ROOT-SERVERS.NET.
> ;; Received 500 bytes from xx.xx.xx.xx #53(xx.xx.xx.xx) in 0 ms
>
> com. 172800 IN NS H.GTLD-SERVERS.NET.
> com. 172800 IN NS E.GTLD-SERVERS.NET.
> com. 172800 IN NS C.GTLD-SERVERS.NET.
> com. 172800 IN NS D.GTLD-SERVERS.NET.
> com. 172800 IN NS G.GTLD-SERVERS.NET.
> com. 172800 IN NS L.GTLD-SERVERS.NET.
> com. 172800 IN NS F.GTLD-SERVERS.NET.
> com. 172800 IN NS I.GTLD-SERVERS.NET.
> com. 172800 IN NS M.GTLD-SERVERS.NET.
> com. 172800 IN NS B.GTLD-SERVERS.NET.
> com. 172800 IN NS K.GTLD-SERVERS.NET.
> com. 172800 IN NS J.GTLD-SERVERS.NET.
> com. 172800 IN NS A.GTLD-SERVERS.NET.
> ;; Received 491 bytes from 192.5.5.241#53(F.ROOT-SERVERS.NET) in 85 ms
>
> gegreklam.com. 172800 IN NS ml1.dhksoft.com.
> gegreklam.com. 172800 IN NS ml2.dhksoft.com.
> ;; Received 107 bytes from 192.26.92.30#53(C.GTLD-SERVERS.NET) in 158 ms
>
> dig: couldn't get address for 'ml2.dhksoft.com': not found
>
> I guess this was your point by "starting with no cache" since it gives us 2
> different NS results, right?
>
>
>
Right. Both domains are actually mis-delegated (for yarnandwaste.com,
the delegated nameservers are in durgamatamandir.com, versus
overlineindia.com in the zone itself, and for gegreklam.com, the
delegated nameservers are in dhksoft.com versus rawshen.com nameservers
in the zone itself).
gegreklam.com is worse off than yarnandwaste.com, because ns3.rawshen.com and ns4.rawshen.com (which you appear to have cached) don't even resolve to A records.
The .com servers have glue records for all 4 of those delegated nameservers, so "fresh" queries, following down from the delegations, should work fine (barring any connectivity problems). The problem comes in when you have the NS and associated A records cached, and then some of them expire from the cache before others. That's why it's always good practice to have your delegation NS records match the NS records at the apex of the zone. In the case of a migration between one set of nameservers and another, it might be necessary for one set of NSes to be a superset of the other, but they should never be completely different; doing so either sets up "glue-less" NS records (NS records pointing in-zone, which the parent servers know nothing about, and therefore cannot provide glue for) or fragile interdependencies between domains -- sometimes even dependency loops (A publishes nameservers in the B domain, B publishes nameservers in the C domain, C publishes nameservers in the A domain). Either way, such mismatches are apt to break things.
I'm not quite sure why C.GTLD-SERVERS.NET didn't return you the A record for ml1.dhksoft.com, since I get it in my response:
$ dig gegreklam.com +norec @C.GTLD-SERVERS.NET
; <<>> DiG 9.3.5-P2 <<>> gegreklam.com +norec @C.GTLD-SERVERS.NET
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1013
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2
;; QUESTION SECTION:
;gegreklam.com. IN A
;; AUTHORITY SECTION:
gegreklam.com. 172800 IN NS ml1.dhksoft.com.
gegreklam.com. 172800 IN NS ml2.dhksoft.com.
;; ADDITIONAL SECTION:
ml1.dhksoft.com. 172800 IN A 208.43.100.50
ml2.dhksoft.com. 172800 IN A 208.43.98.188
;; Query time: 28 msec
;; SERVER: 192.26.92.30#53(192.26.92.30)
;; WHEN: Thu Oct 29 11:11:33 2009
;; MSG SIZE rcvd: 107
$
It's possible that the dhksoft.com glue records might have been temporarily purged from the registry (if there were no known dependencies), and then popped up again later, but this seems unlikely. Although, I will note that the dhksoft.com domain appears to be about to expire (Expiration Date: 2009-10-29 16:48:25 according to WHOIS), so they may be making some registry changes to it.
Another possibility is that C.GTLD-SERVERS.NET might have deliberately omitted the A records as a bandwidth-saving measure, knowing that there were/are no interdependencies between dhksoft.com and gegreklam.com, or any dependency topology of which those 2 domains were a part, and therefore anyone who needed the A records could simply re-query for them (which dig +trace doesn't do, apparently).
- Kevin
More information about the bind-users
mailing list