BIND not resolving some addresses

[Tim]

Hi,

Recently I've tried to follow a few links in e-mails and news, to find
the browser couldn't do so.  At first I thought it was just the server
being temporarily unavailable, but realised it's BIND.  And it's all the
BINDs that I have (the latest available using yum on FC4, FC5 & FC6).

For example, doing a dig on eweek.com it takes ages and eventually
fails.  Conversely, doing a dig using my routers resolver, returns
results almost instantly.  I don't use it, however, for two reasons:  I
use internal DNS servers for the LAN, and my ISP's servers aren't always
very good (don't ask me why, I'm not the one that manages them).

Samples from different BIND servers and the router below.  I wonder if
anybody knows why, and whether they get the same effect for that
address?  There's about three addresses that I couldn't resolve, but
that's the only one that I can remember, at the moment.

--------------------------------

[tim@serge .gnupg]$ dig eweek.com

; <<>> DiG 9.3.3rc3 <<>> eweek.com
;; global options:  printcmd
;; connection timed out; no servers could be reached

--------------------------------

[tim@serge .gnupg]$ dig eweek.com @localhost

; <<>> DiG 9.3.3rc3 <<>> eweek.com @localhost
; (2 servers found)
;; global options:  printcmd
;; connection timed out; no servers could be reached

------------------------------

[tim@serge .gnupg]$ dig eweek.com @server

; <<>> DiG 9.3.3rc3 <<>> eweek.com @server
; (1 server found)
;; global options:  printcmd
;; connection timed out; no servers could be reached

------------------------------

[tim@serge .gnupg]$ dig eweek.com @router

; <<>> DiG 9.3.3rc3 <<>> eweek.com @router
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17304
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;eweek.com.                     IN      A

;; ANSWER SECTION:
eweek.com.              1800    IN      A       63.87.252.184

;; Query time: 265 msec
;; SERVER: 192.168.1.254#53(192.168.1.254)
;; WHEN: Tue Jan  9 11:39:51 2007
;; MSG SIZE  rcvd: 43

------------------------------

[Eric Wood]

----- Original Message ----- 
From: "Tim"
> Recently I've tried to follow a few links in e-mails and news, to find
> the browser couldn't do so.  At first I thought it was just the server
> being temporarily unavailable, but realised it's BIND.  And it's all the
> BINDs that I have (the latest available using yum on FC4, FC5 & FC6).
>
> For example, doing a dig on eweek.com it takes ages and eventually
> fails.  Conversely, doing a dig using my routers resolver, returns
> results almost instantly.  I don't use it, however, for two reasons:  I
> use internal DNS servers for the LAN, and my ISP's servers aren't always
> very good (don't ask me why, I'm not the one that manages them).

Has anyone seen a fix for this?  Even though my dns server can resolve 
eweek.com, It can't resolve "e.staples-deals.com".

Ever since I ran bind on redhat 7.3, it has never resolved that domain name 
for me:

# dig e.staples-deals.com @mydnsserver
results in a status: SERVFAIL

# dig e.staples-deals.com @myrouter
results are good!!

These are indeed weird results.  I'm currently running FC6 and I have the 
same exact problem as when I had it with RH 7.3.

Any ideas on how to track this down?

-Eric Wood

[Ed Greshko]

Eric Wood wrote:
> Has anyone seen a fix for this?  Even though my dns server can resolve 
> eweek.com, It can't resolve "e.staples-deals.com".
>
> Ever since I ran bind on redhat 7.3, it has never resolved that domain 
> name for me:
>
> # dig e.staples-deals.com @mydnsserver
> results in a status: SERVFAIL
>
> # dig e.staples-deals.com @myrouter
> results are good!!
>
> These are indeed weird results.  I'm currently running FC6 and I have 
> the same exact problem as when I had it with RH 7.3.
>
> Any ideas on how to track this down?

I would run named in debug mode on @mydnsserver and check the logs.  At 
least as a start.

[David L. Gehrt]

> Eric Wood wrote:
> > Has anyone seen a fix for this?  Even though my dns server can resolve 
> > eweek.com, It can't resolve "e.staples-deals.com".

<snip>
> > Any ideas on how to track this down?
>
> I would run named in debug mode on @mydnsserver and check the logs.  At 
> least as a start.

(Make sure  that the initial cache file is correct and up to date, then)

