DNS
DNS
Linux DNS
See Linux DNS
Windows DNS
See Windows DNS
BIND
See BIND
Record Types
A
A - IPv4 Address
www.example.com. 300 IN A 10.0.0.10
AAAA
AAAA - IPv6 Address
www.example.com. 300 IN AAAA fe80::202:b3ff:fe1e:8329
CNAME
CNAME - Canonical name
www.example.com. 300 IN CNAME google.com.
- "A CNAME record or Canonical Name record is a type of resource record in the Domain Name System (DNS) that specifies that the domain name is an alias of another, canonical domain name. This helps when running multiple services (like an FTP server and a webserver; each running on different ports) from a single IP address. Each service can then have its own entry in DNS (like ftp.example.com. and www.example.com.). Network administrators also use CNAMEs when running multiple HTTP servers on the same port, with different names, on the same physical host. CNAME records are specified in RFC 1034" [1]
MX
MX - Mail Exchange
"MX Record (Mail Exchange Record) - These records is used by mail servers to determine where to deliver email. MX records should only map to A records (not CNAME records). If an MX record is missing for the domain the mail for the domain will normally be attempted to be delivered to the matching A record. So for the domain “example.com” if there were no MX records for “example.com” then the mail would be attempted to delivered to the apex / root record of “example.com”." [2]
example.com. 300 IN MX 10 mail1.example.com. example.com. 300 IN MX 20 mail2.example.com.
Format:
[priority] [mail server host name]
NS
NS - Name Server
example.com. 86400 IN NS ns1.example.com. example.com. 86400 IN NS ns2.example.com. ns1.example.com. 86400 IN A 10.0.0.11 ns2.example.com. 86400 IN A 10.0.0.12
PTR
PTR - Pointer
ptr.example.com. 300 IN PTR google.com.
SOA
SOA - Start of Authority
example.com. 900 IN SOA ns-509.awsdns-63.com. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400
Start of authority record. Enter all time
values in seconds.
Format:
[authority-domain] [domain-of-zone-admin]
[zone-serial-number] [refresh-time] [retry-time]
[expire-time] [minimum TTL]
SRV
SRV - Service Locator
srv.example.com. 300 IN SRV 1 10 5269 xmpp-server.example.com. srv.example.com. 300 IN SRV 2 12 5060 sip-server.example.com.
Format:
[priority] [weight] [port] [server host name]
TXT
TXT - Text
txt.example.com. 300 IN TXT "this is" txt.example.com. 300 IN TXT "so much fun"
SPF - Sender Policy Framework
example.com. 300 IN TXT "v=spf1 ip4:192.168.0.1/16-all"
CNAME Apex Issue
CNAME - Canonical name
www.example.com. 300 IN CNAME google.com.
- "A CNAME record or Canonical Name record is a type of resource record in the Domain Name System (DNS) that specifies that the domain name is an alias of another, canonical domain name. This helps when running multiple services (like an FTP server and a webserver; each running on different ports) from a single IP address. Each service can then have its own entry in DNS (like ftp.example.com. and www.example.com.). Network administrators also use CNAMEs when running multiple HTTP servers on the same port, with different names, on the same physical host. CNAME records are specified in RFC 1034" [3]
"CNAME Record (Canonical Name Record) - These are usually referred to as alias records since they usually map an alias to its canonical name. The name server does handle these queries differently from an A record. When a name server looks up a name and finds a CNAME record, it replaces the name with the canonical name and looks up the new name. This allows you to point multiple systems to one IP without specifically assigning an A record to each host name. If your IP was ever to change you would only have to change one A record." [4]
foo.example.com. CNAME bar.example.com.
may be read as:
- foo.example.com is an alias for the canonical name (CNAME) bar.example.com.
Good for aliasing a subdomain to domain apex:
- CNAME to record apex / root record in the same domain
www.example.com. 1800 CNAME example.com.
NOTE: Make sure to always include the trailing '.', unless you want the current domain appended.
Restrictions: [5]
- An alias defined in a CNAME record must have no other resource records of other types (MX, A, etc.). (RFC 1034 section 3.6.2, RFC 1912 section 2.4)
- CNAME records that point to other CNAME records should be avoided due to their lack of efficiency, but are not an error'
- Other DNS record types, such as NS, MX, PTR, SRV, etc. that point to other names should never point to a CNAME alias.
- Domains that are used for e-mail may not have a CNAME record.
- DNS rules prohibit the creation of a CNAME record at the zone apex (e.g., example.com). [6] "You cannot create a CNAME record for the top node of a DNS namespace, also known as the zone apex. (For example, if you register the DNS name example.com, the zone apex is example.com.)" [7] (Although some DNS services do allow it)
top node of DNS namespace = naked 2nd level domain = zone apex
"The problem is the DNS RFC (RFC1033) requires the "zone apex" (sometimes called the "root domain" or "naked domain") to be an "A Record," not a CNAME. " [8]
- mydomain.com - allows apex CNAMEs!
- dnsmadeeasy.com - does not allow apex CNAMEs
- amazon aws - does not allow apex CNAMEs, but does allow apex internal aliases
Oversimplified DNS - Start of Authority (SOA)
Oversimplified DNS - Start of Authority (SOA)
Oversimplified DNS
... or, even a rocket scientist can understand DNS
Step 3 - Verify SOA (Start of Authority)
GOAL: Find your
SOA record and make sure that it is accurate.
BACKGROUND: The SOA record has core information about your zone. It defines which server is your primary nameserver, your contact information (E-mail), how your secondary nameservers get updated, and the default (minimum) Time-To-Live values for your records.
Step 3a: Get your SOA data
To get your SOA data, you can use NSLOOKUP or DIG (or any other program, or a
web site, that can query DNS records from a nameserver you choose). You need to
use your domain as the domain name to query, query for the SOA record, once for
each nameserver on the list you wrote down.
Using NSLOOKUP, enter "server nameserver.example.com" (do this once for each
nameserver on your list, replacing "nameserver.example.com" with one nameserver
at a time). Then, type "set type=SOA". Finally, type your domain name
("example.com"). You will see the SOA record for your domain.
Using DIG, enter your domain name as the domain name to query, and enter each
server from the list you wrote down (one at a time), and look at the SOA or
"Zone of Authority" section.
Problem? Make sure that the SOA record returned by each name server is
identical. If the serial numbers are different, you will have to wait up
to the number of seconds listed in the "refresh" section of the nameserver with
the lower serial number for it to get updated (or more time if the secondary
nameserver can't reach the primary). If the primary nameserver has a lower
serial number than a secondary, you have a serious problem that you will need to
fix. If the serial numbers are the same, but other data is different, you have a
serious problem -- your primary was updated without updating the serial number
(update the serial number and the problem will get fixed).
Problem? The SOA record MUST be the FIRST record in your zone file,
and MUST also be the LAST record in your zone file. It must appear only those
two times, and both of the entries must be identical. This can be verified
correctly only on the nameserver itself; the procedure varies depending on the
software you use.
Step 3b: Check your SOA data
- MNAME ("Primary NS") - This entry is the domain name of the name
server that was the original source of the data (this entry MUST be your
primary nameserver). This is your primary nameserver, and MUST be the one and
only server that you ever update. You must not update the secondary server(s)
-- they will update automatically, based on this the SOA record.
Problem? This should be a fully qualified domain name .
- RNAME ("Responsible Person") - This is a DOMAIN NAME that
indicates the E-mail address of the person responsible for this zone. It MUST
be in the format username.domain.tld; IE "jimmy.example.com" if the E-mail
address is "jimmy@example.com". Problem? If this record has an "@"
sign in it, it is wrong! (some programs, such as Sam Spade, may put the "@"
sign in there when displaying it -- check the actual SOA record to be sure).
Problem? If this record doesn't have a domain name in it (ie, just
"hostmaster"), it is wrong!. It is recommended [RFC1912 2.2] to use the
format "hostmaster.example.com", of course making sure that
"hostmaster@example.com" is a valid E-mail address! If the E-mail address has
a "." in it, there must be a "\" before it (for example,
"scott\.perry.example.com" for "scott.perry@example.com"). Problem?
Make sure that there is no "@" sign in this entry, otherwise there is an error.
- SERIAL - This is a serial number (32-bit unsigned integer) that
must be incremented on the primary name server whenever a change is
made. The recommended [RFC1912 2.2] value for this is a 10-digit number in the
form YYYYMMDDnn (year, month, date, revision). For example, if you change the
primary on June 4, 2001, you would enter 2001060401. If you change it again
that day, you would enter 2001060402. Using this format (rather than 1, 2, 3,
4, ...) is very useful, as you can determine the last day the file was changed
(which comes in handy when looking at cached entries in other DNS servers). It
can also be used to double-check that you remembered to update the serial
number when you last made a change. Problem? Make sure that there is
NOT a decimal point in the serial number -- if so, it won't work as you think
[RFC1912 2.2].
- REFRESH - The number of seconds (32-bit integer) between the time
that a secondary name server gets a copy of the zone (or sees that it hasn't
changed), and the next time it checks to see if it needs a new copy. This
should be set to the amount of time you think it is O.K. for your secondary to
have out-of-date information when you update your primary server. An hour or
two might be a good value. If set too short (say, 1 minute), it will cause
more traffic. If set too long (say, 1 day), the secondary servers might give
out old information for up to a day. Problem? Make sure this value
isn't very high, say a week or more, or else it will take a long time for your
secondary nameservers to update when you make changes.
- RETRY - The number of seconds (32-bit integer) that the primary
name server(s) should wait, if an attempt to refresh failed, before making
another attempt to refresh. If your primary nameserver is reliable, this value
should never be needed.
- EXPIRE - The number of seconds (32-bit integer) that lets the
secondary name server(s) know how long they can hold the information before it
is no longer considered authoritative. A good value might be 2 to 4 weeks
[RFC1912 2.2]. It should be long enough to keep the data during a major
outage. Problem? Make sure that the value is greater than the minimum
and retry intervals, or else the data will immediately expire if the secondary
server can't reach the primary server.
- MINIMUM ("Minimum TTL") - The number of seconds that the records in the zone are valid for (time-to-live, or TTL), unless the records have a higher TTL value. This is VERY important! I would recommend setting this to one day, or less if you change your DNS often (note that RFC1912 2.2 suggests at least 3 days if your DNS is fairly stable). If you rarely change your DNS, and have a lot of traffic, you could increase this somewhat to minimize traffic. Problem? Make sure that this value isn't too long (say a week or more); otherwise, when you have to make a change to one of your servers, it will take this long before everyone knows about it -- and you may not have that much time. If you are about to make a DNS change, you can lower the value temporarily, wait the old default TTL, make your changes, and then raise it back again.
SOA Record
TTL Record
Migration Strategy
Set the TTL down to a few minutes.
DNS TTL -
- "TTL is an acronym for Time To Live and refers to the capability of the DNS servers to cache DNS records. It represents the amount of time that a DNS record for a certain host remains in the cache memory of a DNS server after the latter has located the host's matching IP address.
- By specifying TTL settings for a particular domain's DNS records, webmasters define the frequency of website content updates. The longer the TTL value is, the faster the domain resolution time periods will be. The TTL value can be set from one to several hours, if you are not planning any changes to your domain's DNS records in the meantime. If you need to make such changes, you will have to decrease the TTL value entry to several minutes to avoid any outdated data on your website." [9]
Move a Website to a New Server - The Seamless Way:
- Reduce the TTL for your domain records to 5 minutes. This means that when you change your records later on, everyone will pick up the change within 5 minutes. You need to do this step at least 24-48 hours beforehand, depending on the old TTL setting.
- Move your site and test it. This involves backing up the site, setting up your web space on the new server, uploading your site, and checking it all works.
- Configure your email program to check both mail servers. This avoids any email getting lost during the transition.
- Put up a holding page. This prevents visitors adding new content to your old site during the changeover period.
- Transfer site data again. To make sure your new site is an exact copy of the old, you'll need to re-transfer any last-minute changes that occurred on the old site.
- Change your domain records. This is the step that gets everyone looking at the new server. Since your TTL is 5 minutes, the changeover happens almost instantly.
- Test everything works. Now the new site and email are live, check they all work correctly.
- Redelegate the domain. You can now safely change the domain's nameservers at your registrar. This change will take 24-48 hours to complete.
- Shut down the old account. Once you're happy that the domain is moved across you can close down your old hosting account.
Short TLD Search
See DNS/TLD
See DNS/Registration