DNS Basics

Let’s talk about a topic that some people just don’t get, DNS. I’ll try to make is super simple to understand.

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 primary 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 forwards requests to.

Zone Transfers – these basically takes 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 about what you are trying to accomplish but you may have a case for these.

My DNS server has a Forwarder (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 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/zone/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 DNS Server since it’s not in cordero.me or kerrycordero.com
USES CONDITIONAL FORWARDER: ping dc2.kerrycordero.com —> this will be forwarded to 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 =
new-dc1 =

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 =

No you just have to change the new-dc1 and not worry about the old-dc1 because that record points to the new one.

One last thing are TTLs. Basically this is telling the client/end user how long they should cache that record for. If it’s set to 24 hours, the client will keep that record cached locally for 24 hours. This means 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

    Record Name . . . . . : support.rackspace.com
    Record Type . . . . . : 1
    Time To Live  . . . . : 47
    Data Length . . . . . : 4
    Section . . . . . . . : Answer
    A (Host) Record . . . :

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 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).

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.

Like everything in IT, PLAN IT OUT first before you go implementing.

More Stories
Data Center Temperature Best Practices