This is a good idea, but first may I suggest that your problem might be
with "mydnsserver", as I had no problems resolving the name to an IP with
the command:
> > > % dig e.staples-deals.com 
> > > ; <<>> DiG 9.2.4 <<>> e.staples-deals.com
> > > ;; global options:  printcmd!
> > > ;; Got answer:
> > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37847
> > > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
> > >
> > > ;; QUESTION SECTION:
> > > ;e.staples-deals.com.           IN      A
> > >
> > > ;; ANSWER SECTION:
> > > e.staples-deals.com.    3600    IN      A       63.210.43.103
> > >
> > > ;; AUTHORITY SECTION:
> > > e.staples-deals.com.    3600    IN      NS
> > > ns10.customer.level3.net.
> > > e.staples-deals.com.    3600    IN      NS
> > > ns11.customer.level3.net.
> > >
> > > ;; ADDITIONAL SECTION:
> > > ns10.customer.level3.net. 172800 IN     A       209.244.4.149
> > > ns11.customer.level3.net. 172800 IN     A       209.244.4.180
> > >
> > > ;; Query time: 1512 msec
> > > ;; SERVER: 127.0.0.1#53(0.0.0.0)
> > > ;; WHEN: Mon Feb 12 16:21:42 2007
> > > ;; MSG SIZE  rcvd: 142

I used to run several name servers at a large organization and when
these sorts of problems arose my first diagnostic tool was dig with the
'+trace' command line option.  This will expand the dig output and show
what name servers were called in order in the attempt to resolve the
host name. For example:
> > > % dig e.staples-deals.com +trace
> > >
> > > ; <<>> DiG 9.2.4 <<>> e.staples-deals.com +trace
> > > ;; global options:  printcmd
> > > .                       450456  IN      NS      A.ROOT-SERVERS.NET.
> > > .                       450456  IN      NS      B.ROOT-SERVERS.NET.
> > > .                       450456  IN      NS      C.ROOT-SERVERS.NET.
> > > .                       450456  IN      NS      D.ROOT-SERVERS.NET.
> > > .                       450456  IN      NS      E.ROOT-SERVERS.NET.
> > > .                       450456  IN      NS      F.ROOT-SERVERS.NET.
> > > .                       450456  IN      NS      G.ROOT-SERVERS.NET.
> > > .                       450456  IN      NS      H.ROOT-SERVERS.NET.
> > > .                       450456  IN      NS      I.ROOT-SERVERS.NET.
> > > .                       450456  IN      NS      J.ROOT-SERVERS.NET.
> > > .                       450456  IN      NS      K.ROOT-SERVERS.NET.
> > > .                       450456  IN      NS      L.ROOT-SERVERS.NET.
> > > .                       450456  IN      NS      M.ROOT-SERVERS.NET.
> > > ;; Received 292 bytes from 127.0.0.1#53(0.0.0.0) in 59 ms
> > >
> > > com.                    172800  IN      NS      A.GTLD-SERVERS.NET.
> > > com.                    172800  IN      NS      G.GTLD-SERVERS.NET.
> > > com.                    172800  IN      NS      H.GTLD-SERVERS.NET.
> > > com.                    172800  IN      NS      C.GTLD-SERVERS.NET.
> > > com.                    172800  IN      NS      I.GTLD-SERVERS.NET.
> > > com.                    172800  IN      NS      B.GTLD-SERVERS.NET.
> > > com.                    172800  IN      NS      D.GTLD-SERVERS.NET.
> > > com.                    172800  IN      NS      L.GTLD-SERVERS.NET.
> > > com.                    172800  IN      NS      F.GTLD-SERVERS.NET.
> > > com.                    172800  IN      NS      J.GTLD-SERVERS.NET.
> > > com.                    172800  IN      NS      K.GTLD-SERVERS.NET.
> > > com.                    172800  IN      NS      E.GTLD-SERVERS.NET.
> > > com.                    172800  IN      NS      M.GTLD-SERVERS.NET.
> > > ;; Received 509 bytes from 198.41.0.4#53(A.ROOT-SERVERS.NET) in 128 ms
> > >
> > > staples-deals.com.      172800  IN      NS
> > > dbru.br.ns.els-gms.att.net.
> > > staples-deals.com.      172800  IN      NS
> > > dmtu.mt.ns.els-gms.att.net.
> > > ;; Received 131 bytes from 192.5.6.30#53(A.GTLD-SERVERS.NET) in 103 ms
> > >
> > > e.staples-deals.com.    86400   IN      NS
> > > ns11.customer.level3.net.
> > > e.staples-deals.com.    86400   IN      NS
> > > ns10.customer.level3.net.
> > > ;; Received 94 bytes from 199.191.128.106#53(dbru.br.ns.els-gms.att.net)
> > > in 64 ms
> > >
> > > e.staples-deals.com.    3600    IN      A       63.210.43.103
> > > e.staples-deals.com.    3600    IN      NS
> > > ns11.customer.level3.net.
> > > e.staples-deals.com.    3600    IN      NS
> > > ns10.customer.level3.net.
> > > ;; Received 142 bytes from 209.244.4.180#53(ns11.customer.level3.net) in
> > > 88 ms

