Re: [homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS

Mark Andrews <> Thu, 19 July 2018 01:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7B7AE130E6A for <>; Wed, 18 Jul 2018 18:07:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FhvVO80qwY3I for <>; Wed, 18 Jul 2018 18:07:47 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6B5AD130DC5 for <>; Wed, 18 Jul 2018 18:07:47 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 69DCC3AB05C; Thu, 19 Jul 2018 01:07:44 +0000 (UTC)
Received: from (localhost []) by (Postfix) with ESMTPS id 5505A160050; Thu, 19 Jul 2018 01:07:44 +0000 (UTC)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4086716006A; Thu, 19 Jul 2018 01:07:44 +0000 (UTC)
Received: from ([]) by localhost ( []) (amavisd-new, port 10026) with ESMTP id x034mN13XyhX; Thu, 19 Jul 2018 01:07:44 +0000 (UTC)
Received: from [] ( []) by (Postfix) with ESMTPSA id 4CCBA160050; Thu, 19 Jul 2018 01:07:43 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Mark Andrews <>
In-Reply-To: <>
Date: Thu, 19 Jul 2018 11:07:41 +1000
Cc:, Daniel Migault <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Juliusz Chroboczek <>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <>
Subject: Re: [homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF Homenet WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 19 Jul 2018 01:07:51 -0000

All of this can be done in the DNS without resorting to any other protocol.

_dns-update._udp SRV is registered with IANA for finding where to send
UPDATE request to if the SOA MNAME or the NS’s are not reasonable.
UPDATEs can be secured with TSIG (shared secret) or SIG(0) (public key
cryptography).  The later has the advantage that there isn’t a scaling
issue as the KEY record is stored in the zone.

If you want to experiment with this named has an update policy rule that
allows just such secured updates.

	update-policy {
		grant name * KEY;
		grant * self . [type list];

where is a TSIG or KEY record used by the administrator
to install the KEY record for the node initially.

Garbage collection (GC) had never been defined by a DNS protocol but a simple
one would be to request a TYPE that can live a long side CNAME (like KEY
does) which has the type code to be removed and GC time.  Server policy
could be to add this or the client could include the record in the UPDATE
request. Doing GC with a record like this would be trivial for a DNS server.

DNSSEC servers already do wall clock time based regeneration of RRSIGs using
the type covered and expiry fields of the RRSIG records.  GC would use a
similar mechanism.

> On 19 Jul 2018, at 7:21 am, Juliusz Chroboczek <>; wrote:
> Dear all,
> Since the 1990s, people have been putting their dynamically allocated IPv4
> addresses into global DNS by using a family of gratuitiously incompatible
> trivial protocols.  The technique doesn't have an official name (let alone
> a specification), and is usually referred to as DDNS, DynDNS or Dynamic DNS.
> The basic idea is as follows:
>  - the client is configured with its DynDNS provider;
>  - whenever its public IP changes, the client makes an HTTP request to
>    register the name directly with the provider.
> Usually, but not always, there's some form of garbage collection -- if the
> client fails to refresh its name within some timeframe, the entry is
> deleted.  Security can be achieved either by using HTTPS with a plaintext
> password, or by using clear HTTP and a cryptographic challenge mechanism.
> This kind of protocol has a number of desirable features:
>  - the client side can be implemented in roughly 4 lines of Python;
>  - it's end-to-end, so no privacy issues (if using HTTPS);
>  - it's end-to-end, so it doesn't depend on any local infrastructure;
>  - it's end-to-end, so it can be used in a foreign network (e.g. you can
>    use it to advertise the address of the game server you run on your
>    laptop during IETF meetings).
> DynDNS has been widely deployed for 20 years or so, and would appear to
> solve the problem of name outsourcing quite nicely.  What technical
> problem is draft-ietf-homenet-front-end-naming-delegation solving that is
> not adequately solved by a DynDNS-style solution?
> This is a question that I've been asking since July 2014:
> and I still haven't received an answer I could understand.
> -- Juliusz
> _______________________________________________
> homenet mailing list

Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: