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
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
