[nsd-users] Records below delegation point

[Matthijs Mekking]

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>