2

I have a functioning DHCP/DNS (ISC Bind 9.6, DHCP 3.1.1) server running on Debian that I would like to add DynamicDNS functionality to. I have a pretty simple question: Does DynamicDNS require (or recommend) separate sub-domains? I have seen a few tutorials where the the clients that are acquiring their IP addresses and other networking information via DHCP are on a different sub-domain as the servers which are statically configured (both in terms of IP, and DNS). For example: All the clients are on ws.example.org and the servers on example.org.

Right now all of our servers and clients are in the same domain (example.org) but spread across different zone files (because we have multiple subnets). The clients are configured with DHCP and the servers are configured statically. If I want to setup DynamicDNS for the clients should I use a separate sub-domain? What's the best practice here (and why or why not would it be a bad idea to do otherwise)?

Thanks.

2 Answers2

2

No, it isn't technically required to have a separate zone for dynamic updates.

I think the biggest factor in using sub-domains for dynamic DNS has to do with security policies for updating the zone. In my opinion the permissions you can set in bind aren't very flexible, though newer versions are somewhat better. With allow-update (Bind 8.*) permissions are applied at the zone level, and not per record. So client a could update the record for you critical server if they had where using an IP address that was authorized to perform updates.

So in deciding about your dynamic DNS configuration, you have to decide if you think it is a good idea to let your workstations to possibly be able to change update records for some critical service. Or do you want to separate critical services off into one zone without dynamic updates, and other machines into the more dynamic zones.

Zoredache
  • 128,755
  • 40
  • 271
  • 413
1

Dynamic DNS doesn't need a separate sub-domain, but that's the easiest (and best) way to set it up.

If you restrict DynamicDNS updates to a subdomain (ws.example.org) and a subnet (both with no servers), it's fairly straightforward to set up the restrictions so that nothing too bad can happen. Worst case of something going wrong is one workstation being identified as another workstation.

If you set up DynamicDNS updates in the same main domain as where servers live, you have to be careful to set up restrictions so that workstations can't dynamically update themselves to being, say, www.example.org. It's been a long time since I looked at it, but you might end up needing a separate ACL for each server (or other device you want the name protected for). Similar issues with subnets.

freiheit
  • 14,334
  • 1
  • 46
  • 69
  • What exactly do you mean when you say there is "similar issues with subnets"? Are you referring to the possibility of a workstation accidentally ending up with the IP address of a server? –  Dec 23 '10 at 17:20