[as112-ops] Extensible AS112 Service

[William F. Maton]

On Thu, 21 Jul 2011, Nick Hilliard wrote:

> 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.

My little grey cells started to dance when I re-read this bit, which 
was then excited more when I started to think about DNAME and IPv6 in 
the reverse zone....and I couldn't quite come up why.  Anyways, to 
complete the tangent, I came across RFC 3363, and section 4:

4.  DNAME in IPv6 Reverse Tree

    The issues for DNAME in the reverse mapping tree appears to be
    closely tied to the need to use fragmented A6 in the main tree: if
    one is necessary, so is the other, and if one isn't necessary, the
    other isn't either.  Therefore, in moving RFC 2874 to experimental,
    the intent of this document is that use of DNAME RRs in the reverse
    tree be deprecated.

Of course this is an Informational RFC.

> 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.

+1

wfms