On Tue, 19 Jun 2007, William Allen Simpson wrote:
alex@pilosoft.com wrote:
Neither 'show ip route' or 'have a text file' scale beyond a hundred customers.
Hogwash. Used text file allocation for ~3,000 customers. After all, it is *REQUIRED* to exist (for bind). You need *a* canonical place that is authoritative for all others. Existing tools easily track commits.
DNS should always reflect reality. Then automated tools will show human readable information. Someday, it may even be authenticated (but I've been beating that horse for a decade). I'm sick and tired of bad NS data.
I agree, DNS should *reflect* reality, but I think it is very much misguided to say that DNS should be the place to have canonical information (i.e. source of all data). Canonical data is in routing/forwarding tables on routers/switches. That's the operational reality. The amount of data that you need to track IP allocations just doesn't fit well into DNS - there's no place to store customer id/service id, the length of allocation (is this IP part of a /28? /29?), etc. So you'll have to have "canonical data" somewhere else anyway.
Yes, we used a separate database for billing, and maybe could have automatically generated the text file. Didn't want the customer service/billing folks to have access to network configuration.... ;-)
Any time you have more than a single location for maintaining network configuration data, or allow technicians to just slap a route into a router on a whim, you are bound for future difficulties!
And when the routing table doesn't match, withdraw the route, and fire the miscreant that failed to properly maintain the allocation data! Unfortunately, I'll have to say again that this doesn't scale. :)
-alex