Drowning in a Sea of Logic

Given any suitably complex structure, when does the application of a logical and orderly layout collapse in on itself when met with the realities of every day use? Can an emphasis on logical address or namespace layouts become a hindrance rather than a benefit?

A specific example might be the DNS structure of an internal organization. Supposing that Hossenfeffer Foods has three locations, 1,200 users, and 40 servers. It would be quite simple to place the whole internal organization under the domain hossenfeffer.com, with hosts identified by their hostname or static DNS entries. There is a desire for DNS names to reflect physical location, however, so subdomains are created.

Then, layer three switching is introduced in all buildings, and the DNS structure is updated to reflect the VLANs

The whole purpose of DNS is to provide a facility to match names to numbers, since humans have an easier time matching a function to a name, rather than a number. www.amazon.com is easier to remember than 207.171.183.16. DNS also exists to facilitate easier back-end changes in server and network resources. If Amazon changes the IP range for their webservers, they need not tell anyone besides their DNS server, and business will continue as usual. Ditto for the utilization of DNS for the purpose of round-robin load balancing. But for the purpose of hossenfeffer.com, are the extra layers necessary?

Take troubleshooting, for example. `ping host234.acct.admin.hossenfeffer.com` is 41 characters. `ping 172.18.32.234` is 19. Where’s the benefit in that? Internal DNS is useful for quick digital-to-mental maps; the desire is to ping a host to test for connectivity, and that host should exist in the “acct” VLAN in the “admin” building. Typing 41 characters to achieve this isn’t productive.

What if the IP structure matches the physical location, so 172.18.32.234 reflects a physical location in the second octet (172.18.0.0/16=admin) and the VLAN is the third octet (32=acct)? Which is easier to work with on a daily basis? Perhaps both. We’re working without rules; we can do as we please, and should make our best guess as to what the future may bring.

The logic and cleanliness of any namespace architecture is wholly dependent on the maintenance of that architecture. Once the scheme is altered, it immediately loses viability and integrity. For instance, say Hossenfeffer completes an acquisition of another company; the desire is to combine the networks as quickly as possible. The DNS structure of the acquired company is well laid out, but in no way matches the layout currently in place. Time doesn’t allow for a wholesale change in DNS structure, considering the ramifications of such a change include the potential for serious problems with existing application architectures. It’s decided that the DNS structure shall remain in place, with the existing domain name until management decides it’s time to remove all references to the old companies’ name. If a sub-domain structure didn’t exist, it would be simpler to make the migration, but alas, we must rebuild from scratch.

DNS is a simple example. The 800lb gorilla is IP addressing at the network level, LDAP structure at the directory level, and perhaps email structure at the application level. So, what’s the solution?

The answer is fairly simple, if not as satisfying as we wish; we can’t achieve perfection, but we must continue to head in that general direction, holding the line as best we can while buffeted by political and economical winds. Make the best decisions you can when in the design phase, with a keen eye on reality. You can’t predict the future, but that’s no reason to let the present suffer.