error (unexpected RCODE REFUSED) resolving

2012-10-12 Thread James Tingler
Hello,
 
I'm getting what appears to be a common error (unexpected RCODE REFUSED) 
resolving error.  My research has lead me to disable IPv6 when starting the 
named service with named -4 as it could be related to IPv6 broken 
connectivity (of which we been actively deploying and testing).  This has taken 
away the  log activity but I still get the error:
 
Oct 12 16:06:55 prod75-dns1 named[23866]: error (unexpected RCODE REFUSED) 
resolving 'nbc.com/A/IN': 205.173.93.213#53
 
Exploring this more, almost all domains I'm having problems with (as discovered 
through dig) is related to this forwarder:
nationalmap.gov. 5M IN NS rdsdns5.ultradns.net. nationalmap.gov. 5M IN NS 
rdsdns1.ultradns.net. nationalmap.gov. 5M IN NS rdsdns2.ultradns.net. 
nationalmap.gov. 5M IN NS rdsdns6.ultradns.net. nationalmap.gov. 5M IN NS 
rdsdns3.ultradns.net. nationalmap.gov. 5M IN NS 
rdsdns4.ultradns.net.linkedin.com, nbc.com, nationalmap.govAlso having problems 
with CNN but that is not ultradns.Note - I'm also seeing plenty of lame server 
and EDNS errors. Any help would be appreciated. 
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: error (unexpected RCODE REFUSED) resolving

2012-10-12 Thread Kevin Darcy

On 10/12/2012 12:28 PM, James Tingler wrote:

Hello,
I'm getting what appears to be a common error (unexpected RCODE 
REFUSED) resolving error.  My research has lead me to disable IPv6 
when starting the named service with named -4 as it could be related 
to IPv6 broken connectivity (of which we been actively deploying and 
testing).  This has taken away the  log activity but I still get 
the error:
Oct 12 16:06:55 prod75-dns1 named[23866]: error (unexpected RCODE 
REFUSED) resolving 'nbc.com/A/IN': 205.173.93.213#53
Exploring this more, almost all domains I'm having problems with (as 
discovered through dig) is related to this forwarder:

nationalmap.gov.5M IN NSrdsdns5.ultradns.net.
nationalmap.gov.5M IN NSrdsdns1.ultradns.net.
nationalmap.gov.5M IN NSrdsdns2.ultradns.net.
nationalmap.gov.5M IN NSrdsdns6.ultradns.net.
nationalmap.gov.5M IN NSrdsdns3.ultradns.net.
nationalmap.gov.5M IN NSrdsdns4.ultradns.net.
linkedin.com, nbc.com, nationalmap.gov

nbc.com is not hosted on those nameservers:

nbc.com.86400   IN  NS  pdns1.ultradns.net.
nbc.com.86400   IN  NS  pdns2.ultradns.net.
nbc.com.86400   IN  NS  pdns3.ultradns.org.
nbc.com.86400   IN  NS  pdns4.ultradns.org.
nbc.com.86400   IN  NS  pdns5.ultradns.info.
nbc.com.86400   IN  NS pdns6.ultradns.co.uk.
nbc.com.86400   IN  NS  ns1.netbcp.com.
nbc.com.86400   IN  NS  ns2.netbcp.net.

Neither is linkedin.com.

I hope you're not trying to use authoritative nameservers as 
forwarders in the strict BIND sense. If you have full Internet 
connectivity, there's really no reason to be forwarding at all. 
Configure your root hints and be happy.




Note - I'm also seeing plenty of lame server and EDNS errors.

Those are fairly normal.

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

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

Re: error (unexpected RCODE REFUSED) resolving

2012-10-12 Thread James Tingler
I don't think that I am.  I only define internal forwarders for internal zones 
as needed.  For my root hint, standard configuration:
Named.conf
 
