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

Ted Lemon <> Thu, 12 July 2018 21:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 25A891311B3 for <>; Thu, 12 Jul 2018 14:47:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.909
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wqyxU3UGP_B3 for <>; Thu, 12 Jul 2018 14:47:46 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4AB7F1311A1 for <>; Thu, 12 Jul 2018 14:47:46 -0700 (PDT)
Received: by with SMTP id l7-v6so29601555ioj.1 for <>; Thu, 12 Jul 2018 14:47:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VhfukJfPx9hr/0l4VyUhjmTBXoYPBg/hQF+fPS0UNgQ=; b=raP3RgWMRyX6aiQDXknww4Bclx5szQ5uYiXfI0u9t8mEBllKnDqk2uXuy9rWXpm/ny 7oQcC4tc9cBOw9zfYOoXde8WD8+YOFTMQ5cpKSXDimqpbMQHtED7wqTQ61dUU40GP5+3 lPlAkbjiS0L+TL6Bbler4eJYcVu3x2UgtjRxmaR1GP1OZCU5Jtm32SvnzMDvBNTjxPL0 vIO9+XEg9rlfTAnQUVc2fBuXINWHHxKPyhXb7mhBTDMp+PSvAQchs6UAyjMxIjjeQHMm Shp9IzfUjPwDOlueS6EZ9KtaFxoyccIAI1XftCgi+gBehxwh75OE+0neCVKYdQa7Z4op 3DYw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=VhfukJfPx9hr/0l4VyUhjmTBXoYPBg/hQF+fPS0UNgQ=; b=anTNdUfFsMUXE581RG6hILjKY9Z77aylgoxuxDp3kCDsJxwTHjUsdJ/GdDUakCILiR Tb95OXIWX1J6kDMq0FKBJ9DBjqtzd5npPyTc7/Goy+cA3WwkDoXtXRSRd4ewUA+yIEdD voI75+gToYMqH3B4YNKoYWSLV3YD095DaQKsuP6NmoZIFmUZ10UDq4+4dAAS6mp3pNga avJ06ObQgHfXGQuBRUeIvz6us6MI7btE5ID+JPKT/bUD5qtVCa5r/e8XCZPGT8RbR9ie 75KOHqsbfXh18SlUPa2ly8d9mOnFxbP/z4FFIheA6U0jAmpCljS1sbt9aadCj52lgPs1 Xbkw==
X-Gm-Message-State: APt69E2po2IgwtsYdHYonwFgWHiT7Sqi1tUStibB5lAyVbCCc54+ugHM 24dmuvYVAiza4M+F6p+xG8TWKEe0/WxeuYgCEjviMw==
X-Google-Smtp-Source: AAOMgpdnKt7J/fx9x+QLN9pyT9GcacVp4oznq1Fe5iekcU/qtBFW76eeqEODoaVjSpMCpBN9uh5AGLLmyIrLg6cfa0c=
X-Received: by 2002:a6b:dd01:: with SMTP id f1-v6mr28851129ioc.45.1531432065663; Thu, 12 Jul 2018 14:47:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4f:5f86:0:0:0:0:0 with HTTP; Thu, 12 Jul 2018 14:47:05 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Ted Lemon <>
Date: Thu, 12 Jul 2018 17:47:05 -0400
Message-ID: <>
To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= <>
Cc: David Schinazi <>, dnssd <>
Content-Type: multipart/alternative; boundary="000000000000459c930570d4502a"
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 21:47:49 -0000

Er, slight clarification, if you want to do Registration Protocol the way
you're describing, and you don't care about the RFC1918 issue, then you'd
need the update to go to your edge router, which would validate the
Registration and then turn it into one or more regular RFC2136-style
updates.   That implementation could be relatively stateless (only state in
memory, only until the transaction is done).

On Thu, Jul 12, 2018 at 5:44 PM, Ted Lemon <> wrote:

> Hm.   For the cloud case, with NAT, that seems kind of problematic anyway,
> because now you have A records in the public DNS pointing at RFC1918
> addresses.   The right way to handle this is with PCP and an SRV record
> pointing at the NAT router's public address and using the PCP-assigned
> port.   I didn't document this because I think it's kind of an extra-cost
> option, but that's how it would have to work.
> On Thu, Jul 12, 2018 at 5:39 PM, Toke Høiland-Jørgensen <>
> wrote:
>> Ted Lemon <> writes:
>> > Yes, this requires separate registrations for IPv4 and IPv6. I think
>> > that's okay. What's a bit chancy is that it also means that if you
>> > have a ULA and a GUA, you have to pick one, or do two updates. As for
>> > NAT, I think we have to assume that the network is not double-natted.
>> > If it's a homenet, that will be true. If it's a campus network, that
>> > will be true. If it's a bunch of crappy routers plugged together, it's
>> > unlikely that service registration will be available anyway, so we
>> > don't care. Do you buy that? :)
>> Heh. For now, probably; by the time this becomes a standard, who knows?
>> (but surely there will be no more IPv4 by then, right? ;))
>> My concern is that requiring client address visibility breaks my
>> deployment use case, where the registration server lives in the cloud...
>> Or rather, I could probably live without v4, but I wouldn't be surprised
>> if someone else got the same idea (DNSSD as a service? One could
>> potentially run a dyndns type service using the same mechanism...).
>> -Toke