BIND does not answer

2012-10-23 Thread Christian Tardif 

Hi,

I have a strange BIND behaviour I don't know how to handle. As I don't 
exactly know how to describe it, I'll rather explain what I did and what 
happens. But not quite easy to follow.


In my tests, I have two servers with BIND installed on them: SiteA (BIND 
9.8.2rc1 on CentOS 6.3), and SiteB (BIND 9.5.0-P2, on Mandriva 2008.1). 
A third environment helps me for diagnostics.


SiteA is a recursive name server. I've been able to prove that it does 
not behave correctly under certain circumstances by hitting it with a 
simple request: asking it to give me NS records for a certain subdomain 
for which it's primary for the base domain (dig @SiteA NS 
sub.domain.tld, SiteA being authoritative for domain.tld). It just times 
out. There are glue records on SiteA for the sub.domain.tld master 
BIND). In order to try to figure out what was going on, I try, directly 
from SiterA, to send a request, as a client, directly to the master of 
sub.domain.tld. Times out again. At this moment, I can't tell which 
server is faulty. But I ge the same behaviour trying to get an answer 
from a completely different server (SiteB). In that case as well, no 
answer. But still starting from SiteA.


I then tried to get a response for the request I made from SiteA to 
SiteB (as I control both), but this time, starting for my third 
environment. Then, SiteB answers to my request. So SiteB looks like it's 
working. But how come it does not answer my request from SiteA?  From 
BIND logs on siteB, there's no trace of SiteA-to-SiteB' request. In 
order to prove that my UDP packets actually reaches their destination, 
and are not modified during transit, I opened a tcpdump session on SiteA 
and on SiteB. Packets come through in good shape, but didn't find their 
way to BIND application, as it seems. In my opinion, SiteB is not part 
of the problem, as it answers normally to every other it receives from 
anywhere else than SiteA. If I try again SiteA-to-SiteB request, I can 
see with TCPDUMP that packets gets out of SiteA, and enters SiteB. But 
BIND doesn't react. Even if I try to enable debugging on SiteB, I don't 
see anything.


What could be wrong, and how do I solve it? What tools are available to 
help out? If I try to ask for recursive request (let's say 
www.google.com) from anywhere, pointing at SiteA, I get a proper answer.


There's no firewall on either side

--
Christian Tardif

___
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: [DNSSEC] Dealing with an inconsistent NSEC

2012-10-23 Thread Casey Deccio 
On Tue, Oct 23, 2012 at 6:36 AM, Stephane Bortzmeyer wrote:

> On Tue, Oct 23, 2012 at 06:27:12AM -0700,
>  Casey Deccio  wrote
>  a message of 88 lines which said:
>
> > The issue here is that no delegation NS records exist for
> > v1.pcextreme.nlin its parent zone, pcextreme.nl.  Thus when any
> > server (authoritative for both zones) is queried for
> > v1.pcextreme.nl/DS, NXDOMAIN is returned because there are no
> > records by that name in the parent (no DS or NS).
>
> But it should reply NOERROR,DATA=0, no NXDOMAIN. Indeed,
> pcextreme.nl's name servers reply NXDOMAIN for DS queries but not for
> other QTYPES.
>
> So, no bug in BIND and Unbound, only in the zone?
>

Yes.  Prior to DNSSEC, it used to be that if all servers authoritative for
a parent were also authoritative for the delegated child, then they could
get away with not having any delegation records in the parent.  With DNSSEC
this omission causes these NXDOMAIN issues with validating resolvers when
child is signed and parent has no DS.

Casey
___
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: [DNSSEC] Dealing with an inconsistent NSEC

2012-10-23 Thread Warren Kumari 

On Oct 23, 2012, at 4:08 AM, Stephane Bortzmeyer  wrote:

> It may be a bug in BIND and it is certainly a bug in the zone
> pcextreme.nl.
> 
> BIND validating resolvers are unable to get the IP address of
> v1.pcextreme.nl.
> 
> I believe this is because of the strange NSEC:
> 
> tools-newerst.pcextreme.nl. 2315 IN NSECv2.pcextreme.nl.  RRSIG 
> NSEC
> 
> which says there is nothing between tools-newerst.pcextreme.nl and
> v2.pcextreme.nl (and therefore no v1).
> 
> This is inconsistent since there are also A and  records for
> v1.pcextreme.nl.
> 
> I tested with a BIND and an Unbound, as well as with ODVR
> . Apparently BIND always
> fail and Unbound always succeed, probably because Unbound is happy
> with the A record but BIND uses the (unvalidated, since there is no DS
> in the parent) NSEC to disprove the domain name.
> 
> So, the zone signature system at pcextreme.nl seems broken.

So, we seem to see a fair number of distinctly "odd" DNSSEC zones -- what I'm 
wondering is how / why.

Presumably the operators of pcextreme.nl. didn't sign their zone by hand ("All 
them sums are hard!"), so how does this actually happen?
1: They rolled their own signer?
2: they are using something well known that happened to fail in some odd way?
3: they cut-n-pated the signed rrset from another signed zonefile, not 
realizing that nsec makes a hole?

My guess is on #3, what do others think?

W


> But is
> BIND right to send back NXDOMAIN? RFC 4035, section 5.4 is not obvious
> here.
> 
> ___
> 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
> 

-- 
"I think it would be a good idea." 
- Mahatma Ghandi, when asked what he thought of Western civilization



___
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: [DNSSEC] Dealing with an inconsistent NSEC

2012-10-23 Thread Stephane Bortzmeyer 
On Tue, Oct 23, 2012 at 06:27:12AM -0700,
 Casey Deccio  wrote 
 a message of 88 lines which said:

> The issue here is that no delegation NS records exist for
> v1.pcextreme.nlin its parent zone, pcextreme.nl.  Thus when any
> server (authoritative for both zones) is queried for
> v1.pcextreme.nl/DS, NXDOMAIN is returned because there are no
> records by that name in the parent (no DS or NS).

But it should reply NOERROR,DATA=0, no NXDOMAIN. Indeed,
pcextreme.nl's name servers reply NXDOMAIN for DS queries but not for
other QTYPES.

So, no bug in BIND and Unbound, only in the zone?
___
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: [DNSSEC] Dealing with an inconsistent NSEC

2012-10-23 Thread Casey Deccio 
On Tue, Oct 23, 2012 at 1:08 AM, Stephane Bortzmeyer wrote:

> It may be a bug in BIND and it is certainly a bug in the zone
> pcextreme.nl.
>
> BIND validating resolvers are unable to get the IP address of
> v1.pcextreme.nl.
>
> I believe this is because of the strange NSEC:
>
> tools-newerst.pcextreme.nl. 2315 IN NSECv2.pcextreme.nl. 
> RRSIG NSEC
>
> which says there is nothing between tools-newerst.pcextreme.nl and
> v2.pcextreme.nl (and therefore no v1).
>
> This is inconsistent since there are also A and  records for
> v1.pcextreme.nl.
>
>
The issue here is that no delegation NS records exist for
v1.pcextreme.nlin its parent zone,
pcextreme.nl.  Thus when any server (authoritative for both zones) is
queried for v1.pcextreme.nl/DS, NXDOMAIN is returned because there are no
records by that name in the parent (no DS or NS).  Because BIND looks
upward for DS RRs after validating RRSIGs in v1.pcextreme.nl, it gets the
NXDOMAIN response, which changes the cache's understandingof
v1.pcextreme.nl--specifically that the name doesn't exist.  The results
from your resolver are reflecting that behavior.  unbound perhaps handles
authentication differently, e.g., top-down, so it doesn't ever perform the
DS query and thus never receives NXDOMAIN for the name.

See also the delegation warning at:
http://dnsviz.net/d/v1.pcextreme.nl/UIY0lg/dnssec/

Casey
___
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

[DNSSEC] Dealing with an inconsistent NSEC

2012-10-23 Thread Stephane Bortzmeyer 
It may be a bug in BIND and it is certainly a bug in the zone
pcextreme.nl.

BIND validating resolvers are unable to get the IP address of
v1.pcextreme.nl.

I believe this is because of the strange NSEC:

tools-newerst.pcextreme.nl. 2315 IN NSECv2.pcextreme.nl.  RRSIG NSEC

which says there is nothing between tools-newerst.pcextreme.nl and
v2.pcextreme.nl (and therefore no v1).

This is inconsistent since there are also A and  records for
v1.pcextreme.nl.

I tested with a BIND and an Unbound, as well as with ODVR
. Apparently BIND always
fail and Unbound always succeed, probably because Unbound is happy
with the A record but BIND uses the (unvalidated, since there is no DS
in the parent) NSEC to disprove the domain name.

So, the zone signature system at pcextreme.nl seems broken. But is
BIND right to send back NXDOMAIN? RFC 4035, section 5.4 is not obvious
here.

___
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