Subject: [dnsext] RRTYPE request for review and comment

From: [email-masked]
Date: Wed, 10 Sep 2008 12:46:45 -0400

Dear colleagues,

IANA has had another request for a new RRTYPE.  In the same way that
we are treating the other open RRTYPE request according to the
2929-bis procedure, we'll be treating this one that way.

Therefore, this is posted for a three week review.  The review period
closes 1 October, 2008 at 17:00 Eastern time.

Best regards,

Andrew

---cut here---begin template---

A. Submission Date: Friday 29th August 2008

B. Submission Type:
[X] New RRTYPE
[ ] Modification to existing RRTYPE

C. Contact Information for submitter:
Name: Stuart Cheshire
Email Address: [email-masked]
International telephone number: +1 408 974 1010
Other contact handles:
(Note: This information will be publicly posted)

D. Motivation for the new RRTYPE application?
Please keep this part at a high level to inform the Expert and
reviewers about uses of the RRTYPE. Remember most reviewers
will be DNS experts that may have limited knowledge of your
application space.

Negative caching in Multicast DNS.

E. Description of the proposed RR type.
This description can be provided in-line in the template,
as an
attachment or with a publicly available URL:

See text below, which we plan to add to draft-cheshire-dnsext-
multicastdns-07.txt.

F. What existing RRTYPE or RRTYPEs come closest to filling that
need and why are they unsatisfactory?

None, or we would have used an existing type.

G. What mnemonic is requested for the new RRTYPE (optional)?
Note: this can be left blank and the mnemonic decided after
the
template is accepted.

NEGATIVE (248)

H. Does the requested RRTYPE make use of any existing IANA
Registry or require the creation of a new IANA Sub-registry
and
in DNS Parameters?
If so, please indicate which registry is to be used or
created.
If a new sub-registry is needed, specify the allocation policy
for it and initial contents. Also include what the
modification
procedures will be.

No.

I. Does the proposal require/expect any changes in DNS
servers/resolvers that prevent the new type from being
processed as an unknown RRTYPE (see [RFC3597])?

No (this is for use in Multicast DNS only, not Unicast DNS)

J. Comments:

We plan to add the following text to draft-cheshire-dnsext-
multicastdns-07.txt:

8.1 Negative Responses

In the early design of Multicast DNS it was assumed that explicit
negative responses would never be needed. However operational
experience showed that negative responses can be important,
specifically in the case of clients querying for a AAAA record when
the host in question has no IPv6 addresses. In this case an explicit
negative response is preferable to the client having to retransmit
its query multiple times and eventually give up with a timeout
before
it can conclude that a given AAAA record does not exist.

A responder indicates the nonexistence of a record by using a
special
pseudo-RR with DNS meta-type "NEGATIVE" (248). This is considered a
pseudo-RR because queries for this meta-type are ignored, and
clients
should never cache records with this type (though receipt of this
pseudo-RR may cause the creation of the appropriate negative cache
entry). Receipt of a NEGATIVE pseudo-RR indicates the
nonexistence of
a record, with the same name and rrclass as the NEGATIVE pseudo-RR,
and rrtype as specified in the rdata of the NEGATIVE pseudo-RR
(which
is therefore always exactly two bytes long, containing a DNS rrtype
in network byte order). The TTL of the NEGATIVE pseudo-RR indicates
the intended lifetime of the negative cache entry. In general,
the TTL
given for a NEGATIVE pseudo-RR SHOULD be the same as the TTL that
the
record would have had, had it existed. For example, the TTL for
address records in Multicast DNS is typically 120 seconds, so the
negative cache lifetime for an address record that does not exist
should also be 120 seconds.

A responder should only generate negative responses to queries for
which it has legitimate ownership of the name/rrtype/rrclass in
question, and can legitimately assert that no record with that
name/rrtype/rrclass exists. A responder can assert that a specified
rrtype does not exist for one of its names only if it previously
claimed unique ownership of that name using probe queries for rrtype
ANY. (If it were to use probe queries for a specific rrtype, then it
would only own the name for that rrtype, and could not assert that
other rrtypes do not exist.) Similarly, a responder can assert
that a
specified rrclass does not exist for one of its names only if it
previously claimed unique ownership of that name using probe queries
for rrclass ANY. On receipt of a question for a particular
name/rrtype/rrclass which a responder knows not to exist by
virtue of
previous successful probing, the responder MUST send a response
packet containing the appropriate NEGATIVE pseudo-RR.

