DNS

From Omnia
Revision as of 21:48, 2 November 2014 by Kenneth (talk | contribs) (→‎DNS)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

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

Chapter 8 - SOA Record

TTL Record

Appendix A - BIND TTL Values

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:

  1. 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.
  2. 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.
  3. Configure your email program to check both mail servers. This avoids any email getting lost during the transition.
  4. Put up a holding page. This prevents visitors adding new content to your old site during the changeover period.
  5. 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.
  6. 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.
  7. Test everything works. Now the new site and email are live, check they all work correctly.
  8. Redelegate the domain. You can now safely change the domain's nameservers at your registrar. This change will take 24-48 hours to complete.
  9. 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

See DNS/Domain Name Search

keywords