dynamic dns server?

Simon Hobson dhcp1 at thehobsons.co.uk
Thu Mar 15 23:18:21 UTC 2007

Craig wrote:

>Crap, that's what I thought. I left out some details.
>Currently, all of the machines are in the domain "example.com". we are
>trying to create some sub-domains: "servers.example.com",
>"desktops.example.com", etc. So, those sub-domains only exist in the
>"internal server" ( and not on the external (ISP) servers:
>So, there is no way to the OS on the dhcp server to figure out who is
>authoritative for the new subdomains (eg servers.example.com).

Like I guessed, broken dns ;-)

Apart from specifying servers in the zone statements, there are two 
ways to fix the DNS.

1) Put the internal zone NS records in the public server (ie properly 
delegate the zone) and accept that people might guess them and try to 
access them. In general it's a bad idea having private (rfc1918) 
addresses in a public dns, but personally i think this is OK since 
no-one should be able to see them - it's like like you are putting 
'well known' records like www.example.com in as private addresses !

2) Run a split dns where your internal machines use one set of 
servers running example.com and the public internet sees a different 
server with a different view of example.com. This is what I did at my 
last job and it works fine. Of course, the two views can simply be 
views in bind, they don't have to be different servers.

Given the choice I prefer option 2 - it keeps your outside visible 
dns clean. If someone takes a machine outside and it attempts to 
contact filestore.servers.example.com then it will get 'not found' 
rather than trying to contact a non-routable address. I have had one 
or two 'interesting discussions' with people who were adamant that 
this was a seriously wrong setup - as if NAT is a good idea in the 
first place !

More information about the dhcp-users mailing list