Re: [dnssd] WGLC on draft-ietf-dnssd-hybrid-03

Dave Thaler <> Sun, 03 April 2016 15:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 11B0112D53D for <>; Sun, 3 Apr 2016 08:51:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.793
X-Spam-Status: No, score=-101.793 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, USER_IN_WHITELIST=-100] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)"
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uSOhzbwTSNYT for <>; Sun, 3 Apr 2016 08:51:41 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C677A12D55B for <>; Sun, 3 Apr 2016 08:51:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=yLsShjgHZrW3k4RTSb6TWScrzsE5nZaT2isTkKfzuZk=; b=f2P3cQQChqMoNKo4L0ePtgGQ5jQqbEBhnREwtUe40ks5ArUZKNX1At2qHRHZsLfose7D1PRxUlYHugsQstBYBcu/pVxeZK4ViNIoPFYLE3cJaq7lKHjdlBG5bRUjh4Zadh2nllmxYHnlNlUU5yRrRoGZZp7jImTEJBb9u209Wt4=
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.1.447.15; Sun, 3 Apr 2016 15:51:38 +0000
Received: from ([]) by ([]) with mapi id 15.01.0447.025; Sun, 3 Apr 2016 15:51:39 +0000
From: Dave Thaler <>
To: Tim Chown <>, "" <>, "Stuart Cheshire" <>
Thread-Topic: [dnssd] WGLC on draft-ietf-dnssd-hybrid-03
Thread-Index: AQHRgJ2Rr53y89iVQE6o15py6Yebnp930EtQ
Date: Sun, 3 Apr 2016 15:51:38 +0000
Message-ID: <>
References: <> <EMEW3|b98542dd0b73f37521687ff14683dda6s2GMb103tjc||>
In-Reply-To: <EMEW3|b98542dd0b73f37521687ff14683dda6s2GMb103tjc||>
Accept-Language: en-US
Content-Language: en-US
authentication-results:; dkim=none (message not signed) header.d=none;; dmarc=none action=none;
x-originating-ip: [2001:67c:370:160:cc7:2a0c:2c4e:fa21]
x-ms-office365-filtering-correlation-id: 728890f3-0369-4c9d-b5a5-08d35bd7d813
x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0718; 5:LampQoca139HlmoDEsk4YXVKAwhlbDu9CF20m23xHR9A2wleo2XbvX37zaA/TynjVrehpkSNzpEww9KoO4I5LieiUSSh/Po5cSEboRqCFOhM7u/fNvhYYRZZN5QFk30rcvgCE/NjjLOPLox54ef6/A==; 24:ZkqQqllDHFWWBDLg0NPxygX4wGfCDu/Yi8xfceSb9l0buncEwy6C4smbJct1ISh2/E3W21LLk3HvA9wmWhkjEbLk0e0s/wDy5BB8fsqeKpk=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0718;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(61426038)(61427038); SRVR:DM2PR0301MB0718; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0718;
x-forefront-prvs: 09011458FC
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(164054003)(377454003)(92566002)(3280700002)(74316001)(1096002)(1220700001)(10290500002)(586003)(5008740100001)(6116002)(102836003)(2906002)(10400500002)(2501003)(5005710100001)(3660700001)(8990500004)(19580405001)(19580395003)(33656002)(5001770100001)(107886002)(81166005)(77096005)(2900100001)(15975445007)(87936001)(5003600100002)(76576001)(189998001)(106116001)(10090500001)(99286002)(50986999)(86362001)(76176999)(54356999)(230783001)(5004730100002)(122556002)(86612001)(2950100001)(5002640100001)(7059030)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0718;; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Apr 2016 15:51:38.8919 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0718
Archived-At: <>
Subject: Re: [dnssd] WGLC on draft-ietf-dnssd-hybrid-03
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 03 Apr 2016 15:51:43 -0000

My comments...

Section 1:
>    up the dot-local  host names of peers on the same home network, and

for consistency with ".home" in quotes later in the same section

Section 3:
>   Existing clients that support DNS-Based Service Discovery over
>   Unicast DNS (Mac OS X 10.4 and later, including iPhone, iPad, and
>   Bonjour for Windows ) work with Hybrid Proxy.

Suggest removing parenthetical clause since this is not a complete list.
E.g., Windows 10 supports DNS-SD over unicast DNS. Rather than 
trying to have a complete list which might be obsolete by the time
the RFC is published, it's easier to omit.

