Subject: updated dname draft-08

From: Wouter Wijngaards <[email-masked]>
Date: Mon, 14 Jan 2008 10:26:56 +0100

Hi,

The new updated DNAME-bis draft has the following changes 07->08:

o Some spelling and grammar corrections.
o Cleanup of text on the fact that a DNAME is not allowed at the parent
side of a delegation (no mention of SOA records and so on).
o Text talks about resource records that exist at a domain name
subordinate to the owner name of the dname. (in the 'no data below' text).
o removed text about chasing chains of cname/dnames out of zone, it was
out of scope.

o dns cache text changed, 'do not crash when DNAME records are changed'.
the text:
~  DNS caches can encounter data at names below the owner name of a
~  DNAME RR, due to a change at the authoritative server where data from
~  before and after the change resides in the cache.  This conflict
~  situation is a transitional phase, that ends when the old data times
~  out.  The cache can opt to store both old and new data and treat each
~  as if the other did not exist, or drop the old data, or drop the
~  longer domain name.  In any approach, consistency returns after the
~  older data TTL times out.

o dynamic update for DNAME works like NS records.
the text:
~  Dynamic update for DNAME records works similar to dynamic update for
~  delegating NS records.  For example, adding a DNAME obscures names in
~  the zone.  DNAME records can be added, changed and removed.

o text about keeping signing keys online removed,
it now says:
~  The answer shown above has the synthesized CNAME included.  However,
~  the CNAME has no signature, since the server does not sign online.
~  So it cannot be trusted.  It could be altered by an attacker to be
~  ... bla bla

I think I have captured all open issues from the working group with this
new version. Let me know if any issues remain.

Best regards,
~   Wouter (and Scott)

--
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: Mon, 14 Jan 2008 15:35:12 +0000

wouter, i have not been following these drafts, but, i have a question.
will a conforming implementation of the existing DNAME RFC also be a
fully conforming implementation of the next one?  that is, are you 
fixing the RFC language and adding some optional signalling, or are you
invalidating what was said before? if so, can the new DNAME draft include
a summary of exactly what has to be done differently by a conforming old
DNAME agent to turn it into a conforming new DNAME agent? --paul

---

From: Wouter Wijngaards <[email-masked]>
Date: Mon, 14 Jan 2008 17:39:10 +0100

Hi Paul,

RFC has nicer language with an optional UD bit added.
What is said before is not invalidated (well re-phrased), so a
conforming old DNAME agent (like, BIND, NSD ;-) ) would need to do
nothing to conform. (although the UD bit is a nice little extra touch
that MAY be implemented).

The dnssec concern 'need to understand dname' is repeated and explained.
The dname-substitution is explained in smaller words.
Usage of DNAME in practice for NS, MX, PTR records is explained.
DNAME-wildcard discouragement is repeated.

Best regards,
~   Wouter

Paul Vixie wrote:
| wouter, i have not been following these drafts, but, i have a question.
| will a conforming implementation of the existing DNAME RFC also be a
| fully conforming implementation of the next one?  that is, are you
| fixing the RFC language and adding some optional signalling, or are you
| invalidating what was said before? if so, can the new DNAME draft include
| a summary of exactly what has to be done differently by a conforming old
| DNAME agent to turn it into a conforming new DNAME agent? --paul

---

From: Scott Rose <[email-masked]>
Date: Mon, 14 Jan 2008 11:51:41 -0500

Basically yes, but the changes are:

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)

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).

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.

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

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?

Scott

-- 
----------------------------------------
Scott Rose            Computer Scientist
NIST
ph: +1 301-975-8439
[email-masked]

http://www-x.antd.nist.gov/dnssec
http://www.dnsops.gov/
-----------------------------------------

---

From: Paul Vixie <[email-masked]>
Date: Mon, 14 Jan 2008 18:20:45 +0000

> Basically yes, but the changes are:

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

> 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.
> 

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.

---

From: Scott Rose <[email-masked]>
Date: Mon, 14 Jan 2008 14:22:04 -0500

> but that no matter what we do, we must not use RCODE=REFUSED.

Hmm, sounds like it might be more correct to have RCODE=YXDOMAIN.  Is 
there anyone who suggests RCODE=REFUSED is more correct?  It isn't a 
policy decision to refuse the update, but a specification.  The RCODE 
should be the same as the RCODE returned by the server that sees a 
dynamic update message that attempts to add a record with a domain name 
under a delegation (NS RR) in the zone.

> think there is no reason to require any automatic deletion of data when a 

Actually, I mis-spoke.  The text in the DNAME-08 draft is:

    Dynamic update for DNAME records works similar to dynamic update for
    delegating NS records.  For example, adding a DNAME obscures names in
    the zone.  DNAME records can be added, changed and removed.

It doesn't delete names, but obscures them.

Scott

---

From: Paul Vixie <[email-masked]>
Date: Mon, 14 Jan 2008 19:49:09 +0000

