[as112-ops] Extensible AS112 Service

[Aleksi Suhonen]

Hello,

On 05/13/11 16:02, William F. Maton wrote:
> Since there seems to be as of late an appetite to consider all things
> AS112, I wanted to float this draft here with fellow operators before
> popping this at the IETF submission queue. Most of it is lifted directly
> from draft-michaelson-as112-ipv6 given that it serves as a nice
> template. It still needs polishing, so forgive the grammar and style,
> but I wanted to have some as112-ops peer review first. Comments
> appreciated. I'm thinking about RFC 2606, but perhaps I'm pushing my luck.

Looks good, and RFC2606 is OK as well in my opinion.

The mismatch with the fact that more and more zones are considered for 
AS112 and the fact that AS112 operators might not actually be active and 
create new authoritative zones on their nodes as they are delegated is 
causing some uneasiness among the natives. The feared end result is lame 
delegations for invalid zones, which of course should be irrelevant just 
as long as the load is off the crucial infrastructure. However, I do 
sympathise with the people who'd like to do things right.

I'd like to propose that we fix the issue in one fell stroke so that 
changes to AS112 nodes' configuration should never be needed again:
Change the way that the delegations for AS112 zones are made to DNAMEs.
(See http://tools.ietf.org/html/rfc2672 )

Instead of the current NS records:

168.192.in-addr.arpa.  IN NS      blackhole-1.iana.org.
168.192.in-addr.arpa.  IN NS      blackhole-2.iana.org.
10.in-addr.arpa.       IN NS      blackhole-1.iana.org.
10.in-addr.arpa.       IN NS      blackhole-2.iana.org.
... and so on ...

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

And AS112 nodes would only need to configure one zone "empty.as112.net."
If that particular zone name is objectionable then we can use something 
else, such as "empty.iana.org", or we can hijack one of the target zones 
for AS112, such as "example.net" if we adopt RFC2606 as well.

This way we can keep adding new zones to AS112 without much hassle and 
the AS112 nodes can still gather stats for the new zones. For example a 
query for 10.1.2.3 reverse mapping would show up as:

3.2.1.10.in-addr.arpa.empty.as112.net.   IN PTR ?

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.

If there is concern that support for DNAMEs might not be universal, I 
suppose we can have the NS delegations there as well, as backup but 
pointing to same (lame) servers. At least RFC2672 doesn't forbid that.

How does this sound?

-- 
	+358 4567 02048 / http://www.trex.fi/
	Aleksi Suhonen / TREX  Tampere Region Exchange Oy