First, let’s talk about the difference between a zone and a domain.
There are several distinct zones in the DNS, distinguishing between the DNS namespace’s separately controlled regions. A DNS zone is a region of the DNS namespace under the control of one particular administrator or organization. An administrative area known as a DNS zone enables more precise control over DNS elements like authoritative nameservers. The DNS root domain is at the top of a hierarchical tree representing the domain name space. A DNS zone can start at a domain in the tree and descend through subdomains, allowing one entity to control several subdomains.
Associating a DNS zone with a domain name or a single DNS server is a typical mistake. A single DNS server can host many zones, each containing several subdomains. Zones in DNS are just used for control delegation; they are not required to be physically isolated from one another.
Take the cordero.me name and its three subdomains, prod.cordero.me, dev.cordero.me, and blog.cordero.me, as an example. Imagine that the support and community sites are more directly related to cordero.me and can be handled in the same zone as the major domain, but the blog is a powerful, independent site that requires separate management. In this scenario, blog.cordero.me would have its own zone, while cordero.me, the prod, and dev sites would all be in one zone.
Forwarders – resolve DNS queries that are NOT answered by this server – basically, if you are not in my DNS domain/zone, I’m going to forward you to these DNS servers. This is primarily used for external DNS lookups like the internet.
Conditional Forwarders – just like above, except this is saying, if you are not in my DNS domain/zone, I’m NOT going to send you to my Forwarders (above); I’m going to send you to the Forwarders listed here for these specific domains/zones. It’s almost like the one above but you get to choose which domains/zones you would like to forward requests to.
Zone Transfers – these take the whole zone and allow them to be transferred to a different DNS server. This process should be locked down if you do decide to use them. I’ve seen environments have this set to ANY and this is a security risk. As you can imagine, one bad character can suck down your whole DNS zone during their RECON stage. Conditional forwarding is usually a better way to go but it depends on what you are trying to accomplish.
=====EXAMPLE
My DNS server has a Forwarder 8.8.8.8 (so I’m using Googles DNS server if I can’t resolve it locally or if it’s not in my Conditional Forwarder list)
My DNS server has a Conditional Forwarder for domain/zone “kerrycordero.com” and I’m going to use my other DNS server 10.200.1.53 to resolve that domain/zone
LOCAL QUERY LOOKUP: ping [hostname] – ping dc1 = dc1.cordero.me (pinging a local hostname will tag on the local domain/suffix)
LOCAL QUERY LOOKUP: ping FQDN – ping dc1.cordero.me = dc1.cordero.me (same result as above)
USERS FORWARDER: ping www.cisco.com —> this will be forwarder to the 8.8.8.8 DNS Server since it’s not in cordero.me or kerrycordero.com
USES CONDITIONAL FORWARDER: ping dc2.kerrycordero.com —> this will be forwarded to 10.200.1.53 since I have a Conditional Forwarder config for this domain/zone.
Let’s talk about A records and CNAMEs real quick. A CNAME is basically a pointer. It can point to another CNAME or A record. Let’s say management came to you one day and said we need to change the A records names from “old” to “new”. You don’t want to have two A records like this:
old-dc1 = 10.1.1.11
new-dc1 = 10.1.1.11
This means you have to make sure you change the IP’s twice for two A records. It’s double the work. A more efficient and better way it to make the old-dc1 a CNAME and not an A record:
old-dc1 = CNAME new-dc1.cordero.me
new-dc1 = 10.1.1.11
Now you have to change the new-dc1 and not worry about the old-dc1 because that record points to the new one.
One last thing is TTLs. TTLS tell the client/end-user how long they should cache that record. If it’s set to 24 hours, the client will keep that record cached locally for 24 hours, meaning if you have a change to the record on the server, you, the client/end-user, will have to wait 24 hours or until the cache expires before it goes out to query again.
You can view this by entering the command: ipconfig /displaydns on the Windows device:
support.rackspace.com ---------------------------------------- Record Name . . . . . : support.rackspace.com Record Type . . . . . : 1 Time To Live . . . . : 47 Data Length . . . . . : 4 Section . . . . . . . : Answer A (Host) Record . . . : 162.242.140.53
You can see above that the TTL is 47 seconds. If you refresh, it will go down. You can also view them on the DNS server. For Windows you have to make sure you enable advanced mode and you’ll see them. From there you can also change the settings or just script it with PowerShell.
The reason I bring this is up is because people forget about these and wonder why clients can’t ping the new FQDN. It’s usually recommended that if the FQDN is static and never changes, use 24 hours (86400 seconds). If you are using it for DR/Failover purposes or for some reason you need it to change often, set it 5 minutes (300 seconds). But if you are load balancing your DNS, you can set it 30 seconds on the LB side but keep the LDNS at the longer TTL setting.
For external DNS TTLs it’s different story based on your configuration and the service you have. I’ve seen Akamai use 10 seconds, 20 seconds, etc… So super low TTLs. This all comes down to the design of your DNS.
Like everything in IT, PLAN IT OUT first before you go implementing.