Subject: DLV now an informational section of DNS protocol suite, plus the TA RR as a bonus

From: Thierry Moreau <[email-masked]>
Date: Mon, 06 Mar 2006 21:08:25 -0500

Dear all:

I realized that the DLV scheme has been approved as the
informational RFC4431, and that the DLV RR and the TA RR has been
approved by IANA according to
http://www.iana.org/assignments/dns-parameters . The TA RR
interworking specification is in
http://www.watson.org/~weiler/INI1999-19.pdf .

Does anybody know the details of procedural compliance with
section 3.1 in RFC2929 and section 2 in RFC2434 in these two
cases?

In other words, how were RFC4431 and INI1999-19.pdf reviewed to
ensure that they provided "sufficient detail so that
interoperability between independent implementations is possible"
?

We may observe that both the DLV RR and TA RR are intended to
cope with the situation where the DNS root zone signature is
missing for DNSSEC deployment.

In addition, the recently approved ICANN-Verisign settlement (in
http://www.icann.org/topics/vrsn-settlement/
revised-root-transition-agreement-redline-29jan06.pdf) previously
hoped to "sign and publish the root and ARPA zones commencing in
2005 and completing by 2006," and is now only "commencing in
2006."

Regards,

-- 

- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, Qc
Canada   H2M 2A1

Tel.: (514)385-5691
Fax:  (514)385-5900

web site: http://www.connotech.com
e-mail: [email-masked]

--
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: Thomas Narten <[email-masked]>
Date: Mon, 06 Mar 2006 21:06:45 -0500

> interoperability between independent implementations is possible"

Without answering your specific question (I do not know the actual
answer), I'll point out that I (as one of the authors of RFC 2434
responsible for the quoted text) have long considered that text to be
a bug, precisely because it doesn't specify _who_ should do the
evaluation. Clearly, IANA doesn't have such expertise.

Going forward, the proposed text in
draft-narten-iana-considerations-rfc2434bis-04.txt (submitted earlier
today) to address this point is:

>       Specification required - Values and their meaning must be
>              documented in an RFC or other permanent and readily
>              available public specification, in sufficient detail so
>              that interoperability between independent implementations
>              is possible. When used, Specification Required also implies
>              useage of a Designated Expert, who will review the public
>              specification and evaluate whether it is sufficiently clear
>              to allow interoperable implementations.

Thomas

---

From: Mark Andrews <[email-masked]>
Date: Tue, 07 Mar 2006 13:11:28 +1100

> interoperability between independent implementations is possible"

	RFC4431 does nothing more that provide a way to publish a
	collection of DS record equivalents in the DNS.  We could
	have done the same thing via HTTPS.  DNS is just more
	practical as the software that uses the records generally
	has the ability to request missing records via the DNS.

	It's up to the validator local policy to decide to use them
	or not.  INI1999-19.pdf discusses a number of different
	mechanisms to do this.

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Thomas Narten <[email-masked]>
Date: Mon, 06 Mar 2006 21:06:45 -0500

Thomas

---

From: Mark Andrews <[email-masked]>
Date: Tue, 07 Mar 2006 13:11:28 +1100

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Tue, 7 Mar 2006 11:46:03 +0100

> http://www.watson.org/~weiler/INI1999-19.pdf .

This is not correct. The DLV _scheme_ has not been approved. It is  
the DLV _resource record_ has been specified in RFC4431. 4431 is not  
an RFC that defines the DLV _scheme_ nor does it standardize its use.  
Actually 4431 does not contain any language on how the RR ought to be  
used, although it hints to use by validators during the validation  
process.

The RR types have been assigned based on "specification  
required" (RFC 2929).

The specification only defines the content of the RR it specifies the  
on-the-wire format, has a well defined zone-file format, does not  
require compression, and does not rely on special processing in any  
component in the DNS. That means that it is just a blob of data  
carried through the DNS as an RR. IMHO this is sufficient any RR type  
to get an RR code. (We trying to deal with the fact that many people  
put blobs of data in TXT RRs because it seems so difficult to get a  
type code assigned.)

If you were to argue that the DLV is a special case because it could  
be used for making policy decisions at the validator end, I would be  
able to follow that argument. But the point is that that behavior has  
not been described in the RFC and that look aside validation has not  
entered the IETF. In other words: That IANA has assigned type codes  
does not mean that the Look aside validation mechanism has been  
standarized by the IETF.

