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 example.com name * KEY;
grant * self . [type list];
};
where example.com 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 <j...@irif.fr> 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:
>
> https://mailarchive.ietf.org/arch/msg/homenet/7JmkTCBSSMs5nnH3VWPj6JAL0cA
>
> and I still haven't received an answer I could understand.
>
> -- Juliusz
>
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
