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.