Discussion:
DIG Info Request
(too old to reply)
Linux Addict
2015-02-03 18:50:14 UTC
Permalink
I do dig . +trace and the results seem show .new servers. This is causing
SERVFAIL for root query. Any ideas?

dig . +trace

; <<>> DiG 9.7.0-P1 <<>> . +trace
;; global options: +cmd
. 348510 IN NS b.root-servers.new.
. 348510 IN NS h.root-servers.new.
. 348510 IN NS l.root-servers.new.
. 348510 IN NS f.root-servers.new.
. 348510 IN NS m.root-servers.new.
. 348510 IN NS k.root-servers.new.
. 348510 IN NS i.root-servers.new.
. 348510 IN NS e.root-servers.new.
. 348510 IN NS g.root-servers.new.
. 348510 IN NS j.root-servers.new.
. 348510 IN NS c.root-servers.new.
. 348510 IN NS d.root-servers.new.
;; Received 405 bytes from 172.27.254.11#53(172.27.254.11) in 1 ms

;; connection timed out; no servers could be reached
Lyle Giese
2015-02-03 19:02:24 UTC
Permalink
If I remember right, DIG does not know the root servers and asks the
local host to retrieve that information and a server at
172.27.254.11(which is RFC 1918 address space) gave you that answer.

Is your machine/shop setup with private root servers?

Lyle
Post by Linux Addict
I do dig . +trace and the results seem show .new servers. This is
causing SERVFAIL for root query. Any ideas?
dig . +trace
; <<>> DiG 9.7.0-P1 <<>> . +trace
;; global options: +cmd
. 348510 IN NS b.root-servers.new.
. 348510 IN NS h.root-servers.new.
. 348510 IN NS l.root-servers.new.
. 348510 IN NS f.root-servers.new.
. 348510 IN NS m.root-servers.new.
. 348510 IN NS k.root-servers.new.
. 348510 IN NS i.root-servers.new.
. 348510 IN NS e.root-servers.new.
. 348510 IN NS g.root-servers.new.
. 348510 IN NS j.root-servers.new.
. 348510 IN NS c.root-servers.new.
. 348510 IN NS d.root-servers.new.
;; Received 405 bytes from 172.27.254.11#53(172.27.254.11) in 1 ms
;; connection timed out; no servers could be reached
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users
Linux Addict
2015-02-03 19:07:56 UTC
Permalink
The named.ca seems good.

;; ANSWER SECTION:
. 518400 IN NS C.ROOT-SERVERS.NET.
. 518400 IN NS I.ROOT-SERVERS.NET.
. 518400 IN NS F.ROOT-SERVERS.NET.
. 518400 IN NS B.ROOT-SERVERS.NET.
. 518400 IN NS L.ROOT-SERVERS.NET.
. 518400 IN NS D.ROOT-SERVERS.NET.
. 518400 IN NS J.ROOT-SERVERS.NET.
. 518400 IN NS K.ROOT-SERVERS.NET.
. 518400 IN NS E.ROOT-SERVERS.NET.
. 518400 IN NS A.ROOT-SERVERS.NET.
. 518400 IN NS M.ROOT-SERVERS.NET.
. 518400 IN NS G.ROOT-SERVERS.NET.
. 518400 IN NS H.ROOT-SERVERS.NET.
Post by Lyle Giese
If I remember right, DIG does not know the root servers and asks the
local host to retrieve that information and a server at 172.27.254.11(which
is RFC 1918 address space) gave you that answer.
Is your machine/shop setup with private root servers?
Lyle
I do dig . +trace and the results seem show .new servers. This is
causing SERVFAIL for root query. Any ideas?
dig . +trace
; <<>> DiG 9.7.0-P1 <<>> . +trace
;; global options: +cmd
. 348510 IN NS b.root-servers.new.
. 348510 IN NS h.root-servers.new.
. 348510 IN NS l.root-servers.new.
. 348510 IN NS f.root-servers.new.
. 348510 IN NS m.root-servers.new.
. 348510 IN NS k.root-servers.new.
. 348510 IN NS i.root-servers.new.
. 348510 IN NS e.root-servers.new.
. 348510 IN NS g.root-servers.new.
. 348510 IN NS j.root-servers.new.
. 348510 IN NS c.root-servers.new.
. 348510 IN NS d.root-servers.new.
;; Received 405 bytes from 172.27.254.11#53(172.27.254.11) in 1 ms
;; connection timed out; no servers could be reached
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to
unsubscribe from this list
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users
Mukund Sivaraman
2015-02-03 19:12:27 UTC
Permalink
Post by Linux Addict
I do dig . +trace and the results seem show .new servers. This is
causing SERVFAIL for root query. Any ideas?
dig . +trace
Contact the person who runs the resolver at 172.27.254.11 and report the
problem about the root hints. dig +trace uses the configured resolver to
only find the root nameservers, and directly does lookups afterwards.