zone . {
type hint;
file named.ca;
Named.ca:
 
;  DiG 9.5.0b2  +bufsize=1200 +norec NS . @a.root-servers.net
;; global options:  printcmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 34420
;; flags: qr aa; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 20
 
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;.  IN  NS
 
;; ANSWER SECTION:
.   518400  IN  NS  M.ROOT-SERVERS.NET.
.   518400  IN  NS  A.ROOT-SERVERS.NET.
.   518400  IN  NS  B.ROOT-SERVERS.NET.
.   518400  IN  NS  C.ROOT-SERVERS.NET.
.   518400  IN  NS  D.ROOT-SERVERS.NET.
.   518400  IN  NS  E.ROOT-SERVERS.NET.
.   518400  IN  NS  F.ROOT-SERVERS.NET.
.   518400  IN  NS  G.ROOT-SERVERS.NET.
.   518400  IN  NS  H.ROOT-SERVERS.NET.
.   518400  IN  NS  I.ROOT-SERVERS.NET.
.   518400  IN  NS  J.ROOT-SERVERS.NET.
.   518400  IN  NS  K.ROOT-SERVERS.NET.
.   518400  IN  NS  L.ROOT-SERVERS.NET.
 
;; ADDITIONAL SECTION:
A.ROOT-SERVERS.NET. 360 IN  A   198.41.0.4
A.ROOT-SERVERS.NET. 360 IN  2001:503:ba3e::2:30
B.ROOT-SERVERS.NET. 360 IN  A   192.228.79.201
C.ROOT-SERVERS.NET. 360 IN  A   192.33.4.12
D.ROOT-SERVERS.NET. 360 IN  A   128.8.10.90
E.ROOT-SERVERS.NET. 360 IN  A   192.203.230.10
F.ROOT-SERVERS.NET. 360 IN  A   192.5.5.241
F.ROOT-SERVERS.NET. 360 IN  2001:500:2f::f
G.ROOT-SERVERS.NET. 360 IN  A   192.112.36.4
H.ROOT-SERVERS.NET. 360 IN  A   128.63.2.53
H.ROOT-SERVERS.NET. 360 IN  2001:500:1::803f:235
I.ROOT-SERVERS.NET. 360 IN  A   192.36.148.17
J.ROOT-SERVERS.NET. 360 IN  A   192.58.128.30
J.ROOT-SERVERS.NET. 360 IN  2001:503:c27::2:30
K.ROOT-SERVERS.NET. 360 IN  A   193.0.14.129
K.ROOT-SERVERS.NET. 360 IN  2001:7fd::1
L.ROOT-SERVERS.NET. 360 IN  A   199.7.83.42
M.ROOT-SERVERS.NET. 360 IN  A   202.12.27.33
M.ROOT-SERVERS.NET. 360 IN  2001:dc3::35
 
;; Query time: 147 msec
;; SERVER: 198.41.0.4#53(198.41.0.4)
;; WHEN: Mon Feb 18 13:29:18 2008
;; MSG SIZE  rcvd: 615

named.ca 52L, 1892C


 Kevin Darcy k...@chrysler.com 10/12/2012 1:20 PM 
On 10/12/2012 12:28 PM, James Tingler wrote:


Hello,
 
I'm getting what appears to be a common error (unexpected RCODE REFUSED) 
resolving error.  My research has lead me to disable IPv6 when starting the 
named service with named -4 as it could be related to IPv6 broken 
connectivity (of which we been actively deploying and testing).  This has taken 
away the  log activity but I still get the error:
 
Oct 12 16:06:55 prod75-dns1 named[23866]: error (unexpected RCODE REFUSED) 
resolving 'nbc.com/A/IN': 205.173.93.213#53
 
Exploring this more, almost all domains I'm having problems with (as discovered 
through dig) is related to this forwarder:
nationalmap.gov. 5M IN NS rdsdns5.ultradns.net. nationalmap.gov. 5M IN NS 
rdsdns1.ultradns.net. nationalmap.gov. 5M IN NS rdsdns2.ultradns.net. 
nationalmap.gov. 5M IN NS rdsdns6.ultradns.net. nationalmap.gov. 5M IN NS 
rdsdns3.ultradns.net. nationalmap.gov. 5M IN NS 
rdsdns4.ultradns.net.linkedin.com, nbc.com, nationalmap.gov
nbc.com is not hosted on those nameservers:

nbc.com.86400   IN  NS  pdns1.ultradns.net.
nbc.com.86400   IN  NS  pdns2.ultradns.net.
nbc.com.86400   IN  NS  pdns3.ultradns.org.
nbc.com.86400   IN  NS  pdns4.ultradns.org.
nbc.com.86400   IN  NS  pdns5.ultradns.info.
nbc.com.86400   IN  NS  pdns6.ultradns.co.uk.
nbc.com.86400   IN  NS  ns1.netbcp.com.
nbc.com.86400   IN  NS  ns2.netbcp.net.

