dynamic dns server?
dhcp1 at thehobsons.co.uk
Thu Mar 15 23:18:21 UTC 2007
>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" (10.0.0.250) 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