So while regular lookup may succeed through your resolver, dig +trace
may not. See:

https://kb.isc.org/article/AA-00208/0/Why-is-the-outcome-different-from-dig-when-using-the-trace-option.html

Mukund
Linux Addict
2015-02-03 19:13:45 UTC
Permalink
Additional info - general: warning: checkhints: unable to find root NS
'b.root-servers.new' in hints

​I cant seem to find where the ".new" coming from...​
Post by Linux Addict
The named.ca seems good.
. 518400 IN NS C.ROOT-SERVERS.NET.
. 518400 IN NS I.ROOT-SERVERS.NET.
. 518400 IN NS F.ROOT-SERVERS.NET.
. 518400 IN NS B.ROOT-SERVERS.NET.
. 518400 IN NS L.ROOT-SERVERS.NET.
. 518400 IN NS D.ROOT-SERVERS.NET.
. 518400 IN NS J.ROOT-SERVERS.NET.
. 518400 IN NS K.ROOT-SERVERS.NET.
. 518400 IN NS E.ROOT-SERVERS.NET.
. 518400 IN NS A.ROOT-SERVERS.NET.
. 518400 IN NS M.ROOT-SERVERS.NET.
. 518400 IN NS G.ROOT-SERVERS.NET.
. 518400 IN NS H.ROOT-SERVERS.NET.
Post by Lyle Giese
If I remember right, DIG does not know the root servers and asks the
local host to retrieve that information and a server at 172.27.254.11(which
is RFC 1918 address space) gave you that answer.
Is your machine/shop setup with private root servers?
Lyle
I do dig . +trace and the results seem show .new servers. This is
causing SERVFAIL for root query. Any ideas?
dig . +trace
; <<>> DiG 9.7.0-P1 <<>> . +trace
;; global options: +cmd
. 348510 IN NS b.root-servers.new.
. 348510 IN NS h.root-servers.new.
. 348510 IN NS l.root-servers.new.
. 348510 IN NS f.root-servers.new.
. 348510 IN NS m.root-servers.new.
. 348510 IN NS k.root-servers.new.
. 348510 IN NS i.root-servers.new.
. 348510 IN NS e.root-servers.new.
. 348510 IN NS g.root-servers.new.
. 348510 IN NS j.root-servers.new.
. 348510 IN NS c.root-servers.new.
. 348510 IN NS d.root-servers.new.
;; Received 405 bytes from 172.27.254.11#53(172.27.254.11) in 1 ms
;; connection timed out; no servers could be reached
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to
unsubscribe from this list
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users
Lyle Giese
2015-02-03 19:19:38 UTC
Permalink
172.27.254.11 is giving you that info with the .new name servers. You
need to ask whomever manages that server.

Look at this line from your +trace output:

Received 405 bytes from 172.27.254.11#53(172.27.254.11) in 1 ms

