Reasons for not resolving
Alans
Hello,
There are few websites that our DNS (BIND 9.4.2 on CentOS 5) is not resolving while others like 4.2.2.2 does, I wonder what could be the reasons for this?
Regards,
Alans
Alans
I looked more and I figure out that we can’t ping or browse any of these hosts http://www.ip-adress.com/reverse_ip/96.31.75.113 (they all are on one IP) it’s confusing because when I search in google for host names it appears in the result which means it’s not down fir everyone!! Any ideas?
Kind regards,
Alans
Kevin Darcy
Why would you use Google to determine whether a web site is up or not?
It's not even clear to me that you're having a DNS problem. It's rather
bad practice to have lots of reverse-records in the DNS for a given
address (e.g. 96.31.75.113), and can even cause problems with oversized
responses to reverse lookups being dropped by firewalls, but it
shouldn't cause any *forward* (name-to-address) lookups to fail.
Can you resolve a name like yarnandwaste.com or can't you? Please follow
normal diagnostic procedures and try to determine what actual problem
you are having. "Can't ping or browse" is only the start of the
diagnostic process, and might not be caused by DNS at all.
Once you've determined that you can't resolve a particular name, then
something you might try is a "dig +trace" on the name, from your
nameserver. That will show you the sequence of queries that will be
followed by a resolver to try and resolve the name, and might help
pinpoint the source of the problem. It will not, however, exactly match
what your nameserver is doing unless you have a completely "vanilla",
iterative-resolving configuration (i.e. Internet root hints and nothing
else). If you have other elements of your config that affect resolution,
e.g. zones of type stub/forward/master/slave anywhere in the hierarchy
of the name you're looking up, or "forwarders" in your "options" clause,
then "dig +trace" won't know about those "specials" and can't match
exactly what your nameserver would do. Also, it's possible that your
nameserver has cached data that might cause it to resolve differently
than "dig +trace", which always starts with no cache at all.
- Kevin
Alans wrote:
>
> I looked more and I figure out that we can�t ping or browse any of
> these hosts http://www.ip-adress.com/reverse_ip/96.31.75.113 (they all
> are on one IP) it�s confusing because when I search in google for host
> names it appears in the result which means it�s not down fir
> everyone!! Any ideas?
>
> Kind regards,
>
> Alans
>
> *From:* bind-user...@lists.isc.org
> [mailto:bind-user...@lists.isc.org] *On Behalf Of *Alans
> *Sent:* Wednesday, October 28, 2009 10:47 AM
> *To:* bind-...@lists.isc.org
> *Subject:* Reasons for not resolving
>
> Hello,
>
> There are few websites that our DNS (BIND 9.4.2 on CentOS 5) is not
> resolving while others like 4.2.2.2 does, I wonder what could be the
> reasons for this?
>
> Regards,
>
> Alans
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> bind-users mailing list
> bind-...@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
Alans
Thanks for your explanation, yarnandwaste.com cannot be resolved, below is
dig +trace result:
[root@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?
Also another issue is with gegreklam.com which have different results when
dig +trace and without +trace, kindly check below results:
- without +trace
[root@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@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?
Best regards,
Alans
- Kevin
Alans wrote:
>
> I looked more and I figure out that we can't ping or browse any of
> these hosts http://www.ip-adress.com/reverse_ip/96.31.75.113 (they all
> are on one IP) it's confusing because when I search in google for host
> names it appears in the result which means it's not down fir
Kevin Darcy
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.
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
Alans
.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
$
- Kevin
_______________________________________________