>>
> IPv6 is not IPv4. Lots of things have changed since ISP's > started pre-populating reverse zones. There was no dynmic > updates being done by default. You can have different > expections with IPv6 than you did with IPv4. So, it's a lovely theory but the reality is this: - Customers often have pathologically broken networks - The internet is NOT a corporate or university environment. We don't get to set policy, domain names etc. I don't want to have to have my DNS servers need "acceptable word" filters or domain filters about what can and can't be set. - Customers get broken computers, CPE, whatever that causes ugly effects (ie. we frequently see SIP CPE that generate a register every second - a few of those (say a few thousand) gives you a thousand registers / sec). - Some customers will, for whatever reason, not want to or be unable to do the updates - so I want to have a way of doing it for them simply and easily. > > >> I don't actually want to scale our nameservers to have to cope with >> an >> extra million or so updates per day - what happens if something >> breaks >> and suddenly I get 200,000 update requests in a minute? > > The same way as you deal with 200,000 DHCP requests a minute. :-) We don't run any DHCP for customers. Most customers get IPs from pools on the LNSes because it scales better and reduces the routing load and complexity on the network. I want to continue this for most customers. We run RADIUS. We can scale RADIUS any way we want because it's invisible to customers and it parallelizes where as DNS doesn't - all DNS updates have to make it to all servers that serve the domain in something akin to real time. Name servers are a public service to do resolution - I can't very well hide them from customers or the internet. Nor do I want to have to tie RADIUS servers to DNS servers to reset reverse mappings if a customer loses their connection if they don't have static ranges. (Don't argue with me about that either!) > > A sdb module or two which looks at the query name and > contructs a response would handle this. Now we're getting some where. That looks reasonably straightforward to do - especially as it's not actually a database. From the looks I just need to implement lookup() anyway. I tried looking for some simple example code - do you have any? It'd be good to be able to standardise that as a $GENERATE6 statement though - more flexible for more people ... MMC
