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

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

Return-Path: <toke@toke.dk>
X-Original-To: dnssd@ietfa.amsl.com
Delivered-To: dnssd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6F93130E52 for <dnssd@ietfa.amsl.com>; Thu, 12 Jul 2018 08:10:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08IxFtppfO5s for <dnssd@ietfa.amsl.com>; Thu, 12 Jul 2018 08:10:18 -0700 (PDT)
Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38645130E00 for <dnssd@ietf.org>; Thu, 12 Jul 2018 08:10:18 -0700 (PDT)
From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= <toke@toke.dk>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; 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 <mellon@fugue.com>
Cc: David Schinazi <dschinazi@apple.com>, dnssd <dnssd@ietf.org>
In-Reply-To: <CAPt1N1=ktPp-T8fg17fAaT=FznDytnXr2N3Uz1rUL+En_QOKUA@mail.gmail.com>
References: <153064569308.5111.7449468818446130425.idtracker@ietfa.amsl.com> <EB70166C-B64B-4509-909D-76978CA00A36@apple.com> <87lgare65v.fsf@toke.dk> <AC270951-0AA4-45D0-9F1A-83067489BF27@fugue.com> <87in5td3ar.fsf@toke.dk> <A667C059-FEBB-4159-A053-0B7AFE35F5FD@fugue.com> <87r2kbcl3h.fsf@toke.dk> <CAPt1N1=kNRiNLMEkSjMmcG+U5Bg6OACkQTAkO6t1b-rzYnza0w@mail.gmail.com> <87fu0obuua.fsf@toke.dk> <CAPt1N1=ktPp-T8fg17fAaT=FznDytnXr2N3Uz1rUL+En_QOKUA@mail.gmail.com>
Date: Thu, 12 Jul 2018 17:10:06 +0200
X-Clacks-Overhead: GNU Terry Pratchett
Message-ID: <874lh4bicx.fsf@toke.dk>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/ZGQ5slCVBv3vgD0TLvML9REQXoE>
Subject: Re: [dnssd] The DNSSD WG has placed draft-sctl-service-registration in state "Call For Adoption By WG Issued"
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Jul 2018 15:10:21 -0000

Ted Lemon <mellon@fugue.com> 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
>>   ip6.arpa for reverse PTRs. How does that work? Won't clients always
>>   do reverse lookups to ip6.arpa?
>
> 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?

-Toke