>>


> 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