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 13:25 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 E09AB130F15 for <dnssd@ietfa.amsl.com>; Thu, 12 Jul 2018 06:25:56 -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 5VzsLPzYfDkg for <dnssd@ietfa.amsl.com>; Thu, 12 Jul 2018 06:25:54 -0700 (PDT)
Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (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 5138E130F14 for <dnssd@ietf.org>; Thu, 12 Jul 2018 06:25:54 -0700 (PDT)
Received: by mail-it0-x22b.google.com with SMTP id h2-v6so4966067itj.1 for <dnssd@ietf.org>; Thu, 12 Jul 2018 06:25:54 -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=0PYwzOWYdElnGqyIQpmW+eF+UFtkWr2DvlxwiGADzgg=; b=qZwFm8Q6QKixdSmJXwoDiDtsaVQT7Ql0SDdkvAeQOPoKw1Lbg/avu3LBdtefnF8cTv 4YOeZwJzJogDyATQ4yu3dMwH7zyHxfeQCaiuzMiUMVdgHfAxR63TaHbJjtVIomy5JPzw 9DNgQnXL3vuuMK98jtb4i9vTz1vLeLoLAvyy1vbzaabHGK6P0XpOW0JQWPCfTcLn8x6f nwntUycPN0hxXkcXsvbi4hmba3xAFNGHOzQRmUjkUNwplApOAtA6DfRGbjoylREe0HNO sbk/B7NC6OmBkJnJlaCZNvo+1XVvY3N1JgfXaOXaCWJVfuaSTB+AHHNwjzaXsW0WknyX iLaQ==
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=0PYwzOWYdElnGqyIQpmW+eF+UFtkWr2DvlxwiGADzgg=; b=hfyY7965VFoTvPe4tGuC35Hqb0Hp/wd4FlISiQOICwBKF9o/pOZR4xCjsOTNmwd5mJ ue+bgomK7UoTSZulPd5BV+9SA/A/KmXsUp9sm78FaD6/sXwz42k253tk3RTPm1sRdmKU D2tyowzXYQkpRoEi3wRn/lvFiV7LDGSxgqY/j0brpliNygN3uTqkrTI8ye30PAQTCSd8 E2ii2EsBmFJzPBAxppsW+TDpWn3Z5QP3KdWbY3VEuF4cZddZx8luWGEQqgwhqrK+7iwo YIVJb4fuRkRLofymHiKEn9xbE5n0OEdLjboIKiFNFgju8BuKbnnO5OVOlz1m2ygzPbsJ EabA==
X-Gm-Message-State: AOUpUlFPbI97a8s4nOgYmdcfNHfGFJSamuhFoFKgsl3IZREAiZ1HVXJ3 68IbOPwkRJszhnAuuEOc6Q9W1ZVJIhacShoyp6mGAg==
X-Google-Smtp-Source: AAOMgpeZhVoiiS/9SGg8rdFokOqKxDKkEbPhXVQ1Qb9XYta1Tuc3ZIGhbeLXDF9svAdvoRJpRfcGULhbkKzOEVpajMY=
X-Received: by 2002:a24:4dd3:: with SMTP id l202-v6mr1271194itb.144.1531401953647; Thu, 12 Jul 2018 06:25:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4f:5f86:0:0:0:0:0 with HTTP; Thu, 12 Jul 2018 06:25:13 -0700 (PDT)
In-Reply-To: <87fu0obuua.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>
From: Ted Lemon <mellon@fugue.com>
Date: Thu, 12 Jul 2018 09:25:13 -0400
Message-ID: <CAPt1N1=ktPp-T8fg17fAaT=FznDytnXr2N3Uz1rUL+En_QOKUA@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="00000000000074b5420570cd4d4c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/TwKHa_keYbp3MsYL1XZTHdoE1z4>
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 13:25:57 -0000

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

> Thanks for the update! I think this version addresses my concerns from
> the previous round. :)
>

Great!


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


> - 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. :)

It could certainly be a site policy to auto-add a PTR record.   Since the
content of the PTR record is fixed, this would just have the effect of
making PTR records non-optional, not of changing what got stored in the
update.   I would be in favor of adding this as an optional behavior.

However, I think that this should be optional behavior, and therefore I
think it's worth allowing the client to update the PTR record.   The
benefit of this is that it gives the software/hardware vendor some say in
what debugging information is available, regardless of the opinions of the
network operator or DNS server implementor.

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


> - 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.   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!   :)