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

Ted Lemon <mellon@fugue.com> Thu, 12 July 2018 18:00 UTC

Return-Path: <mellon@fugue.com>
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 76D56131151 for <dnssd@ietfa.amsl.com>; Thu, 12 Jul 2018 11:00:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com
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 e8LkZi_j33bA for <dnssd@ietfa.amsl.com>; Thu, 12 Jul 2018 11:00:01 -0700 (PDT)
Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AD00131150 for <dnssd@ietf.org>; Thu, 12 Jul 2018 11:00:01 -0700 (PDT)
Received: by mail-it0-x232.google.com with SMTP id s7-v6so8034406itb.4 for <dnssd@ietf.org>; Thu, 12 Jul 2018 11:00:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LWrwYKEzdvq/8d/QdymhGF467Y3xmX2YsecRNVd6IBg=; b=nAIS1XlGp+yeYtCqAFPW20DhjVADENmei1aK/oNwH+gaAFnSoorDdlSfcVLcf9u2Fr T8QQlUv+K0XvLSRMfU3S/KaXF97GPgWz2ZVOvzI5Bk3UneJlziItlGmUpdjCQ2NyO3ia 0Akn3X3H8lharTbANBpdLXi79/UepqHLq8qdP0oHNHStOjGMb/Eev96QQW4ZHIzIqqUb JkAdSe71Ezz4k9o8I5WwWMGIxIadena+Ul1KHB8rWuILkEW7zlgnMoVg4LMwnyRohfIk OVL5jmln9Zc/q0lAyDvFu9Oi+111KfK1Y55x1VejA1T39sjyxIzqdfRWhl0QuSPnBW4Z ZC7w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LWrwYKEzdvq/8d/QdymhGF467Y3xmX2YsecRNVd6IBg=; b=t394nSIDhWNqq2QI2ha3pXqaPZCRysxDxjaDhWXPr6jh/bmd+X/3ktxqouFDAB5Tqw 5az9Ogd1pt6a/0Q92PUxgBk2qnuD9IcQ871JVF/ij46eiIOY99zU792n5UT+cu7HmpP8 BV3hHaXwfEMkSMLmRDtljJA0yD3jAAi1+ryUAaD1/Lz4yjVSiLb3kW1WrjvsEmckpxJE aEIcCq9JQ4k0NbcVQTQdskXdOGxZbEkM4rHL7yqUr+NfXBZ0uY5MyD0PJUZMoh9iEQ7M B/17NzI6iv5OKLH94D8UY5iXoWArgK12ZPHDNAdJeguvh0S6E9e06SJxcSS8Z3U2Jc+r r9tA==
X-Gm-Message-State: AOUpUlGL2vjj5OIm0J83fysegLvfH64gJZYwkSIwUwMW1xh8LnNYaN/x pcCnKd3UHJbbQKx3WG7xCI4ET/SIOZoah3XYkpFIOA==
X-Google-Smtp-Source: AAOMgpfJfbeTchwKGkICEPdDylfHJsIGg7L77f1TTd7CAdWvtCHy8Jnj+iFDVjK4YScdHjIX4xGKtlh5qY4WiK8tZCE=
X-Received: by 2002:a24:d485:: with SMTP id x127-v6mr2256178itg.82.1531418400935; Thu, 12 Jul 2018 11:00:00 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4f:5f86:0:0:0:0:0 with HTTP; Thu, 12 Jul 2018 10:59:20 -0700 (PDT)
In-Reply-To: <874lh4bicx.fsf@toke.dk>
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> <874lh4bicx.fsf@toke.dk>
From: Ted Lemon <mellon@fugue.com>
Date: Thu, 12 Jul 2018 13:59:20 -0400
Message-ID: <CAPt1N1mLA3knwxW0R9Ayb29Og4hh=y+6X9OaPSZW58noYv-4+A@mail.gmail.com>
To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= <toke@toke.dk>
Cc: David Schinazi <dschinazi@apple.com>, dnssd <dnssd@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ca6c540570d12131"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/ZXxFlmCMv3JN9sOT8Mx6KYUlNXg>
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 18:00:05 -0000

It seems like the client should just keep maintaining whatever records it
maintains.   If the server doesn't take some updates, then the client can
just keep trying.   Otherwise the client has to somehow model the state of
the server, which seems unnecessary.

As for A and AAAA records, this is an open question: how to handle it.   Is
it a problem to allow a client to update arbitrary A and AAAA records?
 The restriction of only updating the one that corresponds to the source
address used to send the update is there because we have some reasonable
assurance that the client actually has that address.   We could have some
hack where we use the neighbor table to notice that several addresses are
associated with the same layer 2 address, but that seems like not what we
want to do.

mDNS seems to just use .arpa.   I don't know how/if that works, but I
definitely don't see how to make it work with the DNS protocol.   Maybe
mDNSResponder caches this information and then returns it for 1918 networks
and ULA networks, I don't know.



On Thu, Jul 12, 2018 at 11:10 AM, Toke Høiland-Jørgensen <toke@toke.dk>
wrote:

> 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
>