Re:

[Ólafur Guðmundsson <ogud@ogud.com>]

At 10:04 AM 8/23/2001, Olaf Kolkman wrote:


>Olafur (and others),
>
>I'm trying to figure out what one should get back when querying for a
>DS record or when following the delegation chain.
>
>As a first iteration:
>
>
>I think that when one queries for a DS record explicitly it is clear
>what should be returned in the answer, authority and additional info
>section. This is specified in 2535 section 3.5. The authority bit is
>off-course set.

Yep this is no brainier, but the problem is to teach resolvers to ask
for the DS record at the upper side of the delegation.

>The problem is if one gets a delegation response.
>
>I think It would be good to have the DS record in the additional
>information section of the response, since the parent has knowledge of
>SIG and KEY those should also be added. This behavior is AFAIK not
>according to 2535 sect 3.5 so it may need to be specified in the
>draft.

I specify that DS is added with NS answers in the draft if space.
The thing I have not specified is if DS should have higher or lower
priority than Address records in the additional section.


>Hmmm, would this break things horrendously?
>
>Did anybody already tried to hack DS into bind?


Not yet, I plan on doing that in the next few weeks for Bind-9 and/or
dnsjava.



>--Olaf
>
>
>As an example of what I try to express: Two questions and responses;
>first following a delegation then a query for the DS record.
>
>
>------------------------------
>dig @ns.parent.tld child.parent.tld
>
>aa bit NOT SET.
>;; QUESTION SECTION:
>; child.parent.tld  IN  A
>
>;; ANSWER SECTION:
>;; empty
>
>;; AUTHORITY SECTION:
>child.parent.tld. 172800 IN NS  ns.child.parent.tld
>
>;; ADDITIONAL SECTION:
>child.parent.tld  172800 IN DS [...rdata...]
>child.parent.tld. 172800 IN SIG DS [....] parent.tld [....]
>parent.tld.       172800 IN KEY [....rdata...]
>
>
>
>------------------------------
>dig @ns.parent.tld child.parent.tld DS
>
>aa bit SET.
>;; QUESTION SECTION:
>; child.parent.tld  IN  DS
>
>;; ANSWER SECTION:
>child.parent.tld  172800 IN      DS [...rdata...]
>child.parent.tld. 172800 IN      SIG DS [....] parent.tld [....]
>
>
>;; AUTHORITY SECTION:
>parent.tld. 172800 IN NS        ns.parent.tld
>parent.tld. 172800 IN NS        ns2.parent.tld
>parent.tld. 172800 IN SIG       NS [....] parent.tld [....]
>
>
>;; ADDITIONAL SECTION:
>parent.tld.172800IN     KEY     [...rdata...]


I do not think that the KEY should be in this answer.