My posts about issues concerning Linux OS and network administration

IP segments, DNS zones and hostname best practice

Once I needed to come up with some reasonable convention of network and DNS zoning as
the company network should have consist of few offices connected together with few more server housing centres.

IP segments, DNS zoning and hostname conventions must have been taken into account.

I was given a free hand as any sofisticated network topology wasn’t build so far and whole company was using simple privat IP segment of 10.0.0.0/8 which satisfied some basic company needs.
First of all I was searching for some “best practice” regarding server hostnames as well as DNS zones naming schemas. I discovered few posts about choosing right hostnames for servers, switches and printers which gave me some rough idea. Another thing I read was RFC 1178 about how to choose a right hostname

The only thing that seemed to be clear at this point was the fact that there would be different IP segments accross all of company officess and server housing centers. Those would be then connected and routed together throgh some VPN server.

After while I came up with this:

  • Each server is assigned its unique number which is used as prefix for server hostname (e.g. server057 )
  • Switches are named likewise ( e.g. switch002 )

Ok, I found a table hostname convention for servers and switches but hostnames is one thing but how to fit those hostnames into DNS zone(s). I wasn’t determined yet if there should only be one DNS zone for a whole LAN including more server housings and offices. The server would be then identified as server001.domain.com. That’s nice but what if I want to get know about the physical location of the server as it could be placed in any office and in case of hardware failure one would need to see it. You could then see the way to solve all this be putting together the server’s hostname and it’s location. RFC 1178 says that you should avoid geographical names what makes sense when you imagine that once you could replace server A from city A to city B and at this point you would have server A in city B. Of cource you could still change server’s hostname but this is not the way I would choose as my primary goal was to pick unique hostname for each hardware piece which should never change in future and thus could be used for example in accounting system where you must have an ability to identify hardware according to it’s serial number or any other unique name.

This led me to give up the idea of one domain zone for a whole company as I could likely use different zones for different locations. In such zones could be then placed all servers and thus could also be easily observable their real location. Those zones looked like dcXX.company.com where DC stands for datacenter and XX for it’s unique ID. All you need is to have a list of what DC number is what location of your bussiness unit or you can just remember them if you have just few of them. The server with unique number 008 placed in datacenter 01 could be then reachable at server008.dc1.company.com. That’s pretty clear but what if I had much more datacentres and woudn’t know that server008 was placed in dc1 zone. Then I would have to look into DNS configuration files to find out where it was placed. The trick was to manage another special DNS zone adm.company.com where every single piece of hardware is registered as CNAME records pointing to proper DC zone. E.g. for “dig server002.adm.company.com” I should get result such as


server002.adm.company.com. 3600 IN CNAME server002.dc1.company.com.
server002.dc1.company.com. 3600 IN A 192.168.1.2

Another thing is that each server has a reference (in resolv.conf) to a domain where it’s placed. That’s nothing more than search dc1.comapny.com line in resolv.conf placed on every signel server. You might think what this could be good for but let’s assume we have more data centers and we would like to put few network services to them such as LDAP server, Database server. The point is to have just one independent LDAP server and one Database server in every single datacenter.

Those two service are likely common examples of services generaly used by other server applications (LDAP for system authentication and Database for some specific applications) of the same domain or network zone. Let’s suppose these two servers are accessible at server005.dc1.domain.com and server006.dc1.domain.com in data center #1 and at server007.dc2.domain.com and server008.dc2.domain.com for data center #2.

As we want to access them easily from other servers within DC1 and DC2 we can create a special CNAME records such as ldap.dc1.domain.com and db.dc1.domain.com pointing to real server hostnames ( server005.dc1.domain.com and server006.dc1.domain.com). This gives us the possibility to configure applications on all servers the same way no matter in which data center they are further placed as all their applications are still accessing just ldap and db hostnames and those is then server looking for within the domain mentioned in search domain parameter from /etc/resolv.conf.

example of DNS configuration (domain dc1.domain.com):


server005 A 192.168.1.5
server006 A 192.168.1.6
ldap CNAME server005
db CNAME server006

and thus we can just access ldap and db hostnames no matter what domain server is in as it allways will reach the proper service for our domain (due to resolv.conf configuration):


[root@server005]# host ldap
ldap.dc1.domain.com is an alias for server005.dc1.domain.com.
server005.dc1.domain.cz has address 192.168.1.5
[root@server005]# host db
db.dc1.domain.com is an alias for server006.dc1.domain.com.
server005.dc1.domain.cz has address 192.168.1.6

 

Next time I will present the automatic installations, VLAN configurations where this DNS zoning comes in handy…

Posted in network concepts, Network Topology

One Response to “IP segments, DNS zones and hostname best practice”


Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Bad Behavior has blocked 728 access attempts in the last 7 days.