Subject: DNAME and EDNS1

From: Thomas Narten <[email-masked]>
Date: Mon, 15 Feb 1999 13:09:13 -0500

draft-ietf-dnsind-dname-02.txt says:

>    DNS clients sending Extended DNS [EDNS0] queries with Version 1 or
>    greater are presumed to understand the semantics of the DNAME
>    record.  The sender of a Version 0 or a non-extended query may not
>    understand DNAME, so a server which implements this specification,
>    when answering a non-extended query, SHOULD synthesize a CNAME
>    record for each DNAME record encountered during query processing to
>    help the client reach the correct DNS data.  

This wording means that the EDNS1 document has a normative dependency
on DNAME. In fact, it means more than that. It means that the EDNS1
implementations MUST support DNAME. Normally, when document A requires
that something in document B also be implemented, document A makes
this statement. In this case, document B is mandating a requirement in
document A. If both of these documents were being advanced together,
this wouldn't really be an issue. However, the WG has asked to advance
DNAME while EDNS1 is still a WG draft. Once DNAME is an RFC, it would
be problematic to change the above. (These sorts of issues are why RFC
2026 has the rules it does about normative references to drafts not
being allowed.)

What is the status of EDNS1? Does it make sense to wait for that
document to become ready and advance the two together?

Alternatively, it might make sense to change to the wording above to
only specify the behavior for the queries of type version 0. The EDNS1
document could then specify the behavior in the case where version >
0.

Comments?

Thomas

---

From: Robert Elz <[email-masked]>
Date: Tue, 16 Feb 1999 11:55:08 +1100

Date:        Mon, 15 Feb 1999 13:09:13 -0500
    From:        Thomas Narten <[email-masked]>
    Message-ID:  <[email-masked]>

  | This wording means that the EDNS1 document has a normative dependency
  | on DNAME.

Yes, but DNAME will be done first, so we don't really have a problem there.

  | In fact, it means more than that. It means that the EDNS1
  | implementations MUST support DNAME.

Yes, the intent of the versioning is that a particular version number
will imply all kinds of things must be supported.  EDNS1, when it is
done, ought contain a list of such requirements, and support for DNAME
will be one of those.

Further, in EDNS1 it will (I think) say that the target of a DNAME can
be compressed (normal DNS compression) when the DNS version is 1 or more.
We're not realistically expecting any implementations of DNAME in dns<1
so in practice, all DNAME RR's that are used will be able to be compressed
(no-one who is not dns>=1 will do a DNAME query, and no-one who is dns<1
will have any DNAME records to supply if they get a DNAME query).

That is why we explicitly decided not to make any mention of compression
at all in the DNAME draft.

That is, the default DNS rules apply right now, which is that no RR type
which is not a standard RR in 1035 can make use of name compression.
That is the in the absense of anything to the contrary, so that applies
here.

We deliberately decided not to have the draft say that though, so as to
avoid having the doc always saying, forever into the future, that compression
must not be used, which would be confusing at best after edns1 comes out
(we hope just a couple of months later) and says that compression can be
used, and where, in practice, it will essentially always be used.

On the other hand, dname cannot say that compression can be used with
dns>=1 as that would start making dependancies on edns1 that we wanted to
avoid.

The current state of the doc in this area is a deliberate WG decision, and
we would appreciate it if you would send the IETF last call on the doc as
it is.

The other issues (the code point, and the IANA considerations section) are
trivialities - the RFC editor will certainly fix the former, and if the
IANA really needs an IANA considerations section explaining what they have
already done, I'm sure they are capable of requesting one.

  | What is the status of EDNS1? Does it make sense to wait for that
  | document to become ready and advance the two together?

Please no, we have too much linkage of drafts upon each other already.
All this was gone through when the drafts were initially submitted to
you (the ADs) last year, and it was agreed then that this (and binary-labels)
both needed to wait for edns0, but not for edns1.

kre

---

From: "Matt Crawford" <[email-masked]>
Date: Tue, 16 Feb 1999 11:51:46 -0600

I don't see an agreement yet between the chair and the AD about
proceeding with the last call on DNAME as-is.  Please advise.

Aside from the lack of Security Considerations (for which I
apologize), everything is considered by the WG to be correct,
although parts arguably could be spelled out differently or more
emphatically.  This could be done under last call, yes?

				Matt

---

From: Randy Bush <[email-masked]>
Date: Tue, 16 Feb 1999 12:37:14 -0800 (PST)

> emphatically.  This could be done under last call, yes?

the iesg should move forward.  we have tried to make this clear.  as it has
already been stalled past the mineapolis window <grrr>, we can pick more
nits at our leasure.

randy

---

From: Thomas Narten <[email-masked]>
Date: Tue, 16 Feb 1999 16:13:00 -0500

> we would appreciate it if you would send the IETF last call on the doc as

OK. Thanks for the background info. It all makes sense now.

Last Call will go out shortly.

Thomas