> Hmm, sounds like it might be more correct to have RCODE=YXDOMAIN.  Is there
> anyone who suggests RCODE=REFUSED is more correct?  It isn't a policy
> decision to refuse the update, but a specification.  The RCODE should be
> the same as the RCODE returned by the server that sees a dynamic update
> message that attempts to add a record with a domain name under a delegation
> (NS RR) in the zone.

in that case, don't prohibit it at all for DNAME, since it's not prohibited
for NS.

> It doesn't delete names, but obscures them.

that's fine, and goes to support the idea of not rejecting new names under
a DNAME.

---

From: Wouter Wijngaards <[email-masked]>
Date: Tue, 15 Jan 2008 09:13:35 +0100

Paul Vixie wrote:
|> 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.)

Servers copy UD into response, so resolvers can see UD bit in response.
Servers are allowed to synthesize CNAMEs from cached DNAME records.
There is no text about ignoring presented CNAMEs if UD bit is copied but
CNAME synthesis is performed anyway.

|> If generated CNAMEs present, expect TTL = DNAME TTL or TTL = 0
|
| how does an initiator know whether the presented CNAMEs are synthetic?

Synthetic because they are the expansion of the DNAME in the packet.

Best regards,
~   Wouter

---

From: Paul Vixie <[email-masked]>
Date: Tue, 15 Jan 2008 10:40:20 +0000

> CNAME synthesis is performed anyway.

thanks.

> Synthetic because they are the expansion of the DNAME in the packet.

so if a presented DNAME is superior to a presented CNAME, then a receiver
can assume that they are related (CNAME was synthesized)?  what if there
is more than one label of difference between them, and one of those labels
has other data, and there is no actual relationship, and the CNAME is real?

i think you need a signalling method to say, the CNAME was generated, if
you want initiators to be able to reliably ignore them when a DNAME is also
presented.

---

From: Wouter Wijngaards <[email-masked]>
Date: Tue, 15 Jan 2008 13:40:58 +0100

Paul Vixie wrote:
| thanks.
np.
|
|> |> If generated CNAMEs present, expect TTL = DNAME TTL or TTL = 0
|> |
|> | how does an initiator know whether the presented CNAMEs are synthetic?
|>
|> Synthetic because they are the expansion of the DNAME in the packet.
|
| so if a presented DNAME is superior to a presented CNAME, then a receiver
| can assume that they are related (CNAME was synthesized)?  what if there
| is more than one label of difference between them, and one of those labels
| has other data, and there is no actual relationship, and the CNAME is
real?

If there is more than one label of difference, the DNAME applies.
Those other labels are not allowed to have data (no data below DNAME).
If the CNAME is real, then there is some sort of data below a DNAME,
which is not allowed. The DNAME applies to all names ending in that
suffix, also names with lots of labels more.

| i think you need a signalling method to say, the CNAME was generated, if
| you want initiators to be able to reliably ignore them when a DNAME is
also
| presented.

Is the current UD bit copied into the response, if older servers won't
copy it into the response, good enough?

Best regards,
~   Wouter

---

From: Niall O'Reilly <[email-masked]>
Date: Tue, 15 Jan 2008 12:57:19 +0000

On 15 Jan 2008, at 10:40, Paul Vixie wrote:

> has other data,

	The number of labels involved shouldn't matter: below is below.

	OTOH, step 3C of the algorithm seems to require an empty
	non-terminal to trigger DNAME processing.
	This can't be right.  Wouter, Scott ?

> and there is no actual relationship, and the CNAME is real?

	On an authoritative server, DNAME obscures.  If this is not
	the operational intention, it's an error on the part of the
	zone administrator.

	In cache, this must be a transient issue, already considered.

	Now, the specification of step 4 reads, "If QNAME is not found
	in the cache but a DNAME record is present at an ancestor of
	QNAME, copy that DNAME record into the answer section."  This
	gives priority to an exact QNAME match, even if a superior (and
	thus obscuring) DNAME has subsequently arrived in the cache. I'm
	not sure whether this is right, but is it indeed the intention ?

	Besides, it's not clear to me that step 5 of the algorithm is
	sufficiently specified.  In RFC1034, specification of this step
	refers to a section where the resolver algorithm is given more
	detailed treatment.  Such a resolver section may be needed here too.

> you want initiators to be able to reliably ignore them when a DNAME  

	TTL=0 _was_ this signalling.  I'm not suggesting we go back there.
	8-)

	Best regards,

	Niall O'Reilly
	University College Dublin IT Services

	PGP key ID: AE995ED9 (see www.pgp.net)
	Fingerprint: 23DC C6DE 8874 2432 2BE0 3905 7987 E48D AE99 5ED9

---

From: Paul Vixie <[email-masked]>
Date: Tue, 15 Jan 2008 17:45:02 +0000

> | real?
> If there is more than one label of difference, the DNAME applies.  Those
> other labels are not allowed to have data (no data below DNAME).  If the
> CNAME is real, then there is some sort of data below a DNAME, which is not
> allowed. The DNAME applies to all names ending in that suffix, also names
> with lots of labels more.

there's a lot of subtlety there.  but i agree, it works.

> | also presented.

it wouldn't, since older authority servers also synthesize, but according to
what you pointed out above, it doesn't matter in that case.