Subject: Re: type codes (Re: wildcard optimization and b/w incompatibility )

From: Paul Vixie <[email-masked]>
Date: Fri, 22 Nov 2002 04:50:47 +0000

>   However, I think that DS is probably a good seperation for zone cuts.
> If we can simply make the child pull records from the parent again, then we
> might find a resolution to this problem. The stub zone stuff that bind has
> might be a good model - pull it down when you can and save it. 

it's not reasonable to ask an authoritative server to have to fetch anything
from anybody.  it should not need a root.cache file, it should never have to
ask a udp/53 question other than, perhaps, when a slave server asks a master
for its SOA to find out if "now" is a good time for an AXFR.

>   If you are offline and can not speak to the zone's parent during a key
> rollover is a clear problem here.
> 
>   So, we either find a way to put the DS record CLEARLY in the parent, or
> a way for the CHILD to get a copy of it.

watch for the "ENS RR", coming soon to a namedroppers list near you.

>   BTW: NS also lives in both places, BUT, we don't have failures if the
> child and parent disagree. In fact, this is often a feature for some.

putting crap at the delegation point is hairy business.

--
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: Paul Vixie <[email-masked]>
Date: Sat, 30 Nov 2002 00:59:22 +0000

>   Paul> ... this is just false, and is indicative of other conceptual errors.
> 
>   I agree strongly with you on this - delegations belong to the child.
> 
>   What about DS? The problems identified at the workshop stem PRECISELY from
> the problems with who is authoritative for the DS record. 

yes.  i've got most of a fix ready to propose.  DS as it stands won't work.

> A hack was proposed, whereby the DS record for example.com would be
> actually named as _ds_example.com. This restores the principle that you
> outline above. it would be very nice if we could come up with a solution
> to the DS problem doesn't violate this principal.

agreed.