[dns-wg] Policy for Reverse DNS for End-User PA Addresses?

I am delighted to see such an interest in this subject. I would love to 
write a draft on it, and perhaps even presenting it at a RIPE meeting.

Instead of spamming you all with answers to each posts, I will collect 
my comments in a single mail. Of course, this messes up threading, but 
so be it :-)


 From the various comments I realise that although I originally related 
this problem to DSL customers it is also an issue to other end users, 
regardless of technology. It seems to be a general pattern for all end 
users with small IP range allocations.

Jim Reid argued that these customers could just switch to another ISP, 
which of course is true. But even if it theoretically possible, it may 
not be economically viable. A small company may have to choose between 
paying, say, €10 a month for a DSL connection or thousands of euros for 
having some serious provider pulling in a fibre or something.

How many small businesses will be able and willing to pay orders of 
magnitude extra just to get the "luxury" of reverse DNS?


Jim Reid also wrote:
> It could also be painful for ISPs and the NCC: creating
> inetnum objects for every /29 or whatever an ISP gives to its DSL
> customers.

Certainly.
I did not mean to suggest making new inetnum objects. My idea was that 
end users that already have inetnum objects might be given the choice of 
reverse delegation. For end users without inetnum objects, the holder of 
the inetnum object for the encompassing range (typically the ISP) should 
handle reverse DNS.

As I see it, it would be enough to make reverse delegation of PA 
addresses analogous to reverse delegation of PI addresses.

The question here would be whether the RIPE NCC DNS servers can carry 
the load. Does anyone have an idea of how many inetnum objects there are 
in the whois database for IPv4 ranges lower than /24 - compared to the 
total number of inetnum objects?


Peter Koch wrote:
> See also draft-ietf-dnsop-inaddr-required-05.txt.

A very interesting draft. If this becomes standard, RIPE should consider 
this question anyway. Does anyone know the status of this draft?

Interestingly, the draft mentions RIPE as appearing "to have the 
strongest policy in this area [ripe-185] indicating Local Internet 
Registries are required to perform IN-ADDR services, and delegate those 
as appropriate when address blocks are delegated".

ripe-185 is now deprecated, and the new policy does not mention this 
requirement at all.
The former reverse DNS FAQ said "Each Local Internet Registry (LIR) is 
obliged to handle administration involved with the reverse delegation 
for the IP addresses it assigns" - but again, the new reverse delegation 
pages does not mention it at all.

Prior to mailing this list, I asked ripe-dbm at ripe.net about this. They 
answered:
 > [...] there is no policy that obliges [the ISPs] to provide this
 > service to their customers, it is their own option.
 >
 > Although the text in our previous F.A.Q. was different, this statement
 > was what was always meant.

So until recently, although unintentional, RIPE already demanded for 
ISPs to provide reverse DNS :-)



Peter Koch also wrote:
> Yes, like privacy issues.

Actually, draft-ietf-dnsop-inaddr-required-05.txt mentions that privacy
issues are irrelevant for this, since the information is already partially
accessible through whois.

> What I've read between the lines is that in the case of DSL the classless
> delegation method may not be sufficient, even if the ISP is able and willing.
> Due to dynamic nature of address assignments they'd need something similar
> to dyndns (and friends) for the reverse mapping. So, is anyone doing this
> already?

It is true that some DSL customers have dynamic addresses, but many have 
static ones. If someone were to make reverse DNS for dynamic addresses, 
it would have to be the ISP (or whoever controls the /24 zone). I feel 
it would be counter-productive to make that mandatory - dynamic 
addresses and DNS cache do not mix (sufficiently low TTLs would just 
make too much traffic).



Thank you for all your comments,


Jørgen E. Larsen
CTO
Elgaard Data
jel(at)elgaard.net