Stuart Cheshire <[email-masked]>
* Wizard Without Portfolio, Apple Inc.
* Internet Architecture Board
* www.stuartcheshire.org

---cut here---end template---

--
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: Mark Andrews <[email-masked]>
Date: Thu, 11 Sep 2008 11:39:55 +1000

I wonder why a RCODE of NXRRSET is not sufficient for
	a specific negative response?

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

---

From: Paul Vixie <[email-masked]>
Date: Thu, 11 Sep 2008 02:08:36 +0000

> 	a specific negative response?

while rcode nxrrset isn't currently defined for queries, there's no
reason it couldn't be sent in a multicast context.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 10 Sep 2008 20:29:45 -0700

>	a specific negative response?

Serious question for the chairs: is this thread meant to be a 
discussion of the protocol (which is in a long-expired draft at 
<http://tools.ietf.org/html/draft-cheshire-dnsext-multicastdns-06>), 
or of the request for the IANA allocation?

--Paul Hoffman, Director
--VPN Consortium

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 11 Sep 2008 09:37:36 +0200

On Wed, Sep 10, 2008 at 08:29:45PM -0700,
 Paul Hoffman <[email-masked]> wrote 

> or of the request for the IANA allocation?

I second the serious question :-) I thought that Apple Multicast DNS
was dropped, now that RFC 4795 is published?

---

From: Joe Abley <[email-masked]>
Date: Thu, 11 Sep 2008 08:15:19 -0500

> was dropped, now that RFC 4795 is published?

It might be dropped, but given that it is implemented and widely- 
deployed it seems understandable that it might require code point  
assignments.

The request is for a review of the request for a new RRTYPE  
assignment, not a review of the protocol, by my reading.

Joe

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 11 Sep 2008 10:04:41 -0400

Dear collegues,

On Wed, Sep 10, 2008 at 08:29:45PM -0700, Paul Hoffman wrote:

> Serious question for the chairs: is this thread meant to be a discussion of 
> the protocol (which is in a long-expired draft at 
> <http://tools.ietf.org/html/draft-cheshire-dnsext-multicastdns-06>), or of 
> the request for the IANA allocation?

Sorry for any confusion.  This is a discussion period just for the
requested allocation.  This allocation is being considered under
expert review, according to the procedures in the 2929bis draft
(which, we've been assured, will be published Any $Day Now, where $Day
is now greater than 30).

This is the second such request we have open -- the comment period for
another one started at the end of August, except that I have just now
looked for the message starting that comment period in the archives,
and haven't found it.  I could swear I saw it come to the list, but
apparently I'd be wrong.  I've just re-sent that message.  It contains
a more complete explanation of what the procedure is and what we're
doing.  Since I'd already explained it once, I thought it would be
silly to reproduce that effort here.  Except, of course, it's not in
the archives, so you wouldn't be able to find it.

Best regards,

Andrew

-- 
Andrew Sullivan
[email-masked]
+1 503 667 4564 x104
http://www.commandprompt.com/

---

From: "Ondřej Surý" <[email-masked]>
Date: Thu, 11 Sep 2008 16:21:12 +0200

2008/9/11 Joe Abley <[email-masked]>:
> It might be dropped, but given that it is implemented and widely-deployed it
> seems understandable that it might require code point assignments.
>
> The request is for a review of the request for a new RRTYPE assignment, not
> a review of the protocol, by my reading.

My understanding is that there is a new version of draft in preparation
which is not implemented and widely-deployed.  And this new RRTYPE extends
draft 06 to add new features and new RRTYPE.

Anyway is this new RR something *like* NSEC/NSEC3?  Or is it more
*like* NXDOMAIN?
NSEC RR was needed so DNS is able to sign record, but here I don't see a reason
why response code cannot be used.

Ondrej
-- 
 Ondřej Surý
 technický ředitel/Chief Technical Officer
 -----------------------------------------
 CZ.NIC, z.s.p.o. -- .cz domain registry
 Americká 23,120 00 Praha 2,Czech Republic
 mailto:[email-masked] http://nic.cz/
 sip:[email-masked] tel:+420.222745110
 mob:+420.739013699 fax:+420.222745112
 -----------------------------------------
h�{.n�+���zwZ��,j��v�y�覗������-��"z��"�a{
+v�칻�&ފv��x%zX�y�-�鞲Ơzױ��ɪ܆+ކ�i��)�'�~���X����jg���iz�?

---

From: Ted Hardie <[email-masked]>
Date: Thu, 11 Sep 2008 10:12:41 -0700

>or of the request for the IANA allocation?

I find it hard to separate the two, honestly.  As it stands, this
proposal takes the TTL returned for one RR (248) and causes it
become the negative cache TTL for a different record, e.g. AAAA.
Approving this RR appears to approve that behavior.  And
though the template says:

>Does the proposal require/expect any changes in DNS

I have a strong suspicion that once NEGATIVE is allocated
some bright spark will use it "Unicast DNS".  I certainly
don't see any way to prevent that.  Someone might
choose to use it in preference to other negative caching
strategies just so they are using the same thing in mdns
and dns.

I'm personally still mulling over the consequences of this,
and I'd be a lot more comfortable if the actual text was
in a draft-cheshire-dnsext-multicastdns-07.txt so it could
be read in full context.  I certainly support there being
some way to do what Stuart describes, but the magic
property behavior ("take this TTL and move it to
the record specified in the rdata, flipping the bit")
does make me wonder if there isn't either a more
general need or more general approach here.

			regards,
					Ted

---

From: Stuart Cheshire <[email-masked]>
Date: Thu, 11 Sep 2008 10:52:36 -0700

> a specific negative response?

Multicast DNS packs multiple answers into a packet for network  
efficiency. A DNS-format packet only has one RCODE field. In a  
Multicast DNS response packet with multiple answers, both positive  
and negative, a single RCODE field is insufficient. A representative  
Multicast DNS response packet might look like this:

Answer Section:

Stuart's\032Printer._http._tcp.local. 120 IN SRV      0 0 80  
stuartsprinter.local.
Stuart's\032Printer._http._tcp.local. 120 IN TXT      "path=/"
stuartsprinter.local.                 120 IN A        169.254.123.45
stuartsprinter.local.                 120 IN NEGATIVE AAAA

This says that the web UI page for "Stuart's\032Printer" is reachable  
at "http://stuartsprinter.local.:80/", and the address of  
"stuartsprinter.local." is 169.254.123.45, and by-the-way the printer  
doesn't have an IPv6 address so don't bother asking.

In real-world networking, a Multicast DNS response packet may contain  
many more records than just four, with a mix of both positive and  
negative answers.

---

From: Stuart Cheshire <[email-masked]>
Date: Thu, 11 Sep 2008 11:25:24 -0700

> was dropped, now that RFC 4795 is published?

The reality is that Multicast DNS is widely used, and that's why over  
the last two years we've received numerous requests to finalize these  
drafts and publish them as RFCs, which is why we're doing that now.

>> deployed it

Over the last couple of years the one remaining issue to resolve with  
Multicast DNS has been how to communicate negative responses, and  
after much thought we concluded that this new meta-type is the best  
solution. The key issue that makes existing DNS approaches unsuitable  
is the way that Multicast DNS packs multiple answers into a packet  
for network efficiency. We need a way to encode negative responses on  
a per-record basis, not per-packet.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 11 Sep 2008 18:44:13 +0000

> In real-world networking, a Multicast DNS response packet may contain  many
> more records than just four, with a mix of both positive and  negative
> answers.
> 

ok, on that basis i withdraw my objection to the NEGATIVE rr type proposal.

---

From: Stuart Cheshire <[email-masked]>
Date: Thu, 11 Sep 2008 18:28:26 -0700

On 11 Sep, 2008, at 10:12, Ted Hardie wrote:

> be read in full context.

Done:

<http://www.ietf.org/internet-drafts/draft-cheshire-dnsext- 
multicastdns-07.txt>

---

From: Florian Weimer <[email-masked]>
Date: Fri, 12 Sep 2008 09:40:41 +0200

> stuartsprinter.local.                 120 IN NEGATIVE AAAA

Ah, thanks, this clarifies your request.

Have implementations of NEGATIVE already been deployed?  I want to
suggest to turn this around and use a positive list of existing RTYPEs
under the name, similar to NSEC.

(Is there a mailing list we can move this discussion to?  It's
off-topic on namedroppers.)

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

---

From: Wouter Wijngaards <[email-masked]>
Date: Fri, 12 Sep 2008 10:00:03 +0200

Stuart Cheshire wrote:
> This says that the web UI page for "Stuart's\032Printer" is reachable at
> "http://stuartsprinter.local.:80/", and the address of

Why don't you use the existing NSEC record type, that can be used to
list all the types present (and absent) for a record?

It would look like this:
stuartsprinter.local.           120 IN A	169.254.123.45
stuartsprinter.local.		120 IN NSEC	. A NSEC

It avoids the transmission of 65000 NEGATIVE records.  Making a
'wildcard'-like generated NEGATIVE record is just asking for
Kaminsky-like problems.

You can use NSEC to signal that the information is 'complete', which
looks like it is what you want (provide all info, or a large subset of
info about a number of names inside a single datagram).

Also, I agree with Ted Hardie that the use of NEGATIVE in the unicast
DNS is not desired.  I propose NSEC for mDNS to resolve that.

If you do not like the special content of the next-owner-name '.', you
could set it equal to the owner name, so that the NSEC does not deny the
existence of domain names.

Best regards,
   Wouter

---

From: Olaf Kolkman <[email-masked]>
Date: Fri, 12 Sep 2008 14:50:24 +0200

> was dropped, now that RFC 4795 is published?

If I recall well then LLMNR spec (RFC 4795) did not gain sufficient  
support to be published on the standards track. We did find it useful  
to publish this as informational as the technical specification had  
had sound review. That decision did not drop "mDNS", in fact I  
(somewhere in the back in my head) always expected that mDNS would at  
some point be published as informational too.

Also see: http://www.ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00364.html

Although Paul Hoffman's question has already been answered in a  
similar fashion: This is truly a tough question. Because mDNS only  
differs one letter from DNS and the protocols share a bunch of  
properties and are disjunct elsewhere it is really tempting to go into  
protocol engineering. I think it is useful if mDNS is reviewed on its  
interaction with DNS but since mDNS is not a WG item we as a group  
should stick to the task at hand: Expert review of the IANA  
registration request.

--Olaf

---

From: Stuart Cheshire <[email-masked]>
Date: Fri, 12 Sep 2008 10:19:40 -0700

> under the name, similar to NSEC.

No, it has not been deployed.

We're open to feedback and suggestions. We'll take another look at  
NSEC. Thanks.

---

From: Ted Hardie <[email-masked]>
Date: Fri, 12 Sep 2008 16:32:01 -0700

><http://www.ietf.org/internet-drafts/draft-cheshire-dnsext-

Thanks very much for putting that together so quickly.  It
has been years since I read the previous drafts, and a fresh
copy did much to refresh my memory on the (quite varied)
differences between multicast DNS and DNS; I appreciate, in
particular, section 22 as it puts the text in 8.1 in the larger
context of other changes.  I would suggest one addition to
section 22--"Multicast DNS records have no SOA records" (noted
in Section 12).

Two comments on the registration:  First, I hope that NSEC
can work for this, as Wouter has suggested.   It seems
possible that this would provide some efficiency and
would avoid some of the risks for a pseudo-RR.

Second, if that does not work, I support the assignment of
an RR for this, but with a special designation by IANA.
2929bis does not appear to allow the assignment of an
RR which is not be used in the DNS (as it doesn't really
treat mDNS at all).  Technically, that means the experts
should reject this as not permitted by the procedures.
Hopefully, they will not be so procedure bound, but will
support something that is needed by a deployed, useful
system.  Some special marking on the part of IANA does
seem warranted, though. A few of the existing RRs are marked
experimental (MB, MR) and a few obsolete (MD, MF).  One
of those entries is:

MD           3 a mail destination (Obsolete - use MX)       [RFC1035]

Having the experts declare that this should be
marked ("reserved psuedo-RR for mDNS") would seem
a reasonable away around the problem of including
it in the IANA registry.

Thanks again for the quick turn-around.
			regards,
				Ted Hardie

---

From: Stuart Cheshire <[email-masked]>
Date: Tue, 23 Sep 2008 15:28:52 -0700

> info about a number of names inside a single datagram).

I like that suggestion, thanks.

We're looking into implementing this, so for now, Andrew, please put  
our application for a new pseudo-RR type on hold. If it works as we  
hope, we'll be able to withdraw the application.

Just to make sure we're on the same page here, you're talking about  
RFC 3845, right?

> existence of domain names.

Am I correct in understanding that both of those would be illegal in  
standard DNS?

Given this, which would you advocate that we should use?

Using the root label takes on byte on the wire.

Using the owner name takes (with name compression) two bytes, so  
there's little difference in wire efficiency.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 24 Sep 2008 09:21:06 +1000

In message <[email-masked]>, Stuart Cheshire wr
> Am I correct in understanding that both of those would be illegal in  

	Only because RRSIG is not set.  The lack of RRSIG could be
	a useful differentiator.  With RRSIG set the record would
	be one from a signed root zone.

	Note: existing NSEC generators set the RRSIG bit as they
	know the next step is to sign the NSEC record.  The RRSIG
	bit could be cleared afterwards however as RRSIG is 46 and
	NSEC is 47 and the record's length would not change.  With
	the next name being "." the offset of the RRSIG bit is also
	fixed.

> there's little difference in wire efficiency.

	But then you would be changing the definition of NSEC which
	has this field uncompressed.   If you want to use existing
	code you need to be aware that we will return FORMERR to
	the caller if we see a compression pointer.

static /* inline */ isc_result_t
fromwire_nsec(ARGS_FROMWIRE) {
        isc_region_t sr;
        dns_name_t name;
        unsigned int window, lastwindow = 0;
        unsigned int len;
        isc_boolean_t first = ISC_TRUE;
        unsigned int i;

        REQUIRE(type == 47);

        UNUSED(type);
        UNUSED(rdclass);

        dns_decompress_setmethods(dctx, DNS_COMPRESS_NONE);

        dns_name_init(&name, NULL);
        RETERR(dns_name_fromwire(&name, source, dctx, options, target));

---

From: Olaf Kolkman <[email-masked]>
Date: Wed, 24 Sep 2008 16:26:55 +0200

Top post...

Why not the NXT RR (RFC2535) same semantics, but not in use any- 
longer, so no possible clashes and possible misunderstood semantics.

--Olaf

---

From: Jim Reid <[email-masked]>
Date: Wed, 24 Sep 2008 15:56:28 +0100

> longer, so no possible clashes and possible misunderstood semantics.

Wouldn't this make it harder to give 2535 a decent burial? Preferably  
one that encased it inside many cubic metres of reinforced concrete. :-)

BTW, apologies for inserting a meaningful Subject: header....

---

From: Mark Andrews <[email-masked]>
Date: Thu, 25 Sep 2008 07:07:17 +1000

In message <[email-masked]>, Olaf Kolkman wri
tes:
> This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
> --Apple-Mail-65--853920391
> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
> Content-Transfer-Encoding: 7bit
> 
> 
> Top post...
> 

	NXT doesn't support all current types.

---

From: "George Barwood" <[email-masked]>
Date: Thu, 25 Sep 2008 10:14:58 +0100

Has defining a class been considered?

Say "NIN" to stand for "Not in Internet" or "Negative Internet".

Stuart's\032Printer._http._tcp.local. 120 IN SRV 0 0 80 
stuartsprinter.local.
Stuart's\032Printer._http._tcp.local. 120 IN TXT      "path=/"
stuartsprinter.local.                 120 IN A        169.254.123.45
stuartsprinter.local.                 120 NIN AAAA
This seems cleaner to me than using a Type.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 25 Sep 2008 12:11:05 +0000

> Has defining a class been considered?

this isn't what classes are for, and it isn't how classes work, so, no.

> This seems cleaner to me than using a Type.

rdata format is class independent.  rdlen=0 would be a protocol violation.
further, the NSEC format is actually much more compact for this purpose.
(the responder in stuart's case doesn't know what rrtypes the initiator
may be contemplating, so it's nec'y to enumerate the full set and illuminate
those present/absent.)

---

From: "George Barwood" <[email-masked]>
Date: Sun, 28 Sep 2008 10:01:41 +0100

----- Original Message ----- 
From: "Paul Vixie" <[email-masked]>
To: "George Barwood" <[email-masked]>
Cc: "Jim Reid" <[email-masked]>; "Olaf Kolkman" <[email-masked]>; 
"Stuart Cheshire" <[email-masked]>; "Wouter Wijngaards" 
<[email-masked]>; "IETF DNSEXT WG" <[email-masked]>; 
<[email-masked]>
Sent: Thursday, September 25, 2008 1:11 PM
Subject: Re: [dnsext] alternatives to the proposed NEGATIVE pseudo-RR

> this isn't what classes are for, and it isn't how classes work, so, no.

The standard doesn't state the purpose of classes, it just enumerates them.

mRDNS is already using class for another purpose.

> rdata format is class independent.  rdlen=0 would be a protocol violation.

A and AAAA are specific to IN, so may have other formats in other classes 
surely?

Still,  class seems dead for practical purposes, so I concede that reviving 
it is probably not a good idea.