last second action completed

> I do agree in general with the idea, but can we (ISP's) provide
> the same level of service to those VSE's?  How are we (Local
> IR's) going to handle Domain Name Services for those VSE's
> customers?  With an emphasis on in-addr.arpa resolving?

A way to solve the in-addr.arpa problem without introducing new
and over-complicated mechanisms into the DNS was mentioned by
Geert Jan de Groot at the last RIPE meeting, but for reasons
unknown to me this was not discussed much (I think I even heard
some critisism of the approach).  Anyway, this message describes
how I understood Geert's scheme -- I think it has some important
merits worth considering.

The trick is to use CNAME records and to further extend the DNS
tree downwards (adding the possibility for delegation) in the
in-addr.arpa tree.

The following example illustrates the approach.  Let's assume we
have assigned the address spaces

	158.36.155.0/25
	158.36.155.128/26
	158.36.155.192/26

to three different parties, and we wish to make it possible for
the owners of these address spaces to administrate their own
in-addr.arpa DNS mappings.  This can be done by setting up the
zone file for the 155.36.158.in-addr.arpa domain like this:

$ORIGIN 155.36.158.in-addr.arpa.
;
0		NS	some.name.server.
0		NS	some.other.name.server.
;
128		NS	some.name.server.too.
128		NS	some.other.name.server.too.
;
192		NS	some.third.name.server.
192		NS	some.other.third.name.server.
;
1		CNAME	1.0.155.36.158.in-addr.arpa.
2		CNAME	2.0.155.36.158.in-addr.arpa.
3		CNAME	3.0.155.36.158.in-addr.arpa.
; etc.
;
129		CNAME	129.128.155.36.158.in-addr.arpa.
130		CNAME	130.128.155.36.158.in-addr.arpa.
131		CNAME	131.128.155.36.158.in-addr.arpa.
; etc.
;
193		CNAME	193.192.155.36.158.in-addr.arpa.
194		CNAME	194.192.155.36.158.in-addr.arpa.
195		CNAME	195.192.155.36.158.in-addr.arpa.
; etc.

and the zone file for 0.155.36.158.in-addr.arpa might look
something like this:

$ORIGIN 0.155.36.158.in-addr.arpa.
;
1		PTR	my.machine.name.
2		PTR	his.machine.name.
; etc.

This approach makes it necessary to have approx.  256 CNAME
records lying around more or less permanently for each size-256
chunk you want to split up this way.  Some people might view this
as ugly.  It is however quite easy to automatically generate the
CNAMEs once and for all, given that the way the split of the
address space is determined.

This approach has the huge advantage that there should be no need
to modify any already-deployed software, and the lookup
mechanisms in the DNS do not have to be modified to acommodate
this splitting of the responsibility for the address->name
translation.  I have been briefly presented the other proposed
solutions for dealing with this probem in the DNS, and I must say
that this approach with CNAMEs is far more elegant and simple
than any of the other approaches.


- Håvard