Lyle
Post by Linux Addict
Additional info - general: warning: checkhints: unable to find root NS
'b.root-servers.new' in hints
​I cant seem to find where the ".new" coming from...​
The named.ca <http://named.ca> seems good.
. 518400 IN NS C.ROOT-SERVERS.NET
<http://C.ROOT-SERVERS.NET>.
. 518400 IN NS I.ROOT-SERVERS.NET
<http://I.ROOT-SERVERS.NET>.
. 518400 IN NS F.ROOT-SERVERS.NET
<http://F.ROOT-SERVERS.NET>.
. 518400 IN NS B.ROOT-SERVERS.NET
<http://B.ROOT-SERVERS.NET>.
. 518400 IN NS L.ROOT-SERVERS.NET
<http://L.ROOT-SERVERS.NET>.
. 518400 IN NS D.ROOT-SERVERS.NET
<http://D.ROOT-SERVERS.NET>.
. 518400 IN NS J.ROOT-SERVERS.NET
<http://J.ROOT-SERVERS.NET>.
. 518400 IN NS K.ROOT-SERVERS.NET
<http://K.ROOT-SERVERS.NET>.
. 518400 IN NS E.ROOT-SERVERS.NET
<http://E.ROOT-SERVERS.NET>.
. 518400 IN NS A.ROOT-SERVERS.NET
<http://A.ROOT-SERVERS.NET>.
. 518400 IN NS M.ROOT-SERVERS.NET
<http://M.ROOT-SERVERS.NET>.
. 518400 IN NS G.ROOT-SERVERS.NET
<http://G.ROOT-SERVERS.NET>.
. 518400 IN NS H.ROOT-SERVERS.NET
<http://H.ROOT-SERVERS.NET>.
If I remember right, DIG does not know the root servers and
asks the local host to retrieve that information and a server
at 172.27.254.11(which is RFC 1918 address space) gave you
that answer.
Is your machine/shop setup with private root servers?
Lyle
Post by Linux Addict
I do dig . +trace and the results seem show .new servers.
This is causing SERVFAIL for root query. Any ideas?
dig . +trace
; <<>> DiG 9.7.0-P1 <<>> . +trace
;; global options: +cmd
. 348510 IN NS b.root-servers.new.
. 348510 IN NS h.root-servers.new.
. 348510 IN NS l.root-servers.new.
. 348510 IN NS f.root-servers.new.
. 348510 IN NS m.root-servers.new.
. 348510 IN NS k.root-servers.new.
. 348510 IN NS i.root-servers.new.
. 348510 IN NS e.root-servers.new.
. 348510 IN NS g.root-servers.new.
. 348510 IN NS j.root-servers.new.
. 348510 IN NS c.root-servers.new.
. 348510 IN NS d.root-servers.new.
;; Received 405 bytes from 172.27.254.11#53(172.27.254.11) in
1 ms
;; connection timed out; no servers could be reached
_______________________________________________
Please visithttps://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users
to unsubscribe from this list
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users
Linux Addict
2015-02-03 19:28:48 UTC
Permalink
Actually I tried +trace from BIND server itself and still get the same
answer. I did "dig . +trace @localhost"


