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

Toke Høiland-Jørgensen <> Wed, 04 July 2018 08:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C8D2C130DC1 for <>; Wed, 4 Jul 2018 01:50:37 -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 RtaV_v85cZ3Y for <>; Wed, 4 Jul 2018 01:50:34 -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 53A1012426A for <>; Wed, 4 Jul 2018 01:50:34 -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=1530694228; bh=6XbUF3GIu2k5cEPNnYat5gyirL8g9Jf/IZGaCOKCSLY=; h=From:To:Subject:In-Reply-To:References:Date:From; b=bC8gZGHIas+8qC9vwREveNF80QiR/MQNVKjxbnUN0qFfZTwZcHufyEOZwiFMoNZEF b7gBU2ULs/khjLxkgKaalEw1KXNsjAeyEs3ejztVfW+Vr7nItwjCiYd3ANTIYg4Fn5 CFwoToaPYUh+udTL+oI3IGsxmT0qftisi6aj/BljvpEzxS6NEo487eBQ6Bfdh6XNQa t2egLw0BWE202U/bHL3xxN1ISNqQCro25INT8y4oQqPHAoSohGQE1Vb4y6wcGT1gDB oa22dC7GsrOoqq/BrNOnHXReDpbg7OaODRDwd/iQLDobLNrZ0NSjXftK/+5L7oEzoi Y2J22ApueVslw==
To: David Schinazi <>, dnssd <>
In-Reply-To: <>
References: <> <>
Date: Wed, 04 Jul 2018 10:50:20 +0200
X-Clacks-Overhead: GNU Terry Pratchett
Message-ID: <>
MIME-Version: 1.0
Content-Type: text/plain
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.26
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: Wed, 04 Jul 2018 08:50:38 -0000

David Schinazi <> writes:

> Hi everyone,
> This email starts a three-week adoption call for
> draft-sctl-service-registration
> <> .

I provided some comments on the -00 of this draft back in October[0].
The -01 version addresses one of them (related to how to specify the
TTL), but the others are still relevant, I think.

I don't believe these comments should block adoption, but I figured this
would be a good time to repeat them, since I received exactly zero (0)
responses on my previous email... :)

Relevant parts of the previous comments below:

- It is not clear how to find the server to register with: Section 2
  refers to RFC2136 and RFC3007 for the DNS Update mechanism, and to
  RFC6763 Section 11 for information on how to discover the zones to
  attempt registration in. So from my best reading of this, the client
  should discover the relevant zones, then just send its signed updates
  to any authoritative server for those zones. However, this prevents
  implementing the registration logic as a proxy (as I'm currently
  doing). So I feel like there should be a SRV lookup in there
  somewhere? I seem to recall Stuart telling me that this is indeed
  specified somewhere, but my google fu is failing me right now, and in
  any case it's not clear from the draft how this process is supposed to

- Address-based ACLs: Obviously, in most cases a client should only be
  able to perform registration if it is actually on the right network.
  Firewalling off the ports from outside the relevant networks is a way
  to ensure this, but it is somewhat of a crude tool. For one, it
  prevents a single registration server / proxy from serving multiple
  networks[1]. For another, it prevents a use case where a client is only
  allowed *initial* registration (when the key is first cached) from
  inside the network, but is allowed to subsequently update the same
  record from anywhere. This is useful to, for instance, have my laptop
  maintain even when visiting another

  So another way to ensure this source verification is needed, I think.
  The way I implemented it is to have the registration server only speak
  TCP; that way, source address spoofing is not possible (as that would
  make the handshake fail), and the server can simply implement a
  straight-forward ACL policy.

- It is not quite clear to me whether the sleep proxy described in
  section 4 is an optional feature or if its meant to be mandatory.
  Stuart explained its usefulness for devices that power off when not in
  use, requiring this function will mean that registration servers will
  need to be on the local link, which is somewhat limiting. Also, the
  implementation complexity goes way up (I certainly don't plan to
  implement this feature :)). So I think having a way for the server to
  signal "no, I can't perform sleep proxying" to the client would be
  good to allow things to fail in a graceful way.



[1] I'll add that since the -01 draft now says that the update should
    always be for .local, how is a registration server supposed to know
    which domain a client wants to register in? By source address only?