Section 4.2.2:
>    for the following Multicast DNS Domain Enumeration queries issues  by


Section 4.4:
> In other words, the Hybrid Proxy becomes the 
>   authoritative name server for the reverse mapping domain.

This says "the" (singular) authoritative server.
Is it limited to only one per link?   What if it goes down?

Section 4.5:
>   Generating the appropriate Multicast DNS queries involves, at the
>   very least, translating from the configured DNS domain
>   (e.g., "Building") on the Unicast DNS side to "local"
>   on the Multicast DNS side.
>   Generating the appropriate Unicast DNS responses involves translating
>   back from "local" to the configured DNS Unicast domain.

If the unicast query contains an xn-A-label, should the translation
convert it to a U-label on the multicast side?

Section 4.5.1:
>    reasonble  to expect it to take on the order of ten seconds for a

Typo "reasonble"

Section 4.5.2:
> Similarly, for sites that
>   have multiple private address realms [RFC1918], private addresses
>   from one private address realm should not  be communicated to clients
>   in a different private address realm.

Should "should not" be MUST NOT or SHOULD NOT?
I'm guessing MUST NOT.

Section 4.6:
>   DNS device taking even longer than that (e.g, a device that is not

Missing period after "e.g"

Section 5:
Two notes exist that should be removed before submitting to the IESG:
>   [Author's note: Or maybe it could just be zero?]
>   [Author's note: Discussion of these recommendations is requested.]

Section 6.1:
> When you  Press Cmd-P on your Mac, or
>   select AirPrint on your iPad or iPhone, and the Terminal room
>   printers appear, that is because your client is sending unicast DNS
>   queries to the IETF DNS servers.

The use of 2nd person implies that the audience of the document is just
IETF attendees.  Suggest use of third-person instead.

Section 8.2:
>   become visibile  in a domain such as "My" that might

Typo " visibile "

Section 8.3:
> For Wi-Fi links the Multicast DNS subsystem SHOULD NOT
>   issue more than 20 Multicast DNS query packets per second.

This does mean that an attacker that can generate >20 unicast queries (e.g., 
for names that don't exist) per second can DOS valid queries for names not
in the cache.   This should be pointed out since 8.3 is the section on DOS.

Section 11:
> [Partial list; more names to be added.]

Another note to be removed before submission to IESG.


From: dnssd [] On Behalf Of Tim Chown
Sent: Thursday, March 17, 2016 3:37 PM
Subject: [dnssd] WGLC on draft-ietf-dnssd-hybrid-03

Dear dnssd WG participants,
We are initiating a WG Last Call today on draft-ietf-dnssd-hybrid-03, as can be found at

The call runs for two weeks, and will thus close on Thursday 31st March.

Please send any comments (including indications of support for progression of the document as is) to the list. This draft will not be advanced for publication unless there is sufficient response and support from the WG.  And, of course, any substantive comments on the draft are strongly encouraged as well. We are aware of a small number of minor outstanding comments from the list, but will consider these as part of the WGLC process.

We will discuss the comments arising from the WGLC in the WG meeting in BA on Monday 4th April.


   Performing DNS-Based Service Discovery using purely link-local
   Multicast DNS enables discovery of services that are on the local
   link, but not (without some kind of proxy or similar special support)
   discovery of services that are outside the local link.  Using a very
   large local link with thousands of hosts facilitates service
   discovery, but at the cost of large amounts of multicast traffic.

   Performing DNS-Based Service Discovery using purely Unicast DNS is
   more efficient and doesn't require excessively large multicast
   domains, but requires that the relevant data be available in the
   Unicast DNS namespace.  This can be achieved by manual DNS
   configuration (as has been done for many years at IETF meetings to
   advertise the IETF Terminal Room printer) but this is labor
   intensive, error prone, and requires a reasonable degree of DNS
   expertise.  The Unicast DNS namespace can be populated with the
   required data automatically by the devices themselves, but that
   requires configuration of DNS Update keys on the devices offering the
   services, which has proven onerous and impractical for simple devices
   like printers and network cameras.

   Hence, to facilitate efficient and reliable DNS-Based Service
   Discovery, a compromise is needed that combines the ease-of-use of
   Multicast DNS with the efficiency and scalability of Unicast DNS.


Ralph and Tim
dnssd WG co-chairs