; <<>> DiG 9.7.0-P1 <<>> . +trace @localhost
;; global options: +cmd
. 346239 IN NS i.root-servers.new.
. 346239 IN NS c.root-servers.new.
. 346239 IN NS b.root-servers.new.
. 346239 IN NS e.root-servers.new.
. 346239 IN NS d.root-servers.new.
. 346239 IN NS l.root-servers.new.
. 346239 IN NS f.root-servers.new.
. 346239 IN NS j.root-servers.new.
. 346239 IN NS h.root-servers.new.
. 346239 IN NS k.root-servers.new.
. 346239 IN NS m.root-servers.new.
. 346239 IN NS g.root-servers.new.
;; Received 405 bytes from localhost#53(localhost) in 1 ms
Post by Lyle Giese
172.27.254.11 is giving you that info with the .new name servers. You
need to ask whomever manages that server.
Received 405 bytes from 172.27.254.11#53(172.27.254.11) in 1 ms
Lyle
Additional info - general: warning: checkhints: unable to find root NS
'b.root-servers.new' in hints
​I cant seem to find where the ".new" coming from...​
Post by Linux Addict
The named.ca seems good.
. 518400 IN NS C.ROOT-SERVERS.NET.
. 518400 IN NS I.ROOT-SERVERS.NET.
. 518400 IN NS F.ROOT-SERVERS.NET.
. 518400 IN NS B.ROOT-SERVERS.NET.
. 518400 IN NS L.ROOT-SERVERS.NET.
. 518400 IN NS D.ROOT-SERVERS.NET.
. 518400 IN NS J.ROOT-SERVERS.NET.
. 518400 IN NS K.ROOT-SERVERS.NET.
. 518400 IN NS E.ROOT-SERVERS.NET.
. 518400 IN NS A.ROOT-SERVERS.NET.
. 518400 IN NS M.ROOT-SERVERS.NET.
. 518400 IN NS G.ROOT-SERVERS.NET.
. 518400 IN NS H.ROOT-SERVERS.NET.
Post by Lyle Giese
If I remember right, DIG does not know the root servers and asks the
local host to retrieve that information and a server at 172.27.254.11(which
is RFC 1918 address space) gave you that answer.
Is your machine/shop setup with private root servers?
Lyle
I do dig . +trace and the results seem show .new servers. This is
causing SERVFAIL for root query. Any ideas?
dig . +trace
; <<>> DiG 9.7.0-P1 <<>> . +trace
;; global options: +cmd
. 348510 IN NS b.root-servers.new.
. 348510 IN NS h.root-servers.new.
. 348510 IN NS l.root-servers.new.
. 348510 IN NS f.root-servers.new.
. 348510 IN NS m.root-servers.new.
. 348510 IN NS k.root-servers.new.
. 348510 IN NS i.root-servers.new.
. 348510 IN NS e.root-servers.new.
. 348510 IN NS g.root-servers.new.
. 348510 IN NS j.root-servers.new.
. 348510 IN NS c.root-servers.new.
. 348510 IN NS d.root-servers.new.
;; Received 405 bytes from 172.27.254.11#53(172.27.254.11) in 1 ms
;; connection timed out; no servers could be reached
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to
unsubscribe from this list
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to
unsubscribe from this list
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users
Linux Addict
2015-02-03 19:34:41 UTC
Permalink
Let me take a step back. The original problem is "dig ." would give
SERVFAIL instead of NOERROR. The "." is pointed to named.ca which looks
normal.
Post by Linux Addict
Actually I tried +trace from BIND server itself and still get the same
;; global options: +cmd
. 346239 IN NS i.root-servers.new.
. 346239 IN NS c.root-servers.new.
. 346239 IN NS b.root-servers.new.
. 346239 IN NS e.root-servers.new.
. 346239 IN NS d.root-servers.new.
. 346239 IN NS l.root-servers.new.
. 346239 IN NS f.root-servers.new.
. 346239 IN NS j.root-servers.new.
. 346239 IN NS h.root-servers.new.
. 346239 IN NS k.root-servers.new.
. 346239 IN NS m.root-servers.new.
. 346239 IN NS g.root-servers.new.
;; Received 405 bytes from localhost#53(localhost) in 1 ms
Post by Lyle Giese
172.27.254.11 is giving you that info with the .new name servers. You
need to ask whomever manages that server.
Received 405 bytes from 172.27.254.11#53(172.27.254.11) in 1 ms
Lyle
Additional info - general: warning: checkhints: unable to find root NS
'b.root-servers.new' in hints
​I cant seem to find where the ".new" coming from...​
Post by Linux Addict
The named.ca seems good.
. 518400 IN NS C.ROOT-SERVERS.NET.
. 518400 IN NS I.ROOT-SERVERS.NET.
. 518400 IN NS F.ROOT-SERVERS.NET.
. 518400 IN NS B.ROOT-SERVERS.NET.
. 518400 IN NS L.ROOT-SERVERS.NET.
. 518400 IN NS D.ROOT-SERVERS.NET.
. 518400 IN NS J.ROOT-SERVERS.NET.
. 518400 IN NS K.ROOT-SERVERS.NET.
. 518400 IN NS E.ROOT-SERVERS.NET.
. 518400 IN NS A.ROOT-SERVERS.NET.
. 518400 IN NS M.ROOT-SERVERS.NET.
. 518400 IN NS G.ROOT-SERVERS.NET.
. 518400 IN NS H.ROOT-SERVERS.NET.
Post by Lyle Giese
If I remember right, DIG does not know the root servers and asks the
local host to retrieve that information and a server at 172.27.254.11(which
is RFC 1918 address space) gave you that answer.
Is your machine/shop setup with private root servers?
Lyle
I do dig . +trace and the results seem show .new servers. This is
causing SERVFAIL for root query. Any ideas?
dig . +trace
; <<>> DiG 9.7.0-P1 <<>> . +trace
;; global options: +cmd
. 348510 IN NS b.root-servers.new.
. 348510 IN NS h.root-servers.new.
. 348510 IN NS l.root-servers.new.
. 348510 IN NS f.root-servers.new.
. 348510 IN NS m.root-servers.new.
. 348510 IN NS k.root-servers.new.
. 348510 IN NS i.root-servers.new.
. 348510 IN NS e.root-servers.new.
. 348510 IN NS g.root-servers.new.
. 348510 IN NS j.root-servers.new.
. 348510 IN NS c.root-servers.new.
. 348510 IN NS d.root-servers.new.
;; Received 405 bytes from 172.27.254.11#53(172.27.254.11) in 1 ms
;; connection timed out; no servers could be reached
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to
unsubscribe from this list
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to
unsubscribe from this list
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users
Leonard Mills
2015-02-03 19:56:25 UTC
Permalink
Post by Linux Addict
Let me take a step back. The original problem is "dig ."
would give SERVFAIL instead of NOERROR. 
The "." is pointed to named.ca which looks normal.
Without source code changes to your tools and/or replacement
hints files "." invariably points to the root servers to be used by the (possibly local) DNS toolset.
HTH,Len



