Thinking that things were going to calm down now that Smirk was headed off to Charlotte for a major server installation, I figured I might go through our DNS (Domain Name Service) records and insure they're consistent. Mainly because the major server installation is going into a second facility up in Charlotte, so we're expanding quite a bit.
Unfortunately, the DNS records are a bit of a mess, what with old records that have accumulated, making it difficult to figure out what's used and what isn't. There's also the problem that we have three types of servers—the physical servers, virtual servers (a complete operating system installation on a simulated machine) and what I'll call pseudo-servers, which are basically glorified websites with their own IP address. It's not always clear what is what (yes, our internal records could be a bit better, but it's an issue we're aware of [1]).
I'm stumbling over the fact that I want to organize the DNS records, but I'm not sure how I want to organize them. Right now, the records are pretty much flat—that is, we have alpha.example.net, bravo.example.net and charlie.example.net, but alpha and bravo are here in Boca, while charlie is in Charlotte (and delta.example.net will be in the second Charlotte location). It's one way of doing things, and it's not bad, since for the most part, we don't care where the servers are physically located. But then we need to filter traffic for bravo and that's a virtual server and you can't really filter the traffic on the virtual server, you need to filter it on the actual server it's running on. I don't remember if that's alpha or romeo. (Or does romeo even have virtual servers? Am I mixing it up with juliet?) And is this level of information even something I want to have in DNS?
And then there're the routers. Since I started at The Company [2] our network has expanded quite a bit (enough to make OSPF (Open Shortest Path First) worth while) and dealing with traceroute becomes an issue. About a year ago, I set up DNS records for the various routers with the names encoding the interface being used. But in the past year, not only have certain routes changed (say, the other end of se0-0.router.customer was moved from se2.edge1.bct.rt to se0-1.edge2.bct.rt (where rt is “router” and bct is the airport code for Boca Raton)) but the interfaces have changed as well (for example, going from a single T1 serial connection to a multipoint link binding multiple T1s). So is the interface type important to know? Or just the router? (I'm thinking—just the router). Also, note the name I gave our edge router—edge1.bct.rt. Conceivably, this means I can create a DNS zone rt, which contains all our routers. But by the same token, I'm inclined to create a DNS zone bct, which contains the routers located in Boca Raton.
Basically, is name.bct.rt better or worse than name.rt.bct?
I don't know. But I do know that we have stuff other than routers that's somewhat datacenter centric, like managed switches we have in Boca, as well as Charlotte (airport code of ctl).
Ah … I'm thinking too hard on this. Time for some Dicewars [3] …
(oh, and it turns out Smirk didn't leave for Charlotte today after all—too much stuff came up at the last minute and pushed his trip back a few days)