You should see the 'SERVFAIL'ing name server

Good luck!

dlg

[Ric Moore]

On Mon, 2007-02-12 at 16:46 -0800, David L. Gehrt wrote:
> dig e.staples-deals.com

dig e.staples-deals.com

; <<>> DiG 9.3.4 <<>> e.staples-deals.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60075
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0

;; QUESTION SECTION:
;e.staples-deals.com.           IN      A

;; ANSWER SECTION:
e.staples-deals.com.    3600    IN      A       63.210.43.103

;; AUTHORITY SECTION:
e.staples-deals.com.    3600    IN      NS
ns10.customer.level3.net.
e.staples-deals.com.    3600    IN      NS
ns11.customer.level3.net.

;; Query time: 277 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Feb 12 21:39:58 2007
;; MSG SIZE  rcvd: 110

I just have a local cache setup, followed the directions posted at
redhat.com. Not bad for a complete DNS idiot. Ric

[Will Yonker]

> Has anyone seen a fix for this?  Even though my dns server can resolve
> eweek.com, It can't resolve "e.staples-deals.com".
>
> Ever since I ran bind on redhat 7.3, it has never resolved that domain
> name
> for me:
>
> # dig e.staples-deals.com @mydnsserver
> results in a status: SERVFAIL
>
> # dig e.staples-deals.com @myrouter
> results are good!!
>
> These are indeed weird results.  I'm currently running FC6 and I have the
> same exact problem as when I had it with RH 7.3.
>
> Any ideas on how to track this down?

This is an old thread but I'm using my powers as a necromancer to
resurrect it!

In any case, I have had this exact problem since way back in the Fedora
Core 2 era.

At first I thought it was my ISP.  I had RR and switched to DSL.  I had
the same problem with both on the same domain (tldp.org).  I added a free
DNS server to my resolv.conf.  This did not help.  It must be something
local.

Any ideas?

[Rick Stevens]

On Tue, 2007-02-27 at 20:27 -0500, [e-mail] wrote:
> > Has anyone seen a fix for this?  Even though my dns server can resolve
> > eweek.com, It can't resolve "e.staples-deals.com".
> >
> > Ever since I ran bind on redhat 7.3, it has never resolved that domain
> > name
> > for me:
> >
> > # dig e.staples-deals.com @mydnsserver
> > results in a status: SERVFAIL
> >
> > # dig e.staples-deals.com @myrouter
> > results are good!!
> >
> > These are indeed weird results.  I'm currently running FC6 and I have the
> > same exact problem as when I had it with RH 7.3.
> >
> > Any ideas on how to track this down?
>
> This is an old thread but I'm using my powers as a necromancer to
> resurrect it!
>
> In any case, I have had this exact problem since way back in the Fedora
> Core 2 era.
>
> At first I thought it was my ISP.  I had RR and switched to DSL.  I had
> the same problem with both on the same domain (tldp.org).  I added a free
> DNS server to my resolv.conf.  This did not help.  It must be something
> local.
>
> Any ideas?

Have you tried "dig +trace e.staples-deals.com @mydnsserver" to see
exactly what's going on?  My guess is that you're not getting to the
root servers.

----------------------------------------------------------------------
- Rick Stevens, Principal Engineer          [e-mail] -
- VitalStream, Inc.                       http://www.vitalstream.com -
-                                                                    -
-               500: Internal Fortune Cookie Error                   -
----------------------------------------------------------------------