Re: [dnsext] Gen-ART review of draft-cheshire-dnsext-dns-sd-07.txt

Stuart Cheshire <> Thu, 16 December 2010 07:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C26953A709F for <>; Wed, 15 Dec 2010 23:54:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.777
X-Spam-Status: No, score=-106.777 tagged_above=-999 required=5 tests=[AWL=-0.178, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WS4ZNMc4ZKDL for <>; Wed, 15 Dec 2010 23:54:30 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id A0CBE3A709B for <>; Wed, 15 Dec 2010 23:54:30 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id D239CBFFA518 for <>; Wed, 15 Dec 2010 23:56:14 -0800 (PST)
X-AuditID: 11807134-b7cfdae000001831-2d-4d09c61e9157
Received: from ( []) by (Apple SCV relay) with SMTP id 97.79.06193.E16C90D4; Wed, 15 Dec 2010 23:56:14 -0800 (PST)
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Received: from [] ([]) by (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <> for; Wed, 15 Dec 2010 23:56:14 -0800 (PST)
In-reply-to: <>
References: <>
Message-id: <>
From: Stuart Cheshire <>
Date: Wed, 15 Dec 2010 23:56:12 -0800
To: Stephane Bortzmeyer <>
X-Mailer: Apple Mail (2.753.1)
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [dnsext] Gen-ART review of draft-cheshire-dnsext-dns-sd-07.txt
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS Extensions working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 16 Dec 2010 07:54:31 -0000

On 8 Dec 2010, at 7:06 AM, Stephane Bortzmeyer wrote:

> The idea of "IANA secret registrations" (section 18) would be, it
> seems, a first in the IETF world and should be rejected. The entire
> point of IANA registries is to document publicly the *technical*
> identifiers. Trademarks and marketing terms do not have to be in the
> IANA registry and therefore do not need special rules for them.

We have removed this.

> Section 4.1 says that the name must be in NFC. Why not referring to
> its subset defined in RFC 5198? Among the practical differences are
> the fact that RFC 5198 handles the case of end-of-lines, which is
> ignored by the draft.

I changed the reference to RFC 5198.

> "commonly-used 16-bit Unicode space" is a misnomer. If one wants to
> talk about the Basic Multilingual Plane (which stores only a minority
> of Unicode code points), it should use the standard term
> <>.

I changed it to say "Basic Multilingual Plane"

> The "standard DNS message size" is no longer 512 bytes since RFC 2671
> (section 6.1). Yes, EDNS0 sometimes is blocked by broken middleboxes
> but for a technique used only in local networks, this is not a too
> serious issue.

I removed the phrase "standard 512-byte DNS message"

> It seems that the possibility of several TXT in a RRset (not several
> strings in a TXT, which is covered in 6.1) is not mentioned. Is it
> legal and, if yes, how to use it?

I have added this text explaining how multiple TXT records can be used:

    Generally speaking every DNS-SD service has exactly one TXT record.
    However it is possible for the DNS-SD advertising specification for
    a particular protocol to specify that it allows multiple TXT  
    In this case, each TXT record describes a different variant of the
    same logical service, offered using the same underlying protocol on
    the same port, described by the same SRV record. The is very rare,
    and to date, of the many hundreds of registered DNS-SD service types
    [services], only one makes use of this capability, namely printing
    [BJP]. This is used when printers support more than one page
    description language, such as plain text, Adobe PostScript, or other
    proprietary page description language. When this is used, printers
    include two additional keys in each TXT records, 'qtotal', which
    specifies the total number of TXT records associated with this SRV
    record, and 'priority', which gives the printer's relative  
    for this particular TXT record. Clients then select the most  
    TXT record suitable for the client's needs [BJP].

> The advice of section 13.1 to stuff several other records (which may
> be in different bailiwicks) in the DNS answer is at odds with security
> practices (RFC 2181, section 5.4.1 and RFC 5452, section 6).

I have added this text:

    Note that while servers may choose to add these additional records
    for efficiency purposes, as with all DNS additional records it is
    the client's responsibility to determine whether it trusts them.
    Generally speaking stub resolves that talk to a single recursive  
    server for all their queries will trust all records they receive  
    that recursive name server. Recursive name servers that talk to
    multiple authoritate name servers should verify that any records  
    receive from a given authoritate name server are "in bailiwick" for
    that server, and ignore them if not.

Stuart Cheshire <>
* Wizard Without Portfolio, Apple Inc.