Reverse DNS operational considerations in an IPv6 environment
I guess this is a question suited for this WG. References to other technical forums that can address this, or any pointers to established or not operational guidelines, are highly welcome. The question has to do with the provisioning of the reverse DNS entries of customers of a broaband provider in an IPv6 environment (PTR records in ip6.arpa). In the IPv4 world, each user receives mainly a single IP. There are dynamic and static users and most providers (including us) have pre-populated PTR records in their allocations in in-addr.arpa. PTR records can point to different namespaces depending on the address space use (eg static.<domainname> and dynamic.<domainname> for static and dynamic customers respectively). In the IPv6 case the problem is obvious because of the huge IPv6 address space. Since each customer can receive a /56, this is an assignment of 2^72 possible /128 addresses which is a tremendously HUGE number. We cannot possibly have pre-populated any zone with that many entries and this is just a single customer. The main question therefore is: how can we address this issue, if we need to have reverse DNS resolution for IPv6 ranges? The first thing that comes to my mind is using wildcard records in BIND, or skipping reverse DNS alltogether. Do you know of any operational recommendations? Thanks, Kostas Zorbadelos
We use wildcard records and then the customer can insert any custom content to override these (but beware that the deprovisioning fairy must visit your database tables when the customer leaves in order to keep this stuff clean) Dave. On 15/06/2010 07:58, "Kostas Zorbadelos" <kzorba@otenet.gr> wrote:
I guess this is a question suited for this WG. References to other technical forums that can address this, or any pointers to established or not operational guidelines, are highly welcome.
The question has to do with the provisioning of the reverse DNS entries of customers of a broaband provider in an IPv6 environment (PTR records in ip6.arpa). In the IPv4 world, each user receives mainly a single IP. There are dynamic and static users and most providers (including us) have pre-populated PTR records in their allocations in in-addr.arpa. PTR records can point to different namespaces depending on the address space use (eg static.<domainname> and dynamic.<domainname> for static and dynamic customers respectively).
In the IPv6 case the problem is obvious because of the huge IPv6 address space. Since each customer can receive a /56, this is an assignment of 2^72 possible /128 addresses which is a tremendously HUGE number. We cannot possibly have pre-populated any zone with that many entries and this is just a single customer. The main question therefore is: how can we address this issue, if we need to have reverse DNS resolution for IPv6 ranges? The first thing that comes to my mind is using wildcard records in BIND, or skipping reverse DNS alltogether. Do you know of any operational recommendations?
Thanks,
Kostas Zorbadelos
------------------------------------------------ David Freedman Group Network Engineering Claranet Limited http://www.clara.net
On 15 Jun 2010, at 17:18, David Freedman wrote:
We use wildcard records and then the customer can insert any custom content to override these (but beware that the deprovisioning fairy must visit your database tables when the customer leaves in order to keep this stuff clean)
Hmmmm. IMO deployment of wildcarding in the DNS is usually an indication that something has gone very wrong. It always gives me the heebie-jeebies. Reverse lookups for IPv6 addresses is a bit of a religious issue. IIRC someone (Johan Ihren?) gave a presentation at a RIPE meeting a few years ago and said it was best not to bother with any PTRs in the reverse zones for IPv6 space. I think his argument was the world was moving away from name-based access controls to things based on crypto tokens, making reverse lookups pointless. That said, my mail server does not accept inbound SMTP if the connecting host fails to have a working reverse DNS entry: this is remarkably good at spam suppression. Provisioning these IPv6 reverse zones is a problem for ISPs and I'm not sure what (if anything) is the Right Thing to do here. Perhaps this is something for the WG to consider and possibly work on: eg compare and contrast approaches, document use cases and so forth? Aside from Claranet, what are the other ISPs doing about provisioning reverse DNS for their IPv6 customers? DDNS with DHCPv6? Anyone care to share? My personal preference would be to delegate the /80 (or whatever) to the end-user/customer and leave them to choose how to provision that zone. [Your mileage may vary...] This might work fairly painlessly with the tcp-self and 6to4-self hooks to the update-policy{} clause in BIND 9.7. Though that's still messy. It also relies on well-behaved clients which is perhaps unwise.
Reverse lookups for IPv6 addresses is a bit of a religious issue. IIRC someone (Johan Ihren?) gave a presentation at a RIPE meeting a few years ago and said it was best not to bother with any PTRs in the reverse zones for IPv6 space. I think his argument was the world was moving away from name-based access controls to things based on crypto tokens, making reverse lookups pointless. That said, my mail server does not accept inbound SMTP if the connecting host fails to have a working reverse DNS entry: this is remarkably good at spam suppression.
We for one welcome our new ID/LOC split overlords :) Still, you will need locator rDNS and the locator space will still be as big... ------------------------------------------------ David Freedman Group Network Engineering Claranet Limited http://www.clara.net
On Tuesday 15 June 2010 22:06:11 David Freedman wrote:
Reverse lookups for IPv6 addresses is a bit of a religious issue. IIRC someone (Johan Ihren?) gave a presentation at a RIPE meeting a few years ago and said it was best not to bother with any PTRs in the reverse zones for IPv6 space. I think his argument was the world was moving away from name-based access controls to things based on crypto tokens, making reverse lookups pointless. That said, my mail server does not accept inbound SMTP if the connecting host fails to have a working reverse DNS entry: this is remarkably good at spam suppression.
We for one welcome our new ID/LOC split overlords :)
Still, you will need locator rDNS and the locator space will still be as big...
Sorry, but I understand nothing out of these phrases... Kostas
------------------------------------------------ David Freedman Group Network Engineering Claranet Limited http://www.clara.net
On Tuesday 15 June 2010 21:59:12 Jim Reid wrote:
On 15 Jun 2010, at 17:18, David Freedman wrote:
We use wildcard records and then the customer can insert any custom content to override these (but beware that the deprovisioning fairy must visit your database tables when the customer leaves in order to keep this stuff clean)
Hmmmm. IMO deployment of wildcarding in the DNS is usually an indication that something has gone very wrong. It always gives me the heebie-jeebies.
I can't imagine of a senario that this would be a problem, but I tend to believe you Jim :) Of course IPv6 produces a totally different world in many things and I guess reverse DNS is one of them. One of my thoughts on this is having wildcard records per customer vlan. If you chose a /56 customer assignment, that leaves you with 256 different /64 vlans. The main idea is to use them for different services (if we ever come to that many offerings). Internet access, VoIP/SIP and IPTV would be the first obvious choices in providers giving these services.
Reverse lookups for IPv6 addresses is a bit of a religious issue. IIRC someone (Johan Ihren?) gave a presentation at a RIPE meeting a few years ago and said it was best not to bother with any PTRs in the reverse zones for IPv6 space. I think his argument was the world was moving away from name-based access controls to things based on crypto tokens, making reverse lookups pointless. That said, my mail server does not accept inbound SMTP if the connecting host fails to have a working reverse DNS entry: this is remarkably good at spam suppression.
My guess is that the world will take a much longer time for such a change to occur. Although reverse DNS is used as a weak authentication mechanism today (if it can be characterized like that) it is not the only use. It is very convenient to see names instead of ugly IPv6 addresses in log files for instance.
Provisioning these IPv6 reverse zones is a problem for ISPs and I'm not sure what (if anything) is the Right Thing to do here. Perhaps this is something for the WG to consider and possibly work on: eg compare and contrast approaches, document use cases and so forth?
This is a good idea.
Aside from Claranet, what are the other ISPs doing about provisioning reverse DNS for their IPv6 customers? DDNS with DHCPv6? Anyone care to share?
Now DDNS is another thought. Can you imagine that working however in an environment of multi-million mobile and consumer devices powering up often, in a secure and scalable way? I find it a challenge, though never say never :)
My personal preference would be to delegate the /80 (or whatever) to the end-user/customer and leave them to choose how to provision that zone. [Your mileage may vary...] This might work fairly painlessly with the tcp-self and 6to4-self hooks to the update-policy{} clause in BIND 9.7. Though that's still messy. It also relies on well-behaved clients which is perhaps unwise.
The hooks you are referring to in BIND are DDNS stuff? Delegating the reverse space of the assignment to the end user sounds like a good idea, provided you have fixed customers with static assignments. You also have to address the issue for mobile one-off address users. The problem is not so much the address space used for servers and network elements. The provider can populate and maintain this space prety much as it does today. Consider home equipment, PCs with Windows 7 or any other operating system with similar behaviour, which as we noticed, apart from the autoconfiguration address, produce random IPv6 addresses used in outgoing connections that change every couple of hours or so. Add to all that some DNSSEC sugar ;-) Kostas
On 16 Jun 2010, at 07:56, Kostas Zorbadelos wrote:
Of course IPv6 produces a totally different world in many things and I guess reverse DNS is one of them.
+1
Although reverse DNS is used as a weak authentication mechanism today (if it can be characterized like that) it is not the only use. It is very convenient to see names instead of ugly IPv6 addresses in log files for instance.
I tend to agree. Though a cost/benefit analysis tends to suggest this convenience might not be worth the pain.
Now DDNS is another thought. Can you imagine that working however in an environment of multi-million mobile and consumer devices powering up often, in a secure and scalable way? I find it a challenge, though never say never :)
I imagine all sorts of things and you probably don't want to know what goes on inside my head. Really. :-) You're right to say that provisioning IPv6 PTR records for bazillions of edge devices is "challenging". In some cases it might not be worth the effort. [Would anyone care if the beer cans in my fridge had hostnames or if they got renumbered once I'd drunk them?] I think that was part of the argument that was being made about not bothering with PTRs for IPv6 addresses. Particularly for stuff that had transient or rapidly changing connectivity.
My personal preference would be to delegate the /80 (or whatever) to the end-user/customer and leave them to choose how to provision that zone. [Your mileage may vary...] This might work fairly painlessly with the tcp-self and 6to4-self hooks to the update-policy{} clause in BIND 9.7. Though that's still messy. It also relies on well-behaved clients which is perhaps unwise.
The hooks you are referring to in BIND are DDNS stuff?
Yes. The tcp-self and 6to4-self hooks allow clients to change the PTR for their own IPv6 address without needing a TSIG or other crypto token. The dynamic updates have to be made over TCP though.
The provider can populate and maintain this space prety much as it does today. Consider home equipment, PCs with Windows 7 or any other operating system with similar behaviour, which as we noticed, apart from the autoconfiguration address, produce random IPv6 addresses used in outgoing connections that change every couple of hours or so.
Add to all that some DNSSEC sugar ;-)
Yes. It's delightful, isn't it? The plug and play semantics of IPv6 pretty much force us down the road of DDNS for forward and reverse lookups if name<->address mappings matter. That in turn makes DNSSEC "interesting".
Hi Kostas, On 6/15/10 4:58 PM, Kostas Zorbadelos wrote:
I guess this is a question suited for this WG. References to other technical forums that can address this, or any pointers to established or not operational guidelines, are highly welcome.
Some of the possible options are documented in this Internet Draft: Reverse DNS in IPv6 for Internet Service Providers: http://tools.ietf.org/html/draft-howard-isp-ip6rdns-03 (also contains links to other relevant documents) And just for the record and for the completeness of the reference: the operational details on how to get the reverse DNS delegated to you from the RIPE NCC: http://www.ripe.net/rs/reverse/ I hope this helps, regards Vesna Manojlovic RIPE NCC trainer
On Wednesday 16 June 2010 10:41:13 Vesna Manojlovic wrote:
Hi Kostas,
On 6/15/10 4:58 PM, Kostas Zorbadelos wrote:
I guess this is a question suited for this WG. References to other technical forums that can address this, or any pointers to established or not operational guidelines, are highly welcome.
Some of the possible options are documented in this Internet Draft:
Reverse DNS in IPv6 for Internet Service Providers: http://tools.ietf.org/html/draft-howard-isp-ip6rdns-03
Excellent reference Vesna, thanks. Of course it is always very valuable to learn what is being deployed in the real world in Service Provider networks.
(also contains links to other relevant documents)
And just for the record and for the completeness of the reference:
the operational details on how to get the reverse DNS delegated to you from the RIPE NCC:
Thanks also. We already have the reverse DNS delegation for the IPv6 address space allocated to us. Kostas Zorbadelos Greek Telecommunications Organization (OTE SA)
I hope this helps, regards Vesna Manojlovic RIPE NCC trainer
participants (4)
-
David Freedman -
Jim Reid -
Kostas Zorbadelos -
Vesna Manojlovic