On Tuesday, February 3, 2015 11:47 AM, Linux Addict <***@gmail.com> wrote:


Actually I tried +trace from BIND server itself and still get the same answer. I did "dig . +trace @localhost"

; <<>> DiG 9.7.0-P1 <<>> . +trace @localhost;; global options: +cmd.                       346239  IN      NS      i.root-servers.new..                       346239  IN      NS      c.root-servers.new..                       346239  IN      NS      b.root-servers.new..                       346239  IN      NS      e.root-servers.new..                       346239  IN      NS      d.root-servers.new..                       346239  IN      NS      l.root-servers.new..                       346239  IN      NS      f.root-servers.new..                       346239  IN      NS      j.root-servers.new..                       346239  IN      NS      h.root-servers.new..                       346239  IN      NS      k.root-servers.new..                       346239  IN      NS      m.root-servers.new..                       346239  IN      NS      g.root-servers.new.;; Received 405 bytes from localhost#53(localhost) in 1 ms

On Tue, Feb 3, 2015 at 2:19 PM, Lyle Giese <***@lcrcomputer.net> wrote:

172.27.254.11 is giving you that info with the .new name servers.  You need to ask whomever manages that server.

Look at this line from your +trace output:

Received 405 bytes from 172.27.254.11#53(172.27.254.11) in 1 ms

Lyle

On 2/3/2015 1:13 PM, Linux Addict wrote:

Additional info - general: warning: checkhints: unable to find root NS 'b.root-servers.new' in hints
​I cant seem to find where the ".new" coming from...​

On Tue, Feb 3, 2015 at 2:07 PM, Linux Addict <***@gmail.com> wrote:

The named.ca seems good.
;; ANSWER SECTION: .                       518400  IN      NS      C.ROOT-SERVERS.NET. .                       518400  IN      NS      I.ROOT-SERVERS.NET. .                       518400  IN      NS      F.ROOT-SERVERS.NET. .                       518400  IN      NS      B.ROOT-SERVERS.NET. .                       518400  IN      NS      L.ROOT-SERVERS.NET. .                       518400  IN      NS      D.ROOT-SERVERS.NET. .                       518400  IN      NS      J.ROOT-SERVERS.NET. .                       518400  IN      NS      K.ROOT-SERVERS.NET. .                       518400  IN      NS      E.ROOT-SERVERS.NET. .                       518400  IN      NS      A.ROOT-SERVERS.NET. .                       518400  IN      NS      M.ROOT-SERVERS.NET. .                       518400  IN      NS      G.ROOT-SERVERS.NET. .                       518400  IN      NS      H.ROOT-SERVERS.NET.


