Reasons for not resolving
Alans
batpower83 at yahoo.co.uk
Sun Nov 1 07:15:19 UTC 2009
What happens if you try to resolve yarnandwaste.com directly from
96.31.75.113/96.31.75.114? I can't, not even able to ping it (.113 &
.114) we'll check our connectivity with that network.
As for gegreklam.com, I too when resolve from c.gtld-servers.net can get A
record IP but not with +trace!!!
I knew from them (gegrek) that they changed their DNS a few weeks ago, I'll
try to notify them that there domain is expired.
Thanks,
Alans
> 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 do
main). 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
_______________________________________________
bind-users mailing list
bind-users at lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
More information about the bind-users
mailing list