Re: [mdnsext] A few questions from a new participant

Kerry Lynn <> Wed, 31 July 2013 15:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9A0DB21F997B for <>; Wed, 31 Jul 2013 08:41:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.144
X-Spam-Status: No, score=-1.144 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tRsowMNpalIe for <>; Wed, 31 Jul 2013 08:41:33 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c01::233]) by (Postfix) with ESMTP id C638B21F9702 for <>; Wed, 31 Jul 2013 08:41:32 -0700 (PDT)
Received: by with SMTP id fb19so1611289obc.24 for <>; Wed, 31 Jul 2013 08:41:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=9z54Tu3NmXUNV4M+w3gXXb8D8PytuP4Ir0PIhb3dBsA=; b=Boh3txYQJjkofjawP3plLiZsKoBT7T08XpFkQMsTj24aYx/Zc7YMIfREg9I63P+RPi kSxaWf4fatLLQ9iAl2TKxKRhl8xdijglM0j/mo1mbP0cY41C1hLQbJTGcrDQzBIVWLmm 1/CqeSuGGqU0PTGTZcoEghQx0B0UEDSxQy8qbaKu8TGsxuHsQeRC8bfAvnywyDmv0Je1 POid2gGWmaQY2LgY+hKka2UCDSSW1W0Cgah/fflF6EpE1N4p9ptBxnczvv8H6jvAJu9U LBOYC57zO2qLdZaNbda/v/Tt3V5CFRHgsJZv4I38Ql0iRXe/Twi1G94S5SzaKR3RRqHW +luA==
MIME-Version: 1.0
X-Received: by with SMTP id h4mr67605438oek.22.1375285292202; Wed, 31 Jul 2013 08:41:32 -0700 (PDT)
Received: by with HTTP; Wed, 31 Jul 2013 08:41:32 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Wed, 31 Jul 2013 11:41:32 -0400
X-Google-Sender-Auth: u6nN_WocbwfYlmbRSZzGsOl-ATY
Message-ID: <>
From: Kerry Lynn <>
To: "Charles E. Perkins" <>
Content-Type: multipart/alternative; boundary=089e0149bf724e820b04e2d08fb6
Subject: Re: [mdnsext] A few questions from a new participant
X-Mailman-Version: 2.1.12
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: Wed, 31 Jul 2013 15:41:33 -0000

Hi Charlie,

I'll take a stab at answering your questions below...

On Wed, Jul 31, 2013 at 5:57 AM, Charles E. Perkins

> Hello folks,
> I've just joined the mailing list, so my questions may already have been
> answered...
> - Why use the terminology "wide-area"?  It usually means a large
>   area, much more than even the (small?) enterprise scenario under
>   discussion.  What about re-using the terminology "site"?
> Let's begin with the distinction between DNS-SD (DNS-Based Service
Discovery [RFC6763]) and mDNS (Multicast DNS [RFC6762]).  DNS-SD
is a conventional use of existing DNS RRs (SRV, TXT, PTR, A/AAAA) for
the purpose of discovering services (which are roughly akin to service
access points).  The use of "wide-area" usually applies to DNS-SD, which
can be deployed in any DNS zone in the Internet and is accessed using
standard DNS.  (However, Andrew Sullivan and others have pointed out
that DNS labels must be LDH or IDNA-encoded, while DNS-SD permits
arbitrary NFC UTF-8.  That was the discussion around point 3 of the

mDNS can be thought of as an optimized transport for DNS-SD, but it
is really more than that.  Unlike DNS, it will return *all* the relevant RRs
for a particular query and operates over local links using link-local mcast
and distributed responders.

- Is it assumed that only a low volume of service discovery operations
>   will be initiated (per unit time)?  This "builds on" the zeroconf /
>   single link case, but might be important to state explicitly.
> I have to go back and read the requirements draft, but a figure of merit
is that the total percentage of bandwidth used for discovery on a given
link should remain constant (or decrease) as the system scales across
the use cases.

- I guess the constraint on the number of networks has to do
>   with trying to limit the traffic load from multicast packets.
>   Is multicast assumed?
> It will probably be part of the eventual solution (especially as we have
the requirement not to break current functionality) but I expect it will be
relied upon to a lesser extent (or not at all) for off-link queries.

HTH, -K-

> --
> Regards,
> Charlie P.
> ______________________________**_________________
> mdnsext mailing list