On Tue, Feb 3, 2015 at 2:02 PM, Lyle Giese <***@lcrcomputer.net> wrote:

If I remember right, DIG does not know the root servers and asks the local host to retrieve that information and a server at 172.27.254.11(which is RFC 1918 address space) gave you that answer.

Is your machine/shop setup with private root servers?

Lyle

On 2/3/2015 12:50 PM, Linux Addict wrote:

I do dig . +trace and the results seem show .new servers. This is causing SERVFAIL for root query. Any ideas?
 dig . +trace
; <<>> DiG 9.7.0-P1 <<>> . +trace ;; global options: +cmd .                       348510  IN      NS      b.root-servers.new. .                       348510  IN      NS      h.root-servers.new. .                       348510  IN      NS      l.root-servers.new. .                       348510  IN      NS      f.root-servers.new. .                       348510  IN      NS      m.root-servers.new. .                       348510  IN      NS      k.root-servers.new. .                       348510  IN      NS      i.root-servers.new. .                       348510  IN      NS      e.root-servers.new. .                       348510  IN      NS      g.root-servers.new. .                       348510  IN      NS      j.root-servers.new. .                       348510  IN      NS      c.root-servers.new. .                       348510  IN      NS      d.root-servers.new. ;; Received 405 bytes from 172.27.254.11#53(172.27.254.11) in 1 ms
;; connection timed out; no servers could be reached


_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
bind-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
bind-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users







_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
bind-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users



