Re: [dnssd] The DNSSD WG has placed draft-sctl-service-registration in state "Call For Adoption By WG Issued"

Toke Høiland-Jørgensen <> Thu, 12 July 2018 15:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C6F93130E52 for <>; Thu, 12 Jul 2018 08:10:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 08IxFtppfO5s for <>; Thu, 12 Jul 2018 08:10:18 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 38645130E00 for <>; Thu, 12 Jul 2018 08:10:18 -0700 (PDT)
From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= <>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=20161023; t=1531408209; bh=jYXn/KlTBlCT+S/t8OEIfuN07hDFI0KbmYwjhLwo/3Q=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=cWhZPUhN42caQsnlr8jkGwkQnlg6/EL5BpYE2j4sHw5FS68ZtduI+a6kNA6MtIJaU p8+vCiUJNfwteZgyavVl2EN6WPn8DMqfaFbv/mE8n6yUGU6Qj6VChz4rThIAn1l/Oc YdhLPz3JmT+pOnFNv/dkFw84CnmU7kO6Z9uqbJSNcim0n9EqHkvYHIVP4ju4ZfUvS8 qirY7u9solBbS9bYq5bDzSdTZPEawAeSyuDknrhdOLLK9N2ClwJ8rzpa1qjnEwX+0C D29X+TVeuZGKvS5s1gJtlmzZT1Mt53BJxpVMaHsvwlBYfCuEjTziXmYAE5Xv9+9DYq 0q47hToDCY/BQ==
To: Ted Lemon <>
Cc: David Schinazi <>, dnssd <>
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <>
Date: Thu, 12 Jul 2018 17:10:06 +0200
X-Clacks-Overhead: GNU Terry Pratchett
Message-ID: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [dnssd] The DNSSD WG has placed draft-sctl-service-registration in state "Call For Adoption By WG Issued"
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 12 Jul 2018 15:10:21 -0000

Ted Lemon <> writes:

>> A few other comments based on a quick read-through:
>> - Since registrations are always done with .local, it is up to the
>>   registration server to decide which domain(s) the registration ends up
>>   in, right? How is it supposed to do that if servicing multiple zones?
>>   Just based on source IP?
> I think that that's up to the implementation. It could do it based on
> IP address, or as I suggested in the document it could have a
> whitelist that's maintained by an administrator, based on the key or
> the name or the service type. As long as it does the same thing every
> time, the details are (I think) immaterial. However, this is worth
> thinking about—if you can come up with something that doesn't work, we
> should document it.

Right. I *think* that will work; but will probably have to try it out to
be sure :)

>> - The document says that clients must generate their own reverse PTR
>>   records. Should the server be able to do that on the clients behalf?
>>   It may be a matter of policy which ranges have reverse domain
>>   delegations...
> Interesting. I did it this way because I don't want to get into the
> "PTR is bad, get rid of it, no it's good, I want it" argument. :)

I'm fine with not having that argument; just want to make sure the
standard doesn't disallow it (auto-adding). See below.

> - Related to the above, is it permitted for the registration server to
>>   modify the records submitted by clients before putting them into
>>   DNS? For example, to add PTR records, or to remove a subset of the
>>   records etc? The alternative to modifying would be to reject the whole
>>   registration if a subset is not admissible. If the server *is* allowed
>>   to modify things, should it communicate back to the client what it
>>   really did?
> Can you think of a scenario where it makes sense to do this? The
> reason that this might not be permissible is simply that I can't think
> of a record other than the PTR record that could be omitted without
> making things fail.

What I implemented is that the client will add AAAA records for all
addresses assigned to the interface; and the registration server will
filter out the ones it doesn't like (mostly making sure site-local
addresses don't end up in global DNS). I think this sort of thing should
be allowed at the server side (could also be a policy like "we don't
want printers on this network").

The question is if the client should be notified; my server will tell
the client which records were actually created, and the client won't
bother maintaining the ones that weren't. However, this is mostly an
optimisation; not sure if it's worth specifying in the spec...

>> - You mention in the text that a network may use a different domain than
>> for reverse PTRs. How does that work? Won't clients always
>>   do reverse lookups to
> Unless they are modified.

Right, that's what I thought.

> The point of that is not to suggest that implementing this is
> REQUIRED, but it could be useful for someone, and hence is not
> FORBIDDEN. If you think the text reads as making this a required
> feature, we should fix that! :)

Hmm, don't think it read like it's required, necessarily; I was just
confused by it. I consider(ed) the reverse domains a static thing not
likely to change, in which case it seems odd to do the mapping from
.local. Is this what happens in mDNS?