How To Keep Your Network Organized With DNS And Subnetting Schemes

• Standardized Naming Conventions
• Well-Designed Network Addressing and Subnetting

You may ask, "Why these two in particular?". Well, in my position as a pre-sales engineer, I encounter problems and issues related to these two fairly frequently.

As a IT professional I've battled these issues from several angles. Both being a slave to a network that evolved organically and to a network planned in way too much detail. Neither approach is ideal but both have merit -- like project management, it can either be part of the solution or part of the problem. I'd like to describe the problems and a solution. 

Try our free DNS Lookup tool

The DNS (Domain Name Service) Lookup tool will help you debug DNS related issues like global propagation, domain authority, MX records, security and performance.
Simply enter a target domain or hostname and click the "Lookup" button.
After a few seconds you will already see the results. Use the upper menu bar to navigate to the individual modules. You can find more tools in our free Paessler Monitoring Toolbox.

Naming Conventions

In the extreme cases, I have seen anything from random naming to deliberate obfuscation of duties of servers. Some more security conscientious argue, "If a name implies something about its duties, it is easier to compromise". That is true, a server named "xxx-Mail-001" would imply an SMTP/IMAP/POPx/etc server, but a port-scan would reveal the same information about what services it performs, regardless of the name. In addition, the size of the networks and the number of devices to be tested for vulnerabilities dictate that it can't be done effectively by humans.

There are instances where policies preclude the use of descriptive names for devices. These are usually government, law enforcement, or military/intelligence environments.  The benefit of using more descriptive names, to the people dealing with the plethora of servers in this sprawling virtual world, far outweighs the potential security risk.

A naming convention can go from the simple: SSSFFFF-NNN

     SSS = Site Code

     FFFF = Function {DBMS|LDAP|AD|...}

     NNN = sequence

To the more complex: OOOSSSotFFF-NNN, where

     OOO = Organization

     o = OS {W[indows]|L[inux]|S[olaris]...}

     t = Device Type  {W[ebserver]|N[as]|...}

And so on.

The conventions do not have to be as structured as these, but the names should imply something... A friend manages hardware at a university in Texas. They use themes for the machine names and each lab has its own theme: Hats (Fedora, Bowler, Caps, Stetson), Cities (Names of cities and towns, where servers have names of major cities), etc.

What is important is that it helps the people managing the devices to remember the names and functions of the different devices.

Designing IP Networking Schemes

Just like with the naming schemes, using IP sub-netting schemes will make life easier on many levels.... It is surprising how many networks just evolved without planning. As mentioned in the "No Quick Fixes" section of the "12 Characteristics" article mentioned above, put a little thought into it before "fixing" the network. In my past experience, these fixes tend to grow out of proportion. When one network runs out of available IP's,  it gets expanded. In the end you may be left with a 10.0.0.0/255.255.0.0, a half class A! Not a good situation. A little upfront planning in the form of general guidelines would have done wonders.

• Break up large networks to isolate broadcast domains by introducing more routers (Layer 3).
• Force clients to access services across IP subnets, thereby making traffic cross a router or other Layer 3 device (which enables the capture of flow data). When you have flow data, you can profile traffic patterns to plan for expansion.
• Concentrate servers in their own subnet to make them easier to protect

There are some general network use cases or patterns:

• Mixed use, which includes most smaller networks
• Wireless LAN
• VPN
• Client LAN
• Virtual LAN (segments with virtual machines, physical/virtual or hybrid)
• Server farm networks, with multiple subnets allocated to servers
• WAN / transit networks and intra-router networks
• Management networks, which are back-haul networks for management of devices, usually separated for security.

Within all of these use cases, your IP allocation should follow a pattern.

Mixed Use Network

For a mixed use network, something like:

• First 8-10: Network infrastructure: At least the first 4 IP's for routers (2 routers and 1 shared), the rest for switches etc.
• Next 8-10: Servers: local file servers etc.
• Last 4: Reserve for expansion.
• Rest: Clients

Depending on the size of the subnet and the requirements, you may shift the allocations around, but proportions of the allocations should be about right.

Transit, VPN and WLAN Networks

In a Transit, VPN or Wireless LAN something like:

• First 4-8: Network infrastructure
• Last 4: Reserve for expansion.
• Rest: Clients

Client Networks

Once the network grows a bit, it is usually beneficial to segment clients from servers/services. This protects the infrastructure from the clients and makes it easier to control access.

Since client LANs usually have many physically attached devices, they usually look like the mixed use without the server segments.

• First 8-10: Network infrastructure: At least the first 4 IP's for routers (2 routers and 1 shared), the rest for switches etc.
• Last 4: Reserve for expansion.
• Rest: Clients

Server Networks

Server farms may be physical, virtual, or hybrid. What is more important is how you segment them. If it is a hybrid, split the IP allocations. It is recommended to segment the traffic: one for physical and one for virtual machines.

• First 8-10: Network infrastructure: At least the first 4 IP's for routers (2 routers and 1 shared), the rest for switches etc.
• Last 4: Reserve for Expansion.
• Split the remainder into chunks
• Authentication: Kerberos/AD/LDAP
• File Services: NAS/CIFS...
• DBMS
• Application services
• Web Services
• Etc.

This way you can quickly ID where the traffic is going.

Management Networks

Management networks are typically used by sites that have larger environments. It makes it easier to control access to the management interfaces for the various hardware. Also, the management network may be isolated from all the other traffic on the network, which makes it possible to monitor and manage even when the rest of the network may be unavailable...

Why All This Attention To The IP Subnets And Their Allocation And Distribution?

As you may know, Paessler is a Network Monitoring Company, we make PRTG. Why is this important to us?

Well, as strange as it may seem, it is ... NOT for us and NOT for our product.... We can monitor pretty much anything with an IP address.

But, it is important for our customers. A well-designed network will be easier for our customers to manage and grow into. Also, when they start to monitor it, they will be able to make discovery and identification of the devices around the network much easier.

If the administrator knows that the things they want to monitor are always within the first 20 IP's on each subnet, it will make it easier to create patterns for discovery. This would also make it easier to create discovery processes to find devices that don't belong and then to alert the admin to that fact. So, in order to allow the admins to perform their duties better, the introduction of a little order may go a long way....

Which is what my wife has been saying about my office for years... I guess she's right... But do NOT tell her I said that!