ip6.arpa help
Hi, I work for a small ISP in Sweden and we recently starting to provide IPv6 for customers. I have a problem thou with the reverse DNS lookups for IPv6. I don't have a good way of doing this, maybe someone can help. When we deliver IPv6 service to a customer they get at least a /64, which you all know is A LOT of addresses. This is impossible to generate unique PTR records for every address. The way we solved this is to use * PTR customer.domain.com. so that all addresses in the /64 will get the same reverse lookup. But if a customer need a unique PTR for a mailserver I cant use both *PTR customer.domain.com. and 5.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0 PTR mail.domain.com. in the same zone-file, the * will be ignored. Is this how it should be or am I doing it wrong? Instead maybe Bind can dynamically generate a answer for a reverse lookup request instead of storing all PTRs in the zone-file? Are there any good information, maybe RFC, how reverse DNS should be done in IPv6. Then I don't mean how to register a ip6.arpa and edit your zone-file in bind. I mean how you solve the problem with generate 2^64 unique PTR records for a single customer without filling your hard drive. =) Cheers // Mattias Andersson ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: ip6.arpa help
Den 18. mars 2011 kl. 10.07 skrev mattias.o.anders...@gavle.se mattias.o.anders...@gavle.se: Are there any good information, maybe RFC, how reverse DNS should be done in IPv6. Then I don’t mean how to register a ip6.arpa and edit your zone-file in bind. I mean how you solve the problem with generate 2^64 unique PTR records for a single customer without filling your hard drive. =) I'm in a similar situation, and no, I don't know of a nice and easy way of doing this with current software. Pre-generating reverse records for any possible IPv6 address in your prefix(es) isn't going to work. Adding it to your own services/servers such as email servers etc, that's easy. But how can you know which of the 2^64 addresses your customer is going to be using? I've been toying with some ideas, not sure which one would actually work the best way: - don't add any IPv6 reverse records for customers - you could take the overhead of letting your customers either ask for specific reverse records to be implemented (through customer service? self service web interface?) - if your customers get assigned addresses from DHCPv6, you might consider letting it update the zones for you - in theory you could delegate the responsability for reverse records in the customers prefix to them, but I doubt many customers would actually bother running their own nameservers for this. - perhaps some alternative nameserver software is capable of generating the reverse records on the fly, based on some template, if there's not a specific record already defined? -- Regards Eivind Olsen eiv...@aminor.no ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: ip6.arpa help
On Mar 18, 2011, at 5:07 AM, mattias.o.anders...@gavle.se wrote: Hi, I work for a small ISP in Sweden and we recently starting to provide IPv6 for customers. I have a problem thou with the reverse DNS lookups for IPv6. I don’t have a good way of doing this, maybe someone can help. When we deliver IPv6 service to a customer they get at least a /64, which you all know is A LOT of addresses. This is impossible to generate unique PTR records for every address. The way we solved this is to use “* PTR customer.domain.com.” so that all addresses in the /64 will get the same reverse lookup. But if a customer need a unique PTR for a mailserver I cant use both “*PTR customer.domain.com.” and “5.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0 PTR mail.domain.com.” in the same zone-file, the * will be ignored. Is this how it should be or am I doing it wrong? Instead maybe Bind can dynamically generate a answer for a reverse lookup request instead of storing all PTRs in the zone-file? Are there any good information, maybe RFC, how reverse DNS should be done in IPv6. Then I don’t mean how to register a ip6.arpa and edit your zone-file in bind. I mean how you solve the problem with generate 2^64 unique PTR records for a single customer without filling your hard drive. =) Cheers // Mattias Andersson ATT1..c How about just 16 records per such server? A lot less than 2^64, and the extra records could be generated by script. 5.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0 PTR mail.domain.com. 5.2.0.0.0.0.0.0.0.0.0.0.0.0.0.* PTR customer.domain.com. 5.2.0.0.0.0.0.0.0.0.0.0.0.0.* PTR customer.domain.com. 5.2.0.0.0.0.0.0.0.0.0.0.0.* PTR customer.domain.com. ... 5.2.* PTR customer.domain.com. 5.* PTR customer.domain.com. I believe that the serving of * is determined by RFC, so while BIND could have its own mechanism to generate records on the fly, it can't/shouldn't do something different with *. I suspect that IPV6 PTR records might fall by the wayside for the general end user, especially since mainstream IPV6 practices are still being formed and are likely tend toward what is practical. Automatically-generated PTR records have limited value, and *just might* make DNSSEC quite a challenge. Some other, more practical method may well be devised for ISPs to show what address space they are making use of. (For example, the powers-that-be could choose to provide two top-level PTR domains for IPV6: one for full records, and the other for subnet-wide wildcards.) John ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: ip6.arpa help
Hello, This was shared at RIPE61 and is pertinent to this discussion. It presents different approaches toward managing IPv6 PTR records for large subnets: http://ripe61.ripe.net/presentations/139-Ripe-61-rDNS-kzorba-freedman.pdf Thanks, Mark -Original Message- From: bind-users-bounces+mark.persiko=level3@lists.isc.org [mailto:bind-users-bounces+mark.persiko=level3@lists.isc.org] On Behalf Of Eivind Olsen Sent: Friday, March 18, 2011 7:07 AM To: bind-users Subject: Re: ip6.arpa help Den 18. mars 2011 kl. 10.07 skrev mattias.o.anders...@gavle.se mattias.o.anders...@gavle.se: Are there any good information, maybe RFC, how reverse DNS should be done in IPv6. Then I don't mean how to register a ip6.arpa and edit your zone-file in bind. I mean how you solve the problem with generate 2^64 unique PTR records for a single customer without filling your hard drive. =) I'm in a similar situation, and no, I don't know of a nice and easy way of doing this with current software. Pre-generating reverse records for any possible IPv6 address in your prefix(es) isn't going to work. Adding it to your own services/servers such as email servers etc, that's easy. But how can you know which of the 2^64 addresses your customer is going to be using? I've been toying with some ideas, not sure which one would actually work the best way: - don't add any IPv6 reverse records for customers - you could take the overhead of letting your customers either ask for specific reverse records to be implemented (through customer service? self service web interface?) - if your customers get assigned addresses from DHCPv6, you might consider letting it update the zones for you - in theory you could delegate the responsability for reverse records in the customers prefix to them, but I doubt many customers would actually bother running their own nameservers for this. - perhaps some alternative nameserver software is capable of generating the reverse records on the fly, based on some template, if there's not a specific record already defined? -- Regards Eivind Olsen eiv...@aminor.no ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: ip6.arpa help
You could just put the customer zones on a separate nameserver and let the clients dynamically update the zones. Windows will do this automatically. Named has 6to4-self and tcp-self which use TCP as the authenticator. 6to4-self lets any machine in the /48 update records for any other machine in the /48. tcp-self just lets the machine update its records. Adding 56-self and 60-self would be relatively straight forward. Named also has external match. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
