Re: [dns-wg] Policy for Reverse DNS for End-User PA Addresses?
Jørgen, you raise an interesting question. This subject is certainly something for the WG to consider. How about presenting something at the next RIPE meeting? My personal opinion is that a mandatory policy is likely to be too cumbersome. 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. That might also open the door to other complications. If some DSL user is in the NCC database because of an inetnum object for reverse delegation, maybe that user should be paying NCC fees? And does that user become responsible for maintaining that inetnum and related objects in the database? I've also got a gut feel that reverse delegation is really an issue between an ISP and its customer. If some ISP won't do reverse delegation properly (or at all), the customer is free to pick another ISP that does. Economic Darwinism should sort this out, just like it eliminates the clueless ISPs with lousy service. A document advising about reverse delegations which customers can put in front of their ISP would be no bad thing though. That said, I would welcome a discussion about the subject and encourage the WG, especially those at DSL providers, to speak up. I would also be pleased for the WG to produce some document on reverse delegation and strongly recommends this gets done properly. Making reverse delegation mandatory for all customer IP addresses may be a step too far IMO, but let the WG decide this. Perhaps you could start the ball rolling by preparing an initial draft with a view to starting a work item? I'm a great believer in delegation (excuse the pun), so over to you.... and the WG.
At 8:41 PM +0100 2004-07-08, Jim Reid wrote:
I've also got a gut feel that reverse delegation is really an issue between an ISP and its customer. If some ISP won't do reverse delegation properly (or at all), the customer is free to pick another ISP that does. Economic Darwinism should sort this out, just like it eliminates the clueless ISPs with lousy service.
I disagree. In many cases, there is one and only one DSL provider for a given address -- the old telephone monopoly continues to have a stranglehold here. In cases where multiple DSL providers are available (or where cablemodem is an option), the monopoly provider is usually more flexible for that customer, whereas they tend to take a much more cavalier attitude towards those who have no other option. I think that it is wishful thinking to assume that Economic Darwinism will sort out this problem. -- Brad Knowles, <brad.knowles@skynet.be> "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See <http://www.sage.org/> for more info.
My personal opinion is that a mandatory policy is likely to be too
Mandating these things usually needs a hat the wg doesn't wear. See also draft-ietf-dnsop-inaddr-required-05.txt.
cumbersome. 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. That might also open the door to other complications. If
Yes, like privacy issues.
some DSL user is in the NCC database because of an inetnum object for reverse delegation, maybe that user should be paying NCC fees? And does
Well, does the recipient of assigned address space now (directly) pay an NCC fee?
about reverse delegations which customers can put in front of their ISP would be no bad thing though.
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? -Peter
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@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
On Friday 09 July 2004 20:08, Jørgen Elgaard Larsen wrote:
So until recently, although unintentional, RIPE already demanded for ISPs to provide reverse DNS :-)
ISP's/LIR's should be required to provide reverse DNS. Even if it's just a generic reverse such as adsl-xx-xx.isp.com
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.
No privacy issues aren't irrelevant. When I got my IP range at home, I wasn't informed that my details could potentially appear in a public registry - they didn't in the end, although there is an inetnum for my range it's fully admin'd by my ISP and doesn't contain any of my details. Privacy issues must be addressed, and there is actually no reason why the end user's details need to be associated with the inetnum. Jon
Jon Lawrence wrote:
ISP's/LIR's should be required to provide reverse DNS. Even if it's just a generic reverse such as adsl-xx-xx.isp.com
Although generic reverses does help in some ways, it could also be argued that they do not provide much real information. In my opinion it will only make sense to make reverse DNS mandatory, if the end user can decide that the information should be useful, i.e. that addresses resolve to corresponding canonical hostnames.
No privacy issues aren't irrelevant. When I got my IP range at home, I wasn't informed that my details could potentially appear in a public registry - they didn't in the end, although there is an inetnum for my range it's fully admin'd by my ISP and doesn't contain any of my details. Privacy issues must be addressed, and there is actually no reason why the end user's details need to be associated with the inetnum.
Sorry, I did not mean that privacy issues are irrelevant. What I (and the draft) ment was that there are no privacy issues with reverse DNS as long as you can find the end user for an IP address through whois. Whether the whois database should allow anonymised inetnum objects is another discussion. But of course there will be privacy issues if otherwise anonymous IP addresses are forced to have reverse DNS pointing to something personal. Thanks for pointing that out - I had not thought of that, since I started the other way around, wanting to ensure that end users could have relevant reverse DNS if they wanted. In practice, however, this is should not be a problem. Even if you can be identified though domain X, there is usally no practical way for the ISP to know that you have made a hostname in that domain point to one of your IP addresses. Unless you instruct your ISP to make reverse DNS point for your addresses to something specific, they usually will have no choice but to let it point to a generic reverse. Best regards, Jørgen E. Larsen CTO Elgaard Data jel(at)elgaard.net
Jon Lawrence wrote:
ISP's/LIR's should be required to provide reverse DNS. Even if it's just a generic reverse such as adsl-xx-xx.isp.com
Although generic reverses does help in some ways, it could also be argued that they do not provide much real information. In my opinion it will only make sense to make reverse DNS mandatory, if the end user can decide that the information should be useful, i.e. that addresses resolve to corresponding canonical hostnames.
No privacy issues aren't irrelevant. When I got my IP range at home, I wasn't informed that my details could potentially appear in a public registry - they didn't in the end, although there is an inetnum for my range it's fully admin'd by my ISP and doesn't contain any of my details. Privacy issues must be addressed, and there is actually no reason why the end user's details need to be associated with the inetnum.
Sorry, I did not mean that privacy issues are irrelevant. What I (and the draft) ment was that there are no privacy issues with reverse DNS as long as you can find the end user for an IP address through whois. Whether the whois database should allow anonymised inetnum objects is another discussion. But of course there will be privacy issues if otherwise anonymous IP addresses are forced to have reverse DNS pointing to something personal. Thanks for pointing that out - I had not thought of that, since I started the other way around, wanting to ensure that end users could have relevant reverse DNS if they wanted. In practice, however, this is should not be a problem. Even if you can be identified though domain X, there is usally no practical way for the ISP to know that you have made a hostname in that domain point to one of your IP addresses. Unless you instruct your ISP to make reverse DNS point for your addresses to something specific, they usually will have no choice but to let it point to a generic reverse. Best regards, Jørgen E. Larsen CTO Elgaard Data jel(at)elgaard.net
On Friday 09 July 2004 21:14, Jørgen Elgaard Larsen wrote:
Jon Lawrence wrote:
ISP's/LIR's should be required to provide reverse DNS. Even if it's just a generic reverse such as adsl-xx-xx.isp.com
Although generic reverses does help in some ways, it could also be argued that they do not provide much real information. In my opinion it will only make sense to make reverse DNS mandatory, if the end user can decide that the information should be useful, i.e. that addresses resolve to corresponding canonical hostnames.
yes and no :) It make sense to make reverse dns mandatory even if it's only a *generic* reverse. For one thing, I see plenty of emails coming through are servers (and some of them are genuine) which come from addresses with absolutely no reverse. I'd rather the reverse was relevant, but a *generic* is better than nothing.
No privacy issues aren't irrelevant. When I got my IP range at home, I wasn't informed that my details could potentially appear in a public registry - they didn't in the end, although there is an inetnum for my range it's fully admin'd by my ISP and doesn't contain any of my details. Privacy issues must be addressed, and there is actually no reason why the end user's details need to be associated with the inetnum.
Sorry, I did not mean that privacy issues are irrelevant.
What I (and the draft) ment was that there are no privacy issues with reverse DNS as long as you can find the end user for an IP address through whois.
You don't necessarily need to be able to find the end user directly from the whois, so long as the whois points you in the right direction - ie the ISP. Ultimately, the whois always points you in the right direction, even if that means you end up complaining to the LIR directly :)
Whether the whois database should allow anonymised inetnum objects is another discussion. Indeed it is another discussion but I for one see nothing intriniscally wrong with it - depending upon the degree on anonimity. I think the inetnum for my home range (81.168.4.64/29) is a good example of how to put in place an anonymous (as far as the end user is concerned) inetnum.
Thanks for pointing that out - I had not thought of that, since I started the other way around, wanting to ensure that end users could have relevant reverse DNS if they wanted.
We also do the same. If someone wants to have a relevant reverse DNS then they get it - we may request proof that they own the domain name that they want it pointing to ;) but the customer gets what they want. Even if they don't want it, they may get it - All be it, it might just be their initials prefixed to our domain - it makes associating entries in log files to users a lot easier. So what if it's a bit more work for me to setup, in the long run I believe it saves me headaches. Jon
Jørgen E. Larsen wrote:
A very interesting draft. If this becomes standard, RIPE should consider this question anyway. Does anyone know the status of this draft?
it is currently a wg item in the IETF DNSOP wg and will be discussed at the San Diego IETF. There hasn't been any discussion on the list for quite a while.
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.
Just to clarify: I wasn't suggesting that the reverse mapping induced privacy problems. This sentence was in response to Jim, who, to my reading, suggested small allocations be added to the RIPE db.
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).
So, do you feel this is DSL specific or could be described as "reverse mapping for small address ranges"? Brad seemed to distinguish between the ISP and the DSL provider {BTW, speaking of categories, you might want to have a look at draft-klensin-ip-service-terms-03.txt - but let's not discuss that one here}. My perception is that we have a similar situation with one of our larger T-elco. On the other hand, the very same company does (and has been doing for years) provide RFC 2317 delegations. Let's first agree what the problem domain is. Then, we could do some measurement/counting, e.g. find how much address space < /24 is actually served in RFC 2317/BCP 20 style. The NCC did regular IN-ADDR.ARPA surveys and some of this data may be either readily available or not too difficult to find. -Peter
On Fri, 9 Jul 2004, [windows-1252] Jørgen Elgaard Larsen wrote:
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?
There are 959000 </24 inetnum objects vs 1101000 total inetnum objects vs 139000 domain objects vs 137000 delegations currently in the RIPE database/zone files. ( Note that some domain objects are occluded by other domain objects )
The question here would be whether the RIPE NCC DNS servers can carry the load.
We have ccTLD zones secondaried on the same servers with more than a million DNS records.
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
Agreed. ( DNS updates by the NCC for dynamic addresses has LIR customers directly contacting the NCC written all over it, to say nothing of how we handle this in the database ) Regards, -- Bruce Campbell RIPE Systems/Network Engineer NCC www.ripe.net - PGP562C8B1B Operations/Security "Text processing has made it possible to right-justify any idea, even one which cannot be justified on any other grounds." -- J. Finnegan, USC.
participants (7)
-
Brad Knowles -
Bruce Campbell -
Jim Reid -
Jon Lawrence -
Jørgen Elgaard Larsen -
Jørgen Elgaard Larsen -
Peter Koch