nsd users - Mar 2009 - Records below delegation point

I have a question for the NSD developers. I have a zone defined as follows:

$ORIGIN zone.tld.
@	IN	SOA ns1 rname 20090309 1d 1h 4w 1h
	IN	NS ns1
	IN	NS ns2
;
child	IN	NS foo.example.
	IN	NS bar.example.
;
sub.child	IN	NS some.more
		IN	NS yet.more

If I query an NSD 3.x server for NS records for sub.child.zone.tld, I
get back an authoritative answer with "some.more." and
"yet.more.".

Just for comparison, tinydns does the same thing.

However, BIND 9 responds with "foo.example." and
"bar.example.".

My understanding is that an authoritative name server should not know
about records below a delegation point, so BIND's behaviour seems okay.
Why does NSD respond with answers for records below the delegation point?

Is there a standard which defines what an authoritative server should do
 with a zone like this?

At the moment, BIND and NSD exhibit opposite behaviour, which could lead
to interesting situations where a particular zone has such a delegation,
and a mix of BIND and NSD among its name server set.

-- 
Anand Buddhdev
DNS Services Manager, RIPE NCC

On Mon, Mar 09, 2009 at 06:19:07PM +0100,
 Anand Buddhdev <anandb at ripe.net> wrote 
 a message of 38 lines which said:
> My understanding is that an authoritative name server should not
> know about records below a delegation point, so BIND's behaviour
> seems okay.
Indeed. IMHO, it is a bug in NSD. It should not have loaded the zone
or at least ignored the below-the-cut records.
> Is there a standard which defines what an authoritative server
> should do with a zone like this?
RFC 1034 has a lot of sentences like (section 4.2.1):

The authoritative data for a zone is simply all of the RRs attached to
all of the nodes from the top node of the zone down to leaf nodes or
nodes above cuts around the bottom edge of the zone.

Hi Anand,

The way I read it is that zone.tld. is delegating the subdomains child
and sub.child. According to RFC 1034, only NS RRsets may appear at the
parental side of a zone cut. RFC 2181 clarifies that no data below the
zone cut may appear at the parental side.

The behavior of what to do with such a zone is undefined. NSD considers
this an operator error. Because of the explicit no end-user friendliness
requirement, NSD has not built in a detailed zone garbage detection.
As the result of the operator error, NSD behaves incorrectly.

Kind regards,

Matthijs Mekking
NLnet Labs

Anand Buddhdev wrote:
> I have a question for the NSD developers. I have a zone defined as follows:
> 
> $ORIGIN zone.tld.
> @	IN	SOA ns1 rname 20090309 1d 1h 4w 1h
> 	IN	NS ns1
> 	IN	NS ns2
> ;
> child	IN	NS foo.example.
> 	IN	NS bar.example.
> ;
> sub.child	IN	NS some.more
> 		IN	NS yet.more
> 
> If I query an NSD 3.x server for NS records for sub.child.zone.tld, I
> get back an authoritative answer with "some.more." and
"yet.more.".
> 
> Just for comparison, tinydns does the same thing.
> 
> However, BIND 9 responds with "foo.example." and
"bar.example.".
> 
> My understanding is that an authoritative name server should not know
> about records below a delegation point, so BIND's behaviour seems okay.
> Why does NSD respond with answers for records below the delegation point?
> 
> Is there a standard which defines what an authoritative server should do
>  with a zone like this?
> 
> At the moment, BIND and NSD exhibit opposite behaviour, which could lead
> to interesting situations where a particular zone has such a delegation,
> and a mix of BIND and NSD among its name server set.
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 544 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.nlnetlabs.nl/pipermail/nsd-users/attachments/20090310/af5422e4/attachment.bin>