Subject: question about draft-ietf-dnsext-dnssec-records-06

From: David Blacka <[email-masked]>
Date: Mon, 12 Jan 2004 17:34:41 -0500

When carefully reviewing this excellent document, I came across this 
sentence in section 4.1.1:

   Owner names of RRsets not authoritative for the given zone (such as
   glue records) MUST NOT be listed in the Next Domain Name unless at
   least one authoritative RRset exists at the same owner name.

which made me think of this "unless" case.  If an authoritive RRset exists 
at the same owner name as glue, what should the type map look like?

Intuitively, it should contain the types of the authoritative RRsets only, 
but since it isn't specified in the document, I'm only guessing.

Just to make sure folks know what I'm talking about, consider this snippet 
from the "example." zone:

foo.example.     IN NS   ns1.foo.example.
foo.example.     IN NS   foo.example.
foo.example.     IN A    1.2.3.5
ns1.foo.example. IN A    1.2.3.4
foo.example.     IN NSEC foo2.example. (A?) NS RRSIG NSEC
foo.example.     IN RRSIG NSEC ...

which I think is a valid illustration of this case.

Whatever the answer is, I think that it should be spelled out in this 
document.

-- 
David Blacka    <[email-masked]> 
Sr. Engineer    Verisign Applied Research

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Ólafur Guðmundsson<[email-masked]>
Date: Wed, 14 Jan 2004 16:33:53 -0500

</chair>

>which I think is a valid illustration of this case.

Yes this is a good illustration of this case.
I can not find any text in any DNS document that outlaws A residing with
a NS in parent. (Not sure anyone does this anyway)

>Whatever the answer is, I think that it should be spelled out in this

It is in a way implied in protocol section 2.2, but it should be spelled
out in records.

In the case of NS the parent is authoritative for the existence
of the name and the type while the child is authoritative for the
contents of the record. Thus the NS is included in the NSEC type
map but not signed.

In the case of NSEC and DS the parent is authoritative for the contents
of them and signs them, thus they appear in the NSEC bit map.

In the case of glue the parent is not authoritative for any part
of the type or content.
For this reason (IMHO) the type should not be listed in the NSEC bit
map.

A different argument is: why should glue that happens to reside at
delegation point get preferential treatment over glue that is below
a delegation point.

With this interpretation of NSEC bitmap at delegations, the contents
of a NSEC at delegation points is always NS [DS] RRSIG NSEC,
this should be spelled out in the documents.

         Olafur (himself not as WG-chair)