Re: draft-ietf-dnsext-rfc2672bis-dname-09.txt

[Paul Vixie <[e-mail]>]

> |> I don't agree that we have to allow obscured records to be loaded.
> |> Why do we "have to"?  Why "(and should be for DNAME)?"
> |
> | 	Because you can't ADD a DNAME which obscures some record
> | 	then STOP and RESTART the server.
> 
> Why do we need obscured records?
> 
> Can't we rule that an added DNAME removes (not obscures) everything
> below it. And nothing can be added below a DNAME.

if the unix "mv" or "cp" command could ever behave like "rm -rf" then the
natural error rate would be high enough, at scale, that a whole lot of
data would get implicitly destroyed, and the behaviour would be changed.

> That would make the draft consistent (but have to say that dynamic
> update for DNAME is different from NS).

we just can't have UPDATE doing implicit "rm -rf".  anyone who wants that
behaviour should code it as successive, explicit UPDATE operations.

> What is the current practice for DNAME and dynamic update in existing
> implementations? How do they handle this - that is what I as an editor
> want to know before introducing another implementation change :-)
> 
> Is it handled exactly like NS records now? In that case - can you
> describe (in text) how that can be put in the draft?

right now there are no special rules for UPDATE on DNAME RRs.  unlike
NS RR it is possible to delete the last DNAME at a zone apex, for example.
(not that this matters, i'm just using it as an example.)  so what we get
at the moment is, if you add a DNAME then the zone beneath that point is
unreachable by the authority server's search algo, and names/records below
that point which have been cached, are still returnable from recursive
servers, who aren't aware of the DNAME.

if you're going to update the DNAME++ spec on this point, i'd say, adding a
DNAME to an existing name (which has either records or children) is not
permitted, and YXDOMAIN should be returned in this case.  i thought that we
had covered this adequately in an earlier thread here.  see attached.

--- Begin Message ---

> Basically yes, but the changes are:

thanks very much for this, and for wouter's answer to the same lazy question
from me.

> Server side
> Old:
> server generated CNAME RRs have TTL=0
> Always generated CNAMEs in response containing DNAME
> 
> New:
> server generated CNAME RRs have TTL = DNAME TTL (some implementations
> already do this)
> 
> Only generate CNAME RRs if the Understand DNAME (UD) bit is NOT set (EDNS0
> flags field - 2nd highest bit requested)

so far so good.

> Server MUST return RCODE=REFUSED to a dynamic update message that would add
> any RR with a domain name under a DNAME RR's ownername.
> 
> Server handles adding DNAME RRs much like adding a NS to a zone (removes
> any domain names that would be under the DNAME ownername).

these are both controversial.  see below.

> Client side
> New:
> If resolver understands DNAME RRs in a response (i.e. follow them without
> the need of a CNAME) set the UD bit in the EDNS0 flags section.

and presumably ignore any presented CNAMEs whose owner matches a presented
DNAME (since not all servers will notice the UD).  but since EDNS is hop/hop
i'm going to ask whether recursive servers are allowed to synthesize CNAME
if there is a cached DNAME and UD=0?  (i don't need to know, it's fine with
me either way, i just hope the draft covers this.)

> If generated CNAMEs present, expect TTL = DNAME TTL or TTL = 0

how does an initiator know whether the presented CNAMEs are synthetic?

> Caches:
> Discussion only
> 
> The rest of the draft is a discussion of DNAME including clarification and
> pulling in sections of other drafts that discuss DNAME RRs.
> 
> I think that's all.  Would it help if this was expanded and included as an
> appendix to the draft?

yes, very much.

---

now for the two controversial UPDATE issues

first, RCODE=REFUSED is defined by RFC 2136 as follows:

              REFUSED     5       The name server refuses to perform the
                                  specified operation for policy or
                                  security reasons.

every RCODE related to UPDATE failure that is dependent on pre-existing zone
content is something other than REFUSED.  by "policy" in the above text, we
really meant something that had a configuration knob, where the knob was in
the "wrong" or incompatible position.  to use RCODE=REFUSED as a data-present
zone content incompatibility would be, in my opinion, the wrong thing to do.

i propose that RCODE=YXDOMAIN be used instead:

              YXDOMAIN    6       Some name that ought not to exist,
                                  does exist.

here, we deliberately did not say that the name which does exist is, or is
not, the same as a name being updated.  it covers perfectly well the case you
said: "would add any RR with a domain name under a DNAME RR's ownername."  if
this isn't reasonable, then i propose we allocate a new RCODE for this case,
but that no matter what we do, we must not use RCODE=REFUSED.

second, automatic removal of removal of domains below a DNAME.  RFC 2136 does
not, as far as i can tell by searching it, ask an UPDATE responder to delete
names when an NS RR is added.  in fact, this issue came up during the DNSIND
discussions and we determined that since the zone searching algorythm used by
QUERY would stop when searching downward from the apex upon encounter with an
NS RRset, then it was theoretically possible to add an NS RR which would hide
all data beneath its owner name, and then later delete that NS RRset causing
all the previously hidden data to become visible.  since DNAME has the same
effect on QUERY's downward search as NS has (that is, the search stops), i
think there is no reason to require any automatic deletion of data when a 
DNAME is added.

sorry to be so late with this.  i don't keep up with drafts like i used to.

--- End Message ---