_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
bind-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Linux Addict
2015-02-03 20:05:20 UTC
Permalink
There was nothing changed on the system since 2012. The behavior changed
all of sudden. I am just curious where dig got root servers like "
b.root-servers.new.".
Post by Leonard Mills
Post by Linux Addict
Let me take a step back. The original problem is "dig ."
would give SERVFAIL instead of NOERROR.
The "." is pointed to named.ca which looks normal.
Without source code changes to your tools and/or replacement
hints files "." invariably points to the root servers to be used by the
(possibly local) DNS toolset.
HTH,
Len
On Tuesday, February 3, 2015 11:47 AM, Linux Addict <
Actually I tried +trace from BIND server itself and still get the same
;; global options: +cmd
. 346239 IN NS i.root-servers.new.
. 346239 IN NS c.root-servers.new.
. 346239 IN NS b.root-servers.new.
. 346239 IN NS e.root-servers.new.
. 346239 IN NS d.root-servers.new.
. 346239 IN NS l.root-servers.new.
. 346239 IN NS f.root-servers.new.
. 346239 IN NS j.root-servers.new.
. 346239 IN NS h.root-servers.new.
. 346239 IN NS k.root-servers.new.
. 346239 IN NS m.root-servers.new.
. 346239 IN NS g.root-servers.new.
;; Received 405 bytes from localhost#53(localhost) in 1 ms
172.27.254.11 is giving you that info with the .new name servers. You
need to ask whomever manages that server.
Received 405 bytes from 172.27.254.11#53(172.27.254.11) in 1 ms
Lyle
Additional info - general: warning: checkhints: unable to find root NS
'b.root-servers.new' in hints
​I cant seem to find where the ".new" coming from...​
The named.ca seems good.
. 518400 IN NS C.ROOT-SERVERS.NET
<http://c.root-servers.net/>.
. 518400 IN NS I.ROOT-SERVERS.NET
<http://i.root-servers.net/>.
. 518400 IN NS F.ROOT-SERVERS.NET
<http://f.root-servers.net/>.
. 518400 IN NS B.ROOT-SERVERS.NET
<http://b.root-servers.net/>.
. 518400 IN NS L.ROOT-SERVERS.NET
<http://l.root-servers.net/>.
. 518400 IN NS D.ROOT-SERVERS.NET
<http://d.root-servers.net/>.
. 518400 IN NS J.ROOT-SERVERS.NET
<http://j.root-servers.net/>.
. 518400 IN NS K.ROOT-SERVERS.NET
<http://k.root-servers.net/>.
. 518400 IN NS E.ROOT-SERVERS.NET
<http://e.root-servers.net/>.
. 518400 IN NS A.ROOT-SERVERS.NET
<http://a.root-servers.net/>.
. 518400 IN NS M.ROOT-SERVERS.NET
<http://m.root-servers.net/>.
. 518400 IN NS G.ROOT-SERVERS.NET
<http://g.root-servers.net/>.
. 518400 IN NS H.ROOT-SERVERS.NET
<http://h.root-servers.net/>.
If I remember right, DIG does not know the root servers and asks the
local host to retrieve that information and a server at 172.27.254.11(which
is RFC 1918 address space) gave you that answer.
Is your machine/shop setup with private root servers?
Lyle
I do dig . +trace and the results seem show .new servers. This is
causing SERVFAIL for root query. Any ideas?
dig . +trace
; <<>> DiG 9.7.0-P1 <<>> . +trace
;; global options: +cmd
. 348510 IN NS b.root-servers.new.
. 348510 IN NS h.root-servers.new.
. 348510 IN NS l.root-servers.new.
. 348510 IN NS f.root-servers.new.
. 348510 IN NS m.root-servers.new.
. 348510 IN NS k.root-servers.new.
. 348510 IN NS i.root-servers.new.
. 348510 IN NS e.root-servers.new.
. 348510 IN NS g.root-servers.new.
. 348510 IN NS j.root-servers.new.
. 348510 IN NS c.root-servers.new.
. 348510 IN NS d.root-servers.new.
;; Received 405 bytes from 172.27.254.11#53(172.27.254.11) in 1 ms
;; connection timed out; no servers could be reached
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to
unsubscribe from this list
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to
unsubscribe from this list
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to
unsubscribe from this list
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users
Robert Edmonds
2015-02-03 21:39:06 UTC
Permalink
Post by Mukund Sivaraman
Post by Linux Addict
I do dig . +trace and the results seem show .new servers. This is
causing SERVFAIL for root query. Any ideas?
dig . +trace
Contact the person who runs the resolver at 172.27.254.11 and report the
problem about the root hints. dig +trace uses the configured resolver to
only find the root nameservers, and directly does lookups afterwards.
Also note that there are only two bits different between ascii 't'
(01110100) and ascii 'w' (01110111). Most likely the root cause is
memory corruption somewhere, rather than any sort of intentional or
unintentional misconfiguration.

See, e.g.:

http://dinaburg.org/bitsquatting.html

https://www.verisigninc.com/assets/VRSN_Bitsquatting_TR_20120320.pdf

http://mina.naguib.ca/blog/2012/10/22/the-little-ssh-that-sometimes-couldnt.html
--
Robert Edmonds
Linux Addict
2015-02-03 21:41:45 UTC
Permalink
Thanks all for your inputs!!
Post by Robert Edmonds
Post by Mukund Sivaraman
Post by Linux Addict
I do dig . +trace and the results seem show .new servers. This is
causing SERVFAIL for root query. Any ideas?
dig . +trace
Contact the person who runs the resolver at 172.27.254.11 and report the
problem about the root hints. dig +trace uses the configured resolver to
only find the root nameservers, and directly does lookups afterwards.
Also note that there are only two bits different between ascii 't'
(01110100) and ascii 'w' (01110111). Most likely the root cause is
memory corruption somewhere, rather than any sort of intentional or
unintentional misconfiguration.
http://dinaburg.org/bitsquatting.html
https://www.verisigninc.com/assets/VRSN_Bitsquatting_TR_20120320.pdf
http://mina.naguib.ca/blog/2012/10/22/the-little-ssh-that-sometimes-couldnt.html
--
Robert Edmonds
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to
unsubscribe from this list
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users
Loading...