Domain Name System (“DNS”) and similar/related (e.g. EDNS, Reverse DNS, DNSSEC, DynDNS, Zone Transfers)
Some additional notes
The following are some additional notes related to DNS, which might not yet have been merged into the main document.
- TechNet article: Using an Internal Subdomain
- For more DNS config info, see also: RFC 1536: Common DNS Implementation Errors and Suggested Fixes
- TechNet info about DNS Interoperability mentions dynamic integration with DHCP.
- Secondary DNS servers: BCP 16: Selection and Operation of Secondary DNS Servers, perhaps especially RFC 2182: “Selection and Operation of Secondary DNS Servers”, Section 7 “Serial Number Maintenance”
- Config issues may be documented at RFC 4697: Observed DNS Resolution Misbehavior.
e.g. The protocols implementing/related to DNS
- [#edns]: EDNS
e.g. RFC 2671: “Extensions Mechanisms for DNS (EDNS0)” notes that (with implementations that pre-existed, before the creation of this RFC document), “The maximum allowable size of a DNS Message is fixed. Many of DNS's protocol limits are too small for uses which are or which are desired to become common.” So, an update to the DNS standard was made. Because some new features could not be added without breaking compatability, EDNS replaced the older DNS specifications. Most third mellenium implementations of “DNS” probably actually support these “EDNS” extensions. However, since the protocol itself wasn't renamed (these are just “extensions” to the older protocol), implementations usually refer to supporting the DNS protocol (rather than the EDNS specification).
- [#domnrule]: Rules about domain names
Since DNS has become such a widely used standard, and at least some patterns are likely to be recognized even by many people who don't consider themselves to be computer experts, information has been placed in the “Basics” Guide: section about DNS domain names. (There are also some commonly used DNS names which may help people locate systems offering specific services.)
RFC 1912: “Common DNS Operational and Configuration Errors” (page 2) (and continuing onto the following page) discusses some rules.
It explains, for instance, why a hostname of 0xe would be a bad idea (and it isn't just because the first character is a digit). However, the RFC 2219 doesn't really explain what the valid syntaxes for
are. Linux manual: section 3:
function may be authoritative sources to provide the missing details.
While most DNS software will look up information about the “resource records” associated with a domain, there is a standardized method of looking up information about the domain's registry information. The communications may use a protocol that is called WHOIS. RFC 3912: WHOIS Protocol Specification is a Standards Track document. When this registry information is discussed, the details of this protocol may often be referred to as the “WHOIS information” for the domain.
This information provides details about when the domain expires, and typically provides some sort of contact information. In theory, this is the contact information for a person in charge of the domain, although often domains will use some sort of marketed “privacy” feature where the contact information goes to the domain's registrar.
A full-featured Unix system will generally have the
A client using the WHOIS protocol has not been bundled as a part of Microsoft Windows operating systems, although a client for Windows can be obtained. (Warning: This software hasn't been heavily checked/verified by the author of this text, at the time of this writing. As a standard disclaimer, please determine any sort of security/stability impacts before using it.) One possible source may be LTR-Data's open source tools and utilities (files/whois.zip contains the executable, while source code is available in the files/source.7z file mentioned very near the top of the page).
Users of web interfaces for obtaining WHOIS information have been known to need to endure unpleasant experiences, such as dealing with slow interfaces, advertisements, or even blocks due to high usage (which force the user to use another interface; most frequently another web page). Becoming familiar with the command line client can avoid all these sorts of issues.
(More info?) See: DNS-based WHOIS
- [#dnsdusbl]: DNS Servers for clients to use
Some usable DNS servers that are commonly used:
- Internal: By using an internal DNS server, private domain names can be used. By having all clients point to an internal DNS server, changes throughout the organization can be done simply by changing the DNS servers. The main reason why public DNS servers may be used on an ongoing basis, even after private DNS servers have been set up, is that mobile users may not be able to use the internal DNS (at least prior to using a VPN) when the machines are outside the network. Also, the internal DNS servers themselves will need some other way to look up information for public sites.
- DNS provided by an Internet Service Provider. In theory, DNS servers provided by the Internet Service Provider may be the fastest (since that network traffic doesn't need to travel as far). Also, since this is generally part of the service that the Internet Service Provider is providing, and since such service is frequently paid, there is some monetary incentive for the provider to invest (as needed) in ensuring that the service is reliable.
Here are some other, more specific choices which are generally available. These are publicly available DNS servers which may be used as external DNS servers.
- Accessible via IPv6 and/or IPv4
- Google Public DNS is available via both IPv6 and IPv4
- Hurricane Electric
Until more offerings are available (and discovered and documented here), the offerings that are available are simply listed in both the IPv6 section and the IPv4 section.
See below sections for information that may apply to IPv6 only or IPv4 only.
- Accessible via IPv6
- See the documentation about FEC0:0:0:ffff::/126 for detials about being a sometimes-used location for private servers.
- 2001:4860:4860::8888 and 2001:4860:4860::8844 : Google Public DNS documentation
- 2001:5c0:1000:11::2 or 2001:5c0:1001::194 (described by FreeNet6 Tools)
- A DNS server at 2001:470:20::2 has been found. Perhaps it was intended to be used by users of HE.net's TunnelBroker.net's tunnels. (Those who are using that tunnel broker service may use this DNS server.) However, the Unbound DNS server (bundled with OpenBSD 5.7) had a default/sample unbound.conf configuration file showing this.
- Accessible via IPv4
- OpenDNS: IPv4 18.104.22.168 and 22.214.171.124
- In addition to just plain being usable, publicly, users may sign up with the site to set up some customizations such as blocking requests for certain types of sites (in order to filter entire domains or IP addresses as a method of content filtering). OpenDNS has announced usage by more than 1% of Internet users. (DSL Reports article about OpenDNS announcement of serving at least 1% of the Internet offers a sacreligious speculation, followed by some real insight about OpenDNS's presence.)
- [#gglpbdns]: Google Public DNS: IPv4 126.96.36.199 and 188.8.131.52
- (see news about Google Public DNS, Google Public DNS telephone support (877-590-4367 in USA and 770-200-1201 outside USA))
- Comodo Secure DNS
Designed to provide safety, this may integrate with an RBL to try to prevent access to malicious sites. The addresses are 184.108.40.206 and 220.127.116.11.
- [#dns42229]: DNS within IPv4 4.2.2/29
18.104.22.168 and nearby (22.214.171.124 through 126.96.36.199): An easy to remember IPv4 address that is short, and may have been the easiest to remember prior to Google's 188.8.131.52. Discussion on 184.108.40.206 where Dan Farrell (
dannosite.com) claims to have started the trend. Report by tummy.com indicates this might not be really desired for global use (by non-customers).
The organization overseeing these IPv4 addresses is called “Level 3 Communications”, and their network is used by many other large organizations. Fortune CNN archived by the Wayback Machine @ Archive.org notes, “Level 3 already runs the single most important part of the Internet. Of the 36,878 autonomous networks that collectively make up the global Internet, Level 3 (LVLT) is by far the largest and most interconnected.” These autonomous network numbers are key numbers affecting how traffic gets routed on the Internet backbone. AS Ranking shows Level 3's dominance: At the time of this writing Level 3 holds the top two AS numbers representing over 48,000 ASes, while the number three holder has only 16,702. CDN Reviews notes, “Operating on a Tier 1 network, the company provides IP, voice, video and content delivery for most carriers in North America.”
- Hurricane Electric
The Unbound DNS server (bundled with OpenBSD 5.7) had a default/sample unbound.conf configuration file showing this. Presumably that indicates that somebody has verified that 220.127.116.11 has verified this is intended for widespread usage by the general public (before including that address in that default file).
- SuperUser.com: Peter Cordess answer to Deltik's question identifies 18.104.22.168 as related to Cloudflare.com.
- Finding more public DNS servers
DNSServerList.org provides DNS servers that the site believes will be the fastest. (However, be wary of what would happen if an untrustworthy DNS server is used... If a formerly trustworthy IP address got into the hands of somebody who wanted to use it for rogue purposes, one certainly can't count on this website to both notice the problem and also, as infeasible as this would be, inform all people who have ever copied the old DNS address from when it was previously published.
- Common DNS Software
- [#dnsclint]: DNS Client software
See: DNS Client Software.
Some information has been moved from this page to that more specific page:
- [#dnssvr]: DNS Server Software
Some information has been moved:
DNSSEC uses EDNS and four new resource record types.The following may need a bit of clean-up...
RFC 4034 (and RFC 4033 and 4035). The DNSSEC-bis replaces the earlier documented DNSSEC (RFC 2535) for reasons described by Wikipedia's page on DNSSEC (section on DNSSEC “History”)
, the trio of which has led to RFC 2535 being marekd as obsolete) RFC 3833 documents how DNSSEC responds to some known threats to DNS (verify ???)
- [#dnscurve]: DNSCurve
Here is a bit of information about DNS Curve:
- DNSCurve Internet Draft
- Info from MaraDNS site: MaraDNS Blog page about why MaraDNS won't implement DNS Curve once had comments. It seems, though, that comments have since been removed from the site. Before that happened, MaraDNS Blog page about why MaraDNS won't implement DNS Curve: comment # 1247970772303 had stated, “Mr. Kaminsky (the person who discovered how to poison DNS caches) has told me DNScurve isn't as secure as DNSSEC.” (Hyperlink added to quote.)
There might also be some info at http://cr.yp.to/djbdns/forgery.html
- [#revdns]: “Reverse DNS” (“RDNS”, “rDNS”)
- Reverse DNS via the web
- A well-known “Online Reverse DNS Lookup Tool” shows the first Reverse DNS entry for an Internet address.
- Querying “Reverse DNS” by using DNS queries
- General method(s)
The standard “reverse DNS” (“RDNS”) record related to an IP address is obtainable by following specific steps. These steps involve using a standard DNS query, sent to a standard DNS server, to obtain a PTR record of a domain name that fits a specific pattern. The first step is to know what IP address to look up the results for. The second step is to determine which well-known precise domain name is used for the type of address that is going to be queried. Then the third step is to use DNS client software to perform a standard lookup of a PTR record for that domain.
- Proper methods, which should work, to look up Reverse DNS intro
- Performing Reverse DNS lookups (by using a DNS query) for an IPv6 address
For an IPv6 address, the first step to determining the domain to use in the DNS query is to expand any IPv6 to a non-abbreviated form, including every leading zero, so that there are thirty-two hexadecimal digits that represent each of the thirty-two nibbles. This is necessary because all thirty-two of these digits are going to be used. Then, instead of separating the quads of nibbles by colon like standard IPv6 notation would dictate, place a period between each of the digits so that the address is written out in a dotted-duotrigint. Then, reverse the order of the digits. Finally, append “.IP6.ARPA” to the end. An elaboration, to disect an example, is shown next.
RFC 3596 section 2.5 provides an example. (There is not supposed to be any white space in the results, despite the white space that shows up in the RFC. Also, the period after the TLD “ARPA” is optional just like any other standard domain in DNS.) As a slightly more elaborate example, consider an IPv6 address of 2001:DB8:7:6:50::4321 (which is being used here in compliance with the intent of RFC 3849). At some point, the double-colon is expanded to show the zeros: if that is done at this point (no reason to day) then the IPv6 address looks like 2001:DB8:7:6:50:0:0:4321. The first thing to do is to convert the IPv6 address into a big long set of 32 hexadecimal digits, inserting leading zeros as needed, and separating each digit with a period. The first half of the results of this process results in 22.214.171.124.0.D.B.126.96.36.199.188.8.131.52.6 which simply comes from adding the leading zeroes as needed. The second half of this is 0.0.5.0.0.0.0.0.0.0.0.0.184.108.40.206 and that involved inserting all leading zeros, including the zeros from the double-colon. Then, the whole address is reversed, so the first half looks like 220.127.116.11.0.0.0.0.0.0.0.0.0.5.0.0 and the second half looks like 18.104.22.168.22.214.171.124.8.B.D.0.1.0.0.2. After the first half of those numbers and the second half of those numbers, the suffix IP6.ARPA is added. (“.IP6.ARPA” was referenced by RFC 2874 (page 3). Much of the rest of that RFC related to using A6 resource records in DNS, although that resource record type ended up not being very widely favored.) The first half of the end results, then, is 126.96.36.199.0.0.0.0.0.0.0.0.0.5.0.0.6.0. and then 0.0.7.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA is the second half of the end result. The end result is always a domain name that is exactly seventy-two characters long (no matter how abbreviatable the original IPv6 address was when written in any sort of standard IPv6 notation.)
OLD TEXT? (This may need to be reviewed further...) similar to 4321:0:1:2:3:4:567:89ab which is converted by this process to a very long domain. The first half of the resulting domain is b.a.188.8.131.52.184.108.40.206.0.0.3.0.0.0.2.0. and then 0.0.1.0.0.0.0.0.0.0.1.2.3.4.IP6.ARPA is the second half of the domain. (The period after the TLD “ARPA” is optional just like any other standard domain in DNS.) In this example, the zero next to the five is the leading zero implied by the :567: portion of the address. To elaborate those steps a bit further (and to start with a more abbreviated example), 4321::1:2:3:4:567:89ab is turned to 220.127.116.11.0.0.0.0.0.0.0.1.0.0.0.2.0. followed by 0.0.3.0.0.0.4.0.18.104.22.168.9.a.b before the reversing of the nibbles. After reversing the nibbles, the results are what are shown above.
(Untested) Example in Unix (This may need to be reviewed further...)
BCP 109: Deprecation of "ip6.int" (RFC 4159) reverses any earlier recommendations (such as RFC 1886) to use a domain ending with “ip6.int”. BCP20 (RFC 2317 is about IN-ADDR.ARPA. Reverse DNS involves making an inverse DNS query. (Reverse DNS and Inverse DNS aren't substantially different things, unlike Reverse ARP and Inverse ARP.)
- Performing Reverse DNS lookups (by using a DNS query) for an IPv4 address
For an IPv4 address where a split on an octet boundary will work, the first step to determining the domain to use in the DNS query is obtained by taking the address in standard dotted-quad IPv4 notation, and reversing the order of the octets. For example, if the address to look up is 192.0.2.64, then the result of having those octets in reverse order and in dotted-quad notation would be 22.214.171.124. After performing that step, append the text “
.in-addr.arpa” to the dotted-quad. Using the example just discussed, the result would be 126.96.36.199.in-addr.arpa and that is the domain name to look up a PTR record for.
command to look up Reverse DNS information: an example
If the IPv4 address to check is 192.0.2.128 then run the following command:
(Optionally, after the address of the address to look up (which is the part ending with
.apra), place a space and then the name of a specific DNS server to use. This option is simply part of how to use command line options to provide details for the
command, which may also be used interactively.)
- [#nslrdni4]: Using the
- Additional ways of looking up Reverse DNS with tools that perform standard DNS queries
The following may or
may not work for an IPv4 address of
Whether this works or not may depend on implementations (perhaps varying by implementation of NSLookup, and/or perhaps implementation of DNS servers?). For instance, it may work with FreeBSD but not Microsoft Windows (verify?). (This might be what is referred to by RFC 1034: “Domain names”, section 3.7.2: “Inverse Queries (Optional)”.)
- Using dig
- Other options
- APNIC's info on Reverse DNS options provide additional methods of obtaining reverse DNS entries.
- DNS communications other than single host lookups
- Automatic assignment of DNS servers
This is typically handled by automatic addressing. For example, IPv4 DHCP option 81: ... is similar in nature. (It would be good to have more info here: e.g.: what DHCP options are typically used with DNS?) Further information about how to set the options, using automatic addressing software, may be covered within the section about automatic addressing.
- Zone transfers
- [#dyndnsup]: Dynamic DNS Updates (“Dynamic DNS”, “DynDNS”, “DDNS”)
Dynamic DNS Updating involves a client reporting to a DNS server so that the DNS server may create an entry for the client.
- DDNS Integration with DHCP
Draft: Failover refers to DDNS and RFC 2136: Dynamic Updates in the Domain Name System (DNS UPDATE). TechNet: Port Assignments for Commonly-Used Services refers to DNS Administration as using TCP port 139.
- Transaction Signature (TSIG)
- [#dnsrsrvd]: Official domains
IANA: Special-Use Domain Names lists some domains that are recognized as special, and also may refer to multiple other RFC documents, possibly including one or more of:
- RFC 6762: Multicast DNS which now does reserve “.local” (see also: the next items)
IETF BCP 32: Reserved Top
Level DNS Names (which is RFC 2606 at the time of this
- RFC 6761: Special-Use Domain Names discusses these further
Another resource from IANA's site: IANA: Reserved domains.
In a comment on Mark Marra's “Why you shouldn't use .local in your Active Directory domain name” article, Martin Grotegut notes ISO Standard 3166 reserving country codes AA, QM through QZ, XA through XZ, “and ZZ as user-defined codes. These will never be used in the public Internet!” Mark Marra responds that conflicts could still occur if multiple companies used the same domain name (and then tried to create a trust relationship). The safest approach to using unique domain names is generally to create a sub-domain off of an official, public, guaranteed-unique domain name that is using a public gTLD. (That should avoid many needs to rename domains for uniqueness, and avoid problems as long as the gTLD remains sufficiently controlled by a helpful organization.)
However, based on the previous paragraph, the following are names that should be available for “private” use, without risk of conflicting with any of the official domain names on the public Internet:
Anything ending with
Anything ending with
.qm.through anything ending with
Anything ending with a two letter domain that starts with x (
Anything ending with
(Don't be scared off by the optional trailing period, if that is unfamiliar to you. Since it is optional, you can typically leave it off. Just like most people refer to google.com instead of the fuller name of google.com. (with the optional trailing period), you may use something like .zz rather than the fuller .zz. (with the optional trailing period). If you didn't know about that optional trailing period, don't fear it, and try using it.
- Summary of some reserved domains
- Usage of the domain name .local is discouraged, unless used as described by IETF RFC 6762: Multicast DNS. (People who were trained to use use .local were using information based on an old common violation that was often considered to be somewhat okay until the new standard was made. The violation is that people were using a top-level domain not endorsed by ICANN
Usage of the domain names example.com and example.org and example.net seem to have become a bit popular, but they are in violation of RFC 6761: “Special Use Domains”, section 6.5: “Domain Name Reservation Considerations for Example Domains” unless they are used as documentation. IETF BCP32 points to RFC 2606 (at the time of this writing); RFC 2606 “Reserved Top Level DNS Names” section 2 “TLDs for Testing, & Documentation Examples” had these reserved as “recommended for use in documentation or as examples.”
- The “example” domain is the same as the other example domains. For instance, usage machine.example is meant to be treated similar to how machine.example.org would be treated. The domain name called “example”, which covers domains that end with the word “example”, is also mentioned by RFC 2606, IETF BCP32, and RFC 6761.
- The IETF BCP32 points to RFC 2606 (at the time of this writing); RFC 2606 “Reserved Top Level DNS Names” section 2 “TLDs for Testing, & Documentation Examples” noted that .test was “recommended for use in testing of current or new DNS related code.” However, the newer RFC 6761: “Special Use Domains”, section 6.2: “Domain Name Reservation Considerations for "test." clearly provides more widespread permission (in the first numbered paragraph of that section). IANA: Reserved domains refers to both of these RFC documents. IANA Assignments of Special Use Domain Names identifies RFC 6762 as the most relevant RFC (at the time of this writing).
- Misc notes
RFC 6761 provides details on how those special addresses are intended to be treated, including some domains that were just discussed in prior documentation, as well as .invalid and .localhost. Also, RFC 6761 also mentions the *in-addr.arpa addresses related to the IPv4 addresses in IETF BCP5 / IETF RFC 1918. (No similar note is made about similar IPv6 addresses, although RFC 6762 does mention some e.f.
ip6.arpa addresses that are also mentioned on IANA: Special-Use Domain Names and
- Alternate DNS roots
RFC 2826: “Internet Architecture Board” (“IAB”) Technical Comment on the Unique DNS Root condemns the practice of trying to use alternate DNS roots publicly. (However, it does say “This does not preclude private networks from operating their own private name spaces”, and so using something like “.local” is not explicitly condemned by this RFC, even if other sources may discourage its use.) Specifically, “names uniquely defined for the global Internet” should be fetched “in particular from the coordinated root servers of the global DNS naming hierarchy.”
A page called Best practices for DNS on a new domain has the following note: “Domain.local or domain.lan is a rubbish way of doing it, even in Windows. If you ever want any sort of integration in the future, then rip your domain apart. Using <internal>.mydomain.com is loads better and any non-Windows techs will thank you for using DNS properly.” Slashdot article on TLDs shows questions, about people using alternate TLDs, “why were they using invalid domains in the first place?” TechNet: Namespace planning for DNS does refer to using a name such as “internal” as described above (using an example of internal.example.microsoft.com (and then other machines might be placed under a different name such as external.example.microsoft.com). Microsoft's “Best Practice Active Directory Design for Managing Windows Networks” instructs people to create a name using the method just described, when the article states, “Add a prefix that is not currently in use to the registered DNS name to create a new subordinate name.”
TechNet: Internal Domain Information (OEM) says: “Using the .local label for the full DNS name for the internal domain is a more secure configuration because the .local label is not registered for use on the Internet. This separates your internal domain from your public Internet domain name. It is recommended that you not use the extension of your registered Internet domain name (for example, .com, .net, and .biz) as this can result in name resolution issues. Microsoft KB Q296250: DNS name recommendations for Windows Small Business Server (2000 and 2003) says, “Make the name a private domain name that is used for name resolution on the internal Small Business Server network. This name is usually configured with the first-level domain of .local. At the present time, the .local domain name is not registered on the Internet.”
MS Q254680: DNS Namespace Planning discusses DNS and Active Directory, and states, “It is critical that the design of the DNS namespace” ... “that exists on the Internet not conflict with an organization's internal namespace.”
Microsoft's “Internal Domain Information (OEM)” page says, “After you install Windows Small Business Server 2003, you cannot change the settings specified in Full DNS name for internal domain or NetBIOS domain name. These settings are used to configure server applications during Setup. If you want to change these names, you must reinstall Windows Small Business Server 2003.” Ouch! That seems like incentive to get the naming scheme correct.
Since there mustn't be a name conflict with public DNS, one may think to just use public DNS in a non-conflicting way. If this is done, this ends up meaning that the organization who uses that Small Business Server installation needs to make sure that organization keeps control of the public DNS name. If the domain name ends up going to someone else's control, then there could be a conflict and the only way to resolve that might be to re-install the operating system. In addition to issues if the domain changes hands (and keep in mind that many things might change hands when a business is sold), consider also about whether the computer (which will be running the Small Business Server operating system installation) might ever want to be transferred to another party (possibly due to selling equipment, or spinning off a new business).
- Using .local (not to be confused with RFC 2606 (page 2)'s .localhost)
Although some text from Microsoft has rather suggested that using a “.local” domain for Active Directory may be a good and even recommended practice, the practice has always been fairly questionable. Newer changes in technology implementations have increased the clarity on this less deniable fact: using a “.local” domain for Active Directory domains is a bad idea. The practice of using this for Active Directory now conflicts with a newer multi-vendor standard that is documented in an IETF RFC (RFC 6762: Standards Track: Multicast DNS), and this newer standard is being used by some newer technologies.
Wikipedia's page about domains ending with “.local”: April 13, 2013 update mentions the approach of using “.local” for Multicast DNS and the approach of using “.local” for Active Directory, and has stated that using multiple...
approaches on the same network can be problematic, however, so resolving such names via “unicast” DNS servers has fallen into disfavor as computers, printers and other devices supporting zero-configuration networking (zeroconf) have become increasingly common.
Why you shouldn't use .local in your Active Directory domain name discusses some disadvantages, and cites Microsoft's “Best Practice Active Directory Design for Managing Windows Networks” (from the days of “Windows 2000”) which stated, “As a best practice use DNS names registered with an Internet authority in the Active Directory namespace. Only registered names are guaranteed to be globally unique. If another organization later registers the same DNS domain name, or if your organization merges with, acquires, or is acquired by other company that uses the same DNS names then the two infrastructures can never interact with one another.”
The only real good news on all this is that renaming Active Directory domains may currently be less painful than what many technicians have heard (or perhaps experienced) with older versions of Microsoft software. (For instance, see: TechRepublic: Active Directory Domain Rename - Not Difficult At All, or vkernel: renaming an Active Directory domain.) Complications may include using a domain controller pre-dating Windows Server 2003, or using Exchange 2007, or using SSL certifiations. However, software has been made more modular/flexible as time goes on, and additional documentation has been made, so the process is not likely worth much fear.
That being said, Mark Marra noted (in the Why you shouldn't use .local in your Active Directory domain name article), in a (initially truncated) comment, “There's no easy way for them to get off of .local.” ... “Unfortunately, Exchange 2007 and 2010 don't support a domain rename like Exchange 2003 did. Once you have exchange in a domain, it can no longer be renamed and requires an entire migration to a whole new domain.”
At this time, the right way of naming domains (e.g. actdir.example.com.) appears to be less likely to cause future issues than trying to use something like example.local, and it does now seem like knowledgable technicians are recommending to avoid using the improper use of .local that had previously been more common. So, if an operating system's software is defaulting to use a .local domain for an Active Directory name, change the bad default.
- Apple Roundevous (Mac OS X)
- Windows (Active Directory)
In the past, Microsoft does seem to have recommended using the .local domain. MS Q296250: Domain Name System recommendations for SBS 2000/2003 seem to recommend using .local, although really .local is simply an example of an example of a private name, and any private name would fit that recommendation just as well. Microsoft's page called Internal Domain Information (OEM) says “Using the .local label for the full DNS name for the internal domain is a more secure configuration because the .local label is not registered for use on the Internet. This separates your internal domain from your public Internet domain name.”
Internal Domain Information (OEM) provides what is probably a newer recommendation: Do not use .local on a network where clients using Mac OSX version 10.2 or newer may exist (although the conflict may be worked around with OSX version 10.3 or later, as noted by the file available at the Download page for SBSMacDoc.doc, a file described as “Connecting Mac OS X 10.3 and Higher clients to a Windows Small Business Server 2003 Network”. Lower in the page, examples of “.lan or .office” are provided (to the dismay of anyone who opposes .local on the grounds of it not being a public domain).
Stats about invalid queries shows that .local seems to have a large number of invalid SOA queries.
- [#dotsex]: .sex
An actual domain of addresses ending with “.sex” may refer to a domain used by an alternate root (such as AlterNIC which referenced a domain involved with Skyscape Communications Inc., at http://www.fastlane.ca/) or a proposed (but, as of the time of this writing, not yet existant) ICANN TLD (used by the mainstream Internet implementations). For example of a reference to a not-yet existing domain supported by the ICANN TLD, there is RFC 3675: “.sex Considered Dangerous” (from February 2004) which discusses not only a domain with addresses that end with a partial name of “.sex”, but also similar domains. Its “Background” section starts by noting, “The concept of a .sex, .xxx, .adult, or similar top-level domain in which it would be mandatory to locate salacious or similar material is periodically suggested by some politicians and commentators.”
Subsequently, ICANN approved of a domain ending with .xxx. The Register's artcile about the .xxx domain made the following statement about activity on Friday (April 15, 2011): “The first .xxx web addresses have gone live on the internet, almost 11 years after the extension was first proposed.”
- Inactive root zones
Some attempts to supplement (initially, and perhaps replace down the road) the offerings by ICANN have been attempted and apparently have not been successful (enough) to continue, as they have become inactive. Wikipedia's article on “Alternate DNS root”: section called “Inactve public root zones” lists some such zones.
- Open Root Server Network
This is historical, mentioned for reference. (It is not recommended for any current use.)
Open Root Server Network project shutdown by 31.12.2008 00:00 UTC shows this was shut down before the year 2009. Implementation of DNSSec was thought to be likely to lead to more interest, but the deemed decision was that there wasn't sufficient interest to continue this project. The recommendations were to use A through “M.ROOT-SERVERS.NET.” in root.hint/named.root instead of using A through “M.ORSN-SERVERS.NET.” in orsn.hint (and, if the filename of orsn.hint must be used for some reason, to replace its contents).
Wikipedia's article on “Alternate DNS root”: section called “Inactve public root zones” mentions that this used to be a mirror of ICANN root.
- More information
- Slashdot commentary by “TheLink” about TLDs references L. Yeoh's proposition of a .here domain. See also: Slashdot commentary mentioning modern problems with using .local.
- Providing domain information
- [#usednsnm]: Commonly used DNS names
See: RFC 2219: “Use of DNS Alaises for Network Services”: section 3: “Special cases”. (At the time of this writing, that RFC, RFC 2219, is what IETF BCP 17: “Use of DNS Alaises for Network Services” refers to. So, IETF BCP 17: “Use of DNS Alaises for Network Services”, section 3 may also be a way to refer to the same “Special cases” section.)
- [#dnsrrtyp]: ”Resource Record” types
There are several standard types. This is shown by the registry of IANA's list of DNS Parameters assignments. IANA's document for “Domain Name System (DNS) Parameters” lists various record types as well as a numeric value for those types. There are also many types listed by Wikipedia's list of DNS record types. Both of those resources provide references to the various RFCs that introduce/define the common resource record types.
Here are details on at least some of the types:
- [#dnsrcrda]: “A” Record
The content of an A record depends on what “class” is being used. If the class is “IN”, then “the Internet system” is being used, according to RFC 1034 page 12 and page 13. In that case, meaning when Internet addresses are being used, the value of the “A record” is simply a standard IPv4 address.
(The following paragraph is trivia: information which is not likely to serve a real wide-spread purpose. It may answer some questions to address some curiosity, or create new curiosity. Feel free to not worry much about these details if they seem to lead to confusion.) If the class is set to “CH”, then “the Chaos system” is being used instead. In that case, the A record is set to “a domain name followed by a 16 bit octal Chaos address”. RFC 4892 (ID'ing a DNS Server) Section 2.2: “Disadvantages” describes this support as being a bit wasteful. For more details about Chaos, see Wikipedia's article on Chaosnet. This class is also mentioned by RFC 1035 section 3.2.4: CLASS values.)
Additional RFC reference: RFC 1035 (DNS “implementation and specification”) section 3.4.1 (“RDATA format” of an “A record”)
Some quick hints when choosing addresses: if automatic addressing is set up, check the configuration of the server(s) for a list of reserved IP addresses. Also, system address usage is an available template which could be used when addressing a network.
- [#dnsraaaa]: “AAAA” Record
- [#dnsrasix]: “A6” Record
An IPv6 address. The instant question many people will likely wonder, upon hearing of this resource record type, is: How does this compare with AAAA records?
Both A6 records and AAAA records are methods to provide an IPv6 address for a named computer. Quoting IETF's Internet Engeineering Steering Group's announcement about the “protocol action” about A6/DNAME, “the IETF standardized two different ways to store IPv6 address information in the DNS. This has led to confusion and conflicts on which one to deploy.” The two methods were the AAAA records and A6 records. Essentially, A6 was a new method that was proposed, but opposition to A6 and DNAME led to the IETF's Internet Engeineering Steering Group “protocol action” which “reclassified” some things “from Proposed Standard to Experimental.” Basically, support for A6 is on hold, if not reversed. The relevant protocol action announcement says “The (rough) consensus of the community is that the A6, Binary Labels and DNAME DNS extensions should not be widely deployed for use with IPv6 at this time” (Hyperlinks may have been added to quoted text.) RFC 3363 (IPv6 addresses in DNS) discusses this.
- [#dnsrrptr]: “PTR” Record
PTR stands for “pointer”. Often used with Reverse DNS (although other records are also, less commonly, used for this purpose: Wikipedia's Reverse DNS page: section on non-PTR records mentions TXT or LOC records). Wikipedia's list of DNS record types: Section on PTR records says “The most common use is for implementing reverse DNS lookups, but other uses include such things as DNS-SD.”
RFC 1912: “Common DNS Operational and Configuration Errors” (Page 2) says “PTR records must point back to a valid A record, not a alias defined by a CNAME.”
Page about IPv6 and DNS shows IPv6 format: each digit is written out in reverse order and is then separated by dots (ignoring the grouping that colons offered) and then “.ip6.apra.” is appended.
RFC 2181 (“Clarifications to the DNS Specification”) Section 10.2 (“PTR records”) states, “There is no implication in” the DNS specification “that only one PTR record is permitted for a name.”
- [#dnsrrmx]: “MX” Record
MX stands for “Mail Exchange”. RFC 1123 section 5.3.5 requires that this record type is supported (by E-Mail software).
RFC 974 (page 6) discusses issues when using an MX record that points to a name which has a CNAME record. RFC 1912 (page 7) clearly condemns this practice. Meng Weng Wong's counter: MX pointing to CNAME is okay provides reasons why this should be considered an acceptable practice. (It cites a “bat book” which is likely referring to O'Reilly Sendmail Desktop Reference (1st Edition).)
RFC 1912 section 2.5 says, “Put MX records even on hosts that aren't intended to send or receive e-mail.” (This advice does not seem to be commonly implemented.)
Some recommendations to pass some anti-spam filters:
- Don't set the value of the MX record to an IP address. Instead, set the value to a name that may be looked up in DNS. Looking up the name in DNS should result in a standard name record for a computer (AAAA record and/or an A record).
- Have the Reverse DNS of the outgoing mail server start with “mail.” (This advice has been provided and seems like generally good advice. However, there is no RFC/etc. to reference the source of this advice.)
For machines receiving mail,
there are a few common prefixes:
- Have the name (of the computer pointed to by the MX record) be a name which starts with the word “mail.” in the beginning. (This will comply with RFC 2219: “Use of DNS Aliases for Network Services” Section 3: “Special cases”.)
- Commonly the destination starts with “mx#.” (where the # is not a literal pound sign, but a number: e.g. “mx1”, “mx2”, etc.). (This sort of naming scheme is similar to a method used for NS resource records.)
- Some places may use “a.mx.” on one machine, and have names that use subsequent letters of the alphabet for additional servers, such as starting with “b.mx.” (This sort of naming scheme is also similar to a method used for NS resource records.)
- [#dnsrrsoa]: “SOA” Record
Start of Authority
RFC 2181 (“Clarifications to the DNS Specification”) Section 6.1 (“Zone authority”) says, “The authoritative servers for a zone are enumerated in the NS records for the origin of the zone, which, along with a Start of Authority (SOA) record are the mandatory records in every zone.”
The RFC 1035 Section 3.3.13 describes the first part of an SOA record, which is a domain name.
Commonly, the value for MNAME is simply
which is an abbreviation, recognized by BIND (and probably lots of other software that process DNS zone files), which refers to the value of the
$ORIGINdefined earlier in the file.
- E-Mail contact info
RFC 1035 Section 3.3.13 calls this the “RNAME”, “which specifies the mailbox of the person responsible for this zone.”
RFC 1912: “Common DNS Operational and Configuration Errors”, section 2.2: “SOA records” notes that the preferred E-Mail address may be to “use the generic name `hostmaster'”. Then use internal mail redirection/routing as needed to get the mail to be handled as desired. The syntax for the E-Mail contact is similar to a standard Internet E-Mail address, except that the character seperating the username from the system name is a “full stop” (period) character, and specifically the first “full stop” (period) character which does not come immediately after a backslash. (A backslash should probably not be part of an E-Mail name, but if it is, presumably a double-backslash would be considered to be treated as a single escaped backslash (that does not escape the next character) That would be consistent with RFC 1035 page 35's description of the backslash.). So, if the E-Mail address was
then the SOA record would specify “
”, and if the E-Mail address was
then the SOA record would specify “
” as relevant E-Mail address information. (The ability to use the backslash to escape the period is clearly demonstrated by RFC 1035 section 5.3, and is even commented upon by the last sentence is that example. That ability also seems to be documented by RFC 1035 page 35 (although those “seems to be” “weasel words” were intentional, as this should be verified before being made as a stronger statement).)
RFC 1912: “Common DNS Operational and Configuration Errors”, section 2.2: “SOA records” discusses. It states, “Even though some BIND versions allow you to use a decimal in a serial number, don't.” (This is discussed further in the quoted RFC.) The quoted RFC goes on to state, “The recommended syntax is YYYYMMDDnn (YYYY=year, MM=month, DD=day, nn=revision number. This won't overflow until the year 4294.” [sic: missing parenthesis]
The official way to update a serial number on all DNS servers is to always increment. If a serial number is too high, see RFC 2182: “Selection and Operation of Secondary DNS Servers” Section 7: “Serial Number Maintenance” (or the older RFC 1912: “Common DNS Operational and Configuration Errors”, section 3.1: “Serial numbers”).
For the timers, RFC 1912: “Common DNS Operational and Configuration Errors”, section 2.2: “SOA records” focuses on this record type. Information in section 2.2, starting with page 4, provides some details about each of these timer values.
- [#dnsrcnam]: “CNAME” record
Canonical Name. Wikipedia's section on CNAME terminology points out that while the type of record is called a CNAME, the value of that record is a label, and that value “is most certainly not a canonical name”. However, an “unfortunate” reality is that the label has often been called a CNAME.
RFC 2181 (“Clarifications to the DNS Specification”) Section 10.1 (“CNAME resource records”) indictes that if a label has a CNAME, then it should have no other RR records except for those required to implement DNSSEC. (The way that was just stated is a generalization: The RFC is more specific and lists those exceptions. Those exceptions are the resource record types of SIG, NXT, and KEY.) RFC 1912 - Common DNS Operational and Configuration Errors (section 2.4: CNAME records) does not mention that exception, possibly because it simply pre-dates DNSSEC. It states, “A CNAME record is not allowed to coexist with any other data.” If the name of a domain or subdomain has a CNAME (that points to the name/label portion of an A record), the (sub)domain that is used with the CNAME record (that points to the A record) cannot have any other DNS resource records. If such a (sub)domain has any other value, the configuration, according to RFC 1912 section 2.4, is not valid.
Additional RFC reference: RFC 1035 section 3.3.1
- [#dnsrdnam]: “DNAME” Record
The IETF's Internet Engeineering Steering Group's announcement about the “protocol action” about A6/DNAME has moved RFC 2874 (which is identified as describing A6 and DNAME) from a “Proposed Standard” to “Experimental”. RFC 3363 discusses DNAME's fate matching that of A6. For more details on why this lost support, see the details provided here about A6 records.
The “protocol action” announcement just referred to references RFC 2874 as “A6/DNAME”. This makes it sound like RFC 2874 is the basic RFC that provides details for DNAME. However, there is also RFC 2672 (which may actually be more relevant to DNAME???).
- [#dnsrrns]: “NS” Record
See: RFC 1035 Section 3.3.11.
IETF BCP 17: “Use of DNS Aliases for Network Services” (more specifically RFC 2219: “Use of DNS Aliases for Network Services” Section 7: “CCSO service name” states that a system name of “
ns” is “being used by DNS to point to the DNS server. In fact, the most prevalent use of” (“
ns” as a system name) “is to name DNS servers.”
One common standard is to name the first server “
ns” and also
a.nsas relative names for a domain, and then to name a secondary servers
b.nsas a relative name for the domain. Another common method is to name the first server
ns1, and to name the second server
ns2(e.g, this is seen in RFC 1912: “Common DNS Operational and Configuration Errors” Section 2.3: “Glue A Records” shows this naming scheme being used)
- [#dnsrrspf]: “SPF” Record
Sender Policy Framework
RFC 4408. Basically the idea here is for the DNS host to allow E-Mail receivers (from any domain) to know what addresses may send E-Mails from the domain that provides the SPF record. Then servers that receive E-Mail can know that E-Mail coming from different IP addresses are not coming from an address that is recognized by the DNS host as one that is authorized to send mail. In theory, this may mean that the E-Mail is being relayed. In practice, a lot of E-Mail these days is performed with direct connections (when it is sent over the Internet), so there is another distinct possibility: the E-Mail's source is being spoofed. A common reason for such E-Mail spoofing is when a sender wishes to be anonymous and is trying to send spam (undesirable E-Mail that is an unsolicited advertisement, an attack E-Mail containing malware, and/or part of a phishing scheme).
Support for SPF may be fairly minimal, but it shouldn't lead to a lot of false positives when it is correctly used or when it simply isn't used.
SPF [#emspfdns]: [(was #dnsrrspf)]: Sender Policy Framework (“SPF”): Referring to policies on what machines are allowed to send E-Mail, details are on the Anti-spam section: usage of SPF DNS records. (Details of creating them are not yet available here ??? )
- [#dnsrropt]: OPT
- Used with EDNS. These records may be transmitted and used by supporting software even though they may not be listed alongside other records in the files that the DNS server uses to load zone data. RFC 2671 section 4.1 specifies this.
- [#dnsrrsig]: RRSIG
- Resource Record Signature (one of four new record types added by DNSSEC, according to DNSSec.Net: DNSSEC - The DNS Security Extensions)
- [#dnsrdkey]: DNSKEY
- DNS Public Key (one of four new record types added by DNSSEC, according to DNSSec.Net: DNSSEC - The DNS Security Extensions)
- [#dnsrrds]: DS
- Delegation Signer (one of four new record types added by DNSSEC, according to DNSSec.Net: DNSSEC - The DNS Security Extensions)
- [#dnsrnsc3]: NSEC3
- RFC 5155, Wikipedia's page on DNSSEC, Wikipedia's DNSSEC page (section on zone enumeration/walking, NSEC3) says this NSEC3 or RFC5155 “was released in March 2008” although the RFC is dated February 2008.
- [#dnsrnsec]: NSEC
- Next Secure (one of four new record types added by DNSSEC, according to DNSSec.Net: DNSSEC - The DNS Security Extensions)
- [#dnsrrtxt]: “TXT” Record
RFC 1035: “Domain names”, section 3.3.14: “TXT RDATA” says “TXT RRs are used to hold descriptive text. The semantics of the text depends on the domain where it is found.” In other words, whatever DNS server uses TXT records may end up using them for whatever purpose is desired. Wikipedia's page about DNS record types: text about the TXT records says “Originally for arbitrary human-readable text in a DNS record. Since the early 1990s, however, this record more often carries machine-readable data”. An example was a method of basically implementing Sender Policy Framework before SPF records were standardized. (Now, usage of an SPF record instead would be more clear what the data is meant for, and be less likely to conflict with other possible uses of TXT.)
Wikipedia's info on TXT records lists some other examples of how machines have used this type of field to share data that is, somehow, processed automatically.
RFC 1123 page 80 says that, due to a lack of widespread usage, “an application cannot rely on the the existence of a TXT or WKS RR in most domains.”.
- [#dnsrrsrv]: “SRV” Record
This is meant to help identify the IP address of a machine that provides a specific type of service. SMTP has a special resource record type, MX records. However, usage of this record type may be able to describe other services without having lots of differnet DNS record types. Wikipedia's “SRV record” article: section on “usage” lists some software and standardized protocols that use these.
- [#dnswks]: WKS
- These should not be used: RFC 1912: “Common DNS Operational and Configuration Errors” section 2.6.1 is clear about using WKS records in ways that external machines may see them: Don't. Usage is discussed by RFC 1123 page 14, and section 5.2.12 (on RFC 1123 page 55), and page RFC 1123 page 80, plus a couple of references in charts. Although RFC 974 (page 5) stated the use of checking WKS records was “optional, but strongly encouraged” at the time, the step has become officially discouraged.
Some Older/misc notes:
- Forwarding on requests
- When clients request DNS info from a server, if the server doesn't have the DNS info cached, the server will need to contact a trusted DNS server that either does have that information or can look it up. Typically it is considred best for the DNS server to look up the info and pass the results to the client, because the info can then be cached for possible future used by the same or different client.