[as112-ops] Extensible AS112 Service

[Nick Hilliard]

On 06/06/2011 04:53, Aleksi Suhonen wrote:
> We'd have the following DNAME records:
> 
> 168.192.in-addr.arpa.  IN DNAME   168.192.in-addr.arpa.empty.as112.net.
> 10.in-addr.arpa.       IN DNAME   10.in-addr.arpa.empty.as112.net.
> ... and so on ...
[...]
> If I've understood correctly, this would make efforts to add DNSSEC to
> AS112 a whole lot simpler too, because there would only be one DNSSEC
> delegation path. The DNAMEs would only exist - and be signed at - the upper
> level zone. As opposed to: Each zone delegated with normal NS records would
> have its own DNSSEC sign path.
[...]
> How does this sound?

In theory, great.  The problem is that in theory, theory and practice ought
to be the same, but in practice they usually aren't.

My (cursory) reading of draft-ietf-dnsext-rfc2672bis-dname indicates that
DNSSEC wouldn't actually work in the way that you're expecting it to.  I
don't view this as a critical problem.

Also, while DNAME is standards track, it's never been used in anger before.
 So while it would certainly seem to fix some problems associated with the
operation of AS112, we have no telemetry to indicate how well or badly it
would work.  If we were to use it for AS112, it would certainly be very
interesting and would likely shake out a whole pile of implementation
problems (which has a lot of merit from the point of view of protocol
development), I would question whether this would be an appropriate first
large-scale production use of DNAMEs.

Nick