Neither is linkedin.com.

I hope you're not trying to use authoritative nameservers as forwarders in 
the strict BIND sense. If you have full Internet connectivity, there's really 
no reason to be forwarding at all. Configure your root hints and be happy.




Note - I'm also seeing plenty of lame server and EDNS errors. 
Those are fairly normal.

- Kevin
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 

Re: error (unexpected RCODE REFUSED) resolving

2012-10-12 Thread Kevin Darcy
OK, so your nbc.com/A resolving error doesn't really have anything to do 
with the nameservers you included in your original post.


It does appear, however, that ns2.netbcp.net (205.173.93.213) is 
refusing requests generally for the nbc.com domain:


$  dig nbc.com +buf=4096 +norec @ns2.netbcp.net

;  DiG 9.4.3-P3  nbc.com +buf=4096 +norec @ns2.netbcp.net
;; global options:  printcmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: REFUSED, id: 1019
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;nbc.com.   IN  A

;; Query time: 30 msec
;; SERVER: 205.173.93.213#53(205.173.93.213)
;; WHEN: Fri Oct 12 13:44:56 2012
;; MSG SIZE  rcvd: 36

ns1.netbcp.com appears to be doing the same thing.

Not known whether this is something temporary (performing maintenance?), 
or something permanent (provider's contract lapsed, but customer never 
updated delegations).


In any case, you have enough working authoritative nameservers for the 
domain, so it'll continue to resolve for you...


- Kevin



On 10/12/2012 1:35 PM, James Tingler wrote:
I don't think that I am.  I only define internal forwarders for 
internal zones as needed.  For my root hint, standard configuration:

Named.conf
zone . {
type hint;
file named.ca;
Named.ca:
;  DiG 9.5.0b2  +bufsize=1200 +norec NS . @a.root-servers.net
;; global options:  printcmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 34420
;; flags: qr aa; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 20
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;.  IN  NS
;; ANSWER SECTION:
.   518400  IN  NS M.ROOT-SERVERS.NET.
.   518400  IN  NS A.ROOT-SERVERS.NET.
.   518400  IN  NS B.ROOT-SERVERS.NET.
.   518400  IN  NS C.ROOT-SERVERS.NET.
.   518400  IN  NS D.ROOT-SERVERS.NET.
.   518400  IN  NS E.ROOT-SERVERS.NET.
.   518400  IN  NS F.ROOT-SERVERS.NET.
.   518400  IN  NS G.ROOT-SERVERS.NET.
.   518400  IN  NS H.ROOT-SERVERS.NET.
.   518400  IN  NS I.ROOT-SERVERS.NET.
.   518400  IN  NS J.ROOT-SERVERS.NET.
.   518400  IN  NS K.ROOT-SERVERS.NET.
.   518400  IN  NS L.ROOT-SERVERS.NET.
;; ADDITIONAL SECTION:
A.ROOT-SERVERS.NET. 360 IN  A   198.41.0.4
A.ROOT-SERVERS.NET. 360 IN   2001:503:ba3e::2:30
B.ROOT-SERVERS.NET. 360 IN  A   192.228.79.201
C.ROOT-SERVERS.NET. 360 IN  A   192.33.4.12
D.ROOT-SERVERS.NET. 360 IN  A   128.8.10.90
E.ROOT-SERVERS.NET. 360 IN  A   192.203.230.10
F.ROOT-SERVERS.NET. 360 IN  A   192.5.5.241
F.ROOT-SERVERS.NET. 360 IN  2001:500:2f::f
G.ROOT-SERVERS.NET. 360 IN  A   192.112.36.4
H.ROOT-SERVERS.NET. 360 IN  A   128.63.2.53
H.ROOT-SERVERS.NET. 360 IN   2001:500:1::803f:235
I.ROOT-SERVERS.NET. 360 IN  A   192.36.148.17
J.ROOT-SERVERS.NET. 360 IN  A   192.58.128.30
J.ROOT-SERVERS.NET. 360 IN   2001:503:c27::2:30
K.ROOT-SERVERS.NET. 360 IN  A   193.0.14.129
K.ROOT-SERVERS.NET. 360 IN  2001:7fd::1
L.ROOT-SERVERS.NET. 360 IN  A   199.7.83.42
M.ROOT-SERVERS.NET. 360 IN  A   202.12.27.33
M.ROOT-SERVERS.NET. 360 IN  2001:dc3::35
;; Query time: 147 msec
;; SERVER: 198.41.0.4#53(198.41.0.4)
;; WHEN: Mon Feb 18 13:29:18 2008
;; MSG SIZE  rcvd: 615

named.ca 52L, 1892C


 Kevin Darcy k...@chrysler.com 10/12/2012 1:20 PM 
On 10/12/2012 12:28 PM, James Tingler wrote:

Hello,
I'm getting what appears to be a common error (unexpected RCODE 
REFUSED) resolving error.  My research has lead me to disable IPv6 
when starting the named service with named -4 as it could be 
related to IPv6 broken connectivity (of which we been actively 
deploying and testing).  This has taken away the  log activity 
but I still get the error:
Oct 12 16:06:55 prod75-dns1 named[23866]: error (unexpected RCODE 
REFUSED) resolving 'nbc.com/A/IN': 205.173.93.213#53
Exploring this more, almost all domains I'm having problems with (as 
discovered through dig) is related to this forwarder:

nationalmap.gov.5M IN NSrdsdns5.ultradns.net.
nationalmap.gov.5M IN NSrdsdns1.ultradns.net.
nationalmap.gov.5M IN NSrdsdns2.ultradns.net.
nationalmap.gov.5M IN NSrdsdns6.ultradns.net.
nationalmap.gov.5M IN NSrdsdns3.ultradns.net.
nationalmap.gov.5M IN NS

Re: error (unexpected RCODE REFUSED) resolving

2012-10-12 Thread James Tingler
Actually, I'm getting mostly no resolution for these sites.  Ever so often I 
will get resolution after multiple nslookup attempts.  
 
Another weird thing that happened today is with the named -4 trigger, my 
internal resolution broke.  I killed the named service and started bind 
normally so now I'm back to all the  request in my logs.

 Kevin Darcy k...@chrysler.com 10/12/2012 1:47 PM 
OK, so your nbc.com/A resolving error doesn't really have anything to do with 
the nameservers you included in your original post.

It does appear, however, that ns2.netbcp.net (205.173.93.213) is refusing 
requests generally for the nbc.com domain:

$  dig nbc.com +buf=4096 +norec @ns2.netbcp.net

;  DiG 9.4.3-P3  nbc.com +buf=4096 +norec @ns2.netbcp.net
;; global options:  printcmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: REFUSED, id: 1019
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;nbc.com.   IN  A

;; Query time: 30 msec
;; SERVER: 205.173.93.213#53(205.173.93.213)
;; WHEN: Fri Oct 12 13:44:56 2012
;; MSG SIZE  rcvd: 36

ns1.netbcp.com appears to be doing the same thing.

Not known whether this is something temporary (performing maintenance?), or 
something permanent (provider's contract lapsed, but customer never updated 
delegations).

In any case, you have enough working authoritative nameservers for the domain, 
so it'll continue to resolve for you...


- Kevin



On 10/12/2012 1:35 PM, James Tingler wrote:


I don't think that I am.  I only define internal forwarders for internal zones 
as needed.  For my root hint, standard configuration:
Named.conf
 
zone . {
type hint;
file named.ca;
Named.ca:
 
;  DiG 9.5.0b2  +bufsize=1200 +norec NS . @a.root-servers.net
;; global options:  printcmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 34420
;; flags: qr aa; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 20
 
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;.  IN  NS
 
;; ANSWER SECTION:
.   518400  IN  NS  M.ROOT-SERVERS.NET.
.   518400  IN  NS  A.ROOT-SERVERS.NET.
.   518400  IN  NS  B.ROOT-SERVERS.NET.
.   518400  IN  NS  C.ROOT-SERVERS.NET.
.   518400  IN  NS  D.ROOT-SERVERS.NET.
.   518400  IN  NS  E.ROOT-SERVERS.NET.
.   518400  IN  NS  F.ROOT-SERVERS.NET.
.   518400  IN  NS  G.ROOT-SERVERS.NET.
.   518400  IN  NS  H.ROOT-SERVERS.NET.
.   518400  IN  NS  I.ROOT-SERVERS.NET.
.   518400  IN  NS  J.ROOT-SERVERS.NET.
.   518400  IN  NS  K.ROOT-SERVERS.NET.
.   518400  IN  NS  L.ROOT-SERVERS.NET.
 
;; ADDITIONAL SECTION:
A.ROOT-SERVERS.NET. 360 IN  A   198.41.0.4
A.ROOT-SERVERS.NET. 360 IN  2001:503:ba3e::2:30
B.ROOT-SERVERS.NET. 360 IN  A   192.228.79.201
C.ROOT-SERVERS.NET. 360 IN  A   192.33.4.12
D.ROOT-SERVERS.NET. 360 IN  A   128.8.10.90
E.ROOT-SERVERS.NET. 360 IN  A   192.203.230.10
F.ROOT-SERVERS.NET. 360 IN  A   192.5.5.241
F.ROOT-SERVERS.NET. 360 IN  2001:500:2f::f
G.ROOT-SERVERS.NET. 360 IN  A   192.112.36.4
H.ROOT-SERVERS.NET. 360 IN  A   128.63.2.53
H.ROOT-SERVERS.NET. 360 IN  2001:500:1::803f:235
I.ROOT-SERVERS.NET. 360 IN  A   192.36.148.17
J.ROOT-SERVERS.NET. 360 IN  A   192.58.128.30
J.ROOT-SERVERS.NET. 360 IN  2001:503:c27::2:30
K.ROOT-SERVERS.NET. 360 IN  A   193.0.14.129
K.ROOT-SERVERS.NET. 360 IN  2001:7fd::1
L.ROOT-SERVERS.NET. 360 IN  A   199.7.83.42
M.ROOT-SERVERS.NET. 360 IN  A   202.12.27.33
M.ROOT-SERVERS.NET. 360 IN  2001:dc3::35
 
;; Query time: 147 msec
;; SERVER: 198.41.0.4#53(198.41.0.4)
;; WHEN: Mon Feb 18 13:29:18 2008
;; MSG SIZE  rcvd: 615

named.ca 52L, 1892C


 Kevin Darcy k...@chrysler.com ( mailto:k...@chrysler.com ) 10/12/2012 
 1:20 PM 
On 10/12/2012 12:28 PM, James Tingler wrote:


Hello,
 
I'm getting what appears to be a common error (unexpected RCODE REFUSED) 
resolving error.  My research has lead me to disable IPv6 when starting the 
named service with named -4 as it could be related to IPv6 broken 
connectivity (of which we been actively deploying and testing).  This has taken 
away the  log activity but I still get the error:
 
Oct 12 16:06:55 

Re: error (unexpected RCODE REFUSED) resolving

2012-10-12 Thread Chris Thompson

On Oct 12 2012, Kevin Darcy wrote:

OK, so your nbc.com/A resolving error doesn't really have anything to do 
with the nameservers you included in your original post.


It does appear, however, that ns2.netbcp.net (205.173.93.213) is 
refusing requests generally for the nbc.com domain:


And so is ns1.netbcp.com [205.173.95.216]. The ultradns servers are
behaving more sensibly. The SOA.mname is ns.ge.com [156.154.67.6],
a hidden[*] master which also gives sensible and authoritative answers.

[*] not *very* hidden :-)

Incidentally, I get a SIGSEGV when going host -C nbc.com, which does
seem to happen when the nameservers for a zone behave abnormally. This
time I have got around to reporting it to bind9-bugs.

--
Chris Thompson
Email: c...@cam.ac.uk
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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


Re: Improved SSL Error Logging [RT #29932]

2012-10-12 Thread Noel Butler
Thanks Mark,

These changes have been committed for future patch releases?


Cheers

On Fri, 2012-10-12 at 12:16 +1100, Mark Andrews wrote:


 
 Just drop the log level to ISC_LOG_DEBUG(1) and recompile.
 
 Search for sucessfully validated after lower casing in lib/dns/dnssec.c
  




signature.asc
Description: This is a digitally signed message part
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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