The registrars are authorized to make changes to the ownership of the domains with the root name servers, and must collect and maintain your information in a database of WHOIS records that includes three levels of contact (registrant, technical, and billing), who are often the same person. Anyone can try and find out who owns a domain by running the WHOIS command and reading the output. Since your registration agreement requires you to provide accurate information to WHOIS (especially the email addresses), not doing so is grounds for nullifying your lease. Figure 17.5 illustrates the kind of information available to anyone with access to a command line.

Figure 17.5 Illustration of the registrant information available to anyone in the WHOIS system

The information in the WHOIS system is accessible by anyone, and indeed, putting your email in there will ensure your name begins to appear on spam lists you never imagined. Not only that, but disclosing your personal information can be a risk to your own personal security since contact details include address and phone number.

To mitigate those risks, many registrars provide private registration services, which broker a deal with a private company as an intermediary to register the domain on your behalf as shown in Figure 17.6. These third-party companies use their own contact information in the WHOIS system with the registrar, keeping your contact information hidden from stalkers, spammers, and other threats.

Figure 17.6 Illustration of a private registration through a third party

A private registration company keeps your real contact information on their own servers because they must know who to contact if the need arises. There are many reasons for wanting private registration. You should know that these private registrants will turn your information over to authorities upon request, so their use is just for keeping regular people from finding out who owns the domain.

Updating records in DNS may require at least 48 hours to ensure that the changes have propagated throughout the system. With so long to wait, you must be able to confirm that the changes are correct before that 48-hour window, since any mistakes may take an additional 48 hours to correct. Thankfully, Linux has some helpful command-line tools to facilitate name server queries such as nslookup and dig.

After updating your name servers with the registrar, it’s a good practice to “dig” on your TLD servers to confirm that the changes have been made. Dig is a command that lets you ask a particular name server about records of a particular type for any domain. Figure 17.7 illustrates a couple of usages of the dig command where different name servers have different values for a recently updated email record.

Figure 17.7 Annotated usage of the dig command

A records and AAAA records are identical except A records use IPv4 addresses and AAAA records use IPv6. Both of them simply associate a hostname with an IP address. These are the most common entires and are used whenever a user requests a domain through a browser.

Canonical Name (CName) records allow you to point multiple subdomains to an existing A record. This allows you to update all your domains at once by changing the one A record. However, it doubles the number of queries required to get resolution for your domain, making A records the preferred technique.

Interestingly, email is also partially controlled by DNS entries, so web administrators should be aware of these entries. Mail Exchange (MX) records provide the location of the SMTP servers to receive email for this domain. Just like the A records, they resolve to an IP address, but unlike the HTTP protocol, SMTP allows redundant mail servers for load distribution or backup purposes. To support multiple destinations for one domain, MX records not only require an IP address but also a ranking. When trying to deliver mail, the lowest-numbered servers are tried first, and only if they are down, will the higher ones be used. All email hosting services will describe how to configure your name servers to point to their servers in detail.

Name server (NS) records tell everyone what name servers to use for this domain. Like CName records they point to hostnames and not IP addresses. There can be (and should be) multiple name servers listed for redundancy.

Start of Authority (SOA) record contains information about how long this record is valid (called time to live [TTL]), together with a serial number that gets incremented with each update to help synchronize DNS.

TXT records and Sender Policy Framework (SPF) records are used to reduce email spam by providing another mechanism to validate your mail servers for the domain. If you omit this record, then any server can send email as your domain, which allows flexibility, but also abuse.

SPF records appear as both SPF and TXT records. The value is a string, enclosed in double quotes (" "). Since it originated as a TXT entry (i.e., an open-ended string DNS record), the later SPF field still uses the string syntax for reverse compatibility. The string starts with v=spf1 (the version) and uses space-separated selectors with modifiers to define which machines should be allowed to send email as this domain.

The selectors are all (any host), A (any IP with A record), IP4/IP6 (address range), MX (mx record exists), and PTR. Modifiers are + (allow), – (deny), and ? (neutral). You can write SPF records that allow or deny specific machines, address ranges, and more as illustrated in Figure 17.9.

Figure 17.9 Annotated SPF string for funwebdev.com

For a complete specification, check out⁷ where there are also tools to validate your SPF records. With email, it’s always the receiving server that decides whether to use SPF to help block spam, so these techniques will not stop all masquerade emails (as described in Chapter 18).