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