By the way, there is an individual submission that describes the  
mechanism draft-weiler-dnssec-dlv-00.txt. The author of that draft  
has (not yet?) chosen not to bring that document to this working group.

--Olaf

-----------------------------------------------------------
Olaf M. Kolkman
NLnet Labs
http://www.nlnetlabs.nl/

---

From: "william(at)elan.net" <[email-masked]>
Date: Tue, 7 Mar 2006 03:10:36 -0800 (PST)

On Tue, 7 Mar 2006, Olaf M. Kolkman wrote:

> This is not correct. The DLV _scheme_ has not been approved. It is the DLV 
> _resource record_ has been specified in RFC4431. 4431 is not an RFC that 
> defines the DLV _scheme_ nor does it standardize its use. Actually 4431 
> does not contain any language on how the RR ought to be used, although 
> it hints to use by validators during the validation process.

Is there reason TA and DLV got such high numbers for their RR?

And in general how is it decided which numbers are assigned based on
the drafts? [I see some new drafts causing RRs in 0-50 range, some
below 100 and TA & DLV got 32768 & 32769]

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Tue, 7 Mar 2006 12:17:52 +0100

On Mar 7, 2006, at 12:10 PM, william(at)elan.net wrote:

>> the DLV _resource record_ has been specified in RFC4431. 4431 is  
>> not an RFC that defines the DLV _scheme_ nor does it standardize  
>> its use. Actually 4431 does not contain any language on how the RR  
>> ought to be used, although it hints to use by validators during  
>> the validation process.
>

Yes, the RR types have been assigned based on "specification  
required" (RFC 2929).

To paraphrase: one type code range require standard actions, other  
type codes are for grabs, and some type codes need a stable reference.

--Olaf

---

From: Thierry Moreau <[email-masked]>
Date: Tue, 07 Mar 2006 11:30:40 -0500

Olaf M. Kolkman wrote:
>> informational RFC4431, and that the DLV RR [...] has been
>> http://www.iana.org/assignments/dns-parameters .  [...]
> 
> 
> This is not correct. The DLV _scheme_ has not been approved. It is  the 
> DLV _resource record_ has been specified in RFC4431. 4431 is not  an RFC 
> that defines the DLV _scheme_ nor does it standardize its use.  Actually 
> 4431 does not contain any language on how the RR ought to be  used, 
> although it hints to use by validators during the validation  process.
> 
> The RR types have been assigned based on "specification  required" (RFC 
> 2929).
> 

I did read the "specification  required" as requiring that 
"interoperability between independent implementations is possible", and 
so I concluded that RFC4431 provided an interoperability specification 
between independent implementations of the DLV RR functionality (OK, 
admittedly I froze my reading skills for a moment when loking at RFC4431).

> component in the DNS. That means that it is just a blob of data  carried 
> through the DNS as an RR. IMHO this is sufficient any RR type  to get an 
> RR code. (We trying to deal with the fact that many people  put blobs of 
> data in TXT RRs because it seems so difficult to get a  type code 
> assigned.)
> 
> If you were to argue that the DLV is a special case because it could  be 
> used for making policy decisions at the validator end, I would be  able 
> to follow that argument.

I don't.

> But the point is that that behavior has  not 
> been described in the RFC [...].
> 

Then why did DLV move from a "private use" code point (value 65323, 
according to BIND 9.3.2 source code) to a "specification required" code 
point (value 32769)? Since one of the RFC4431 authors is affiliated with 
the publisher of BIND 9.3.2, I assume that the dual use of the acronym 
"DLV" is not accidental.

Regards,

-- 

- Thierry Moreau

Tel.: (514)385-5691
Fax:  (514)385-5900

---

From: Rob Austein <[email-masked]>
Date: Tue, 07 Mar 2006 13:26:26 -0500

At Tue, 07 Mar 2006 11:30:40 -0500, Thierry Moreau wrote:
> point (value 32769)?

Because using a well-known type code avoids possible confusion with
unrelated uses of the "private use" type code space.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 08 Mar 2006 09:04:16 +1100

> the publisher of BIND 9.3.2, I assume that the dual use of the acronym 

	Private use was good enough for testbeds.  It is not good
	enough for longer term deployment.  That required that the
	type be registered (both by name and code point).

	We really should have kept it called TYPE65323 rather than
	naming it DLV.  As of 9.4.0/9.3.3 TYPE65323 will go back to
	being treated as opaque.

	Mark