Table of Contents
- Introduction
- Domain Names
- Subdomains
- Certificates
- Records
- APEX Redirects
- DNS over HTTPS
- Operational Checklist
- Helpful Code
- References
Domain Names, DNS, URLs (and Query Strings) represent a surface are of hidden risk because while these topics appear trivial, mishaps during certain activities can have disasterous consequences. Beyond providing a brief intro to these topics, this document is designed to enable a stronger posture against typical considerations for: DevOps; Product Owners; SEO; etc., during activities such as: site launches; migrations; and diagnostics.
Domain names such as 'google.com' or 'nike.com' are well known, with their function being fairly obvious -- but for technical and technical-adjacent disciplines, understanding the structure and just a bit about how they work is an absolute requirement.
Breaking down the example of 'google.com.' going from RIGHT to LEFT --the order of operations for DNS resolution-- we start with the trailing period (.). Note specifically that although you don't include a trailing period in the browser address bar, DNS records always end with a dot, and DNS handles the absense of the trailing period gracefully.
🗒️ Each segment of a domain is separated by a period (dot (.)).
This is a trailing period, and although this is HIDDEN in user interactions with web clients (browsers, curl, etc.), it is present, and can be assessed with the following dig command:
💡 You can optionally include a trailing period when typing a url, like: 'google.com.', and it will resolve.
$ dig +trace +answer .
; <<>> DiG 9.18.8 <<>> +trace +answer com.
;; global options: +cmd
. 6876 IN NS i.root-servers.net.
. 6876 IN NS e.root-servers.net.
...
;; Received 519 bytes from 127.0.0.53#53(127.0.0.53) in 0 ms
com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
...
com. 86400 IN DS 30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766
com. 86400 IN RRSIG DS 8 1 86400 20230311170000 20230226160000 951 . nunIoQWBjTgraJKjwOf5upBDnSOflTh7ytJexlVrAT3F20QFj7vlT05Z HJnvhPUVmKNYMxKA87mqYzRUH+F9QAY95WZYSOeH0dZXAPha1WSk7RfS lC0RHtJ1+pSS0JtUD7NUfYy55bjk2WSQID/7S2H+nGg2sxrpZHDyKMa4 rlhSaOnZyeNHJkf/CP6DY3C8Xwx1oFaHWx1bRV1LenP/Gy6kI2ywHyrF uLaJOGEjD9OT4itYbdarEaa/961ySoCkZFwJtYFbN8KVBDQmcTAiXzRN /nnfb3BAx4GfGNwgSQ1pplmQSnAFT1cF/nS5sAtYgqfgp3JaKC8Iwfi2 E46D9g==
;; Received 1163 bytes from 198.97.190.53#53(h.root-servers.net) in 83 ms
com. 900 IN SOA a.gtld-servers.net. nstld.verisign-grs.com. 1677478378 1800 900 604800 86400
com. 900 IN RRSIG SOA 8 1 900 20230306061258 20230227050258 36739 com. BBxr/BBBMlUdAhZO5BcLVfiH0Jb7OrUEZBWoMbNhHKBwq3g+tVkRPLo7 LW/A/HAmkf/Sado08lVzwP/I1Y9tkxcLSjc0KqyZANRdmkdhEwfXsH4S oPIe2ZicCYX9dfa0sD2hDwfaqXoLb7nmet7qllYGdO73/4z5RLLhPEkl pCKagrvNGWtiMRFy2AVfVW1mlFgI494SXWnkJuQjrDjTGQ==
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - CK0Q2D6NI4I7EQH8NA30NS61O48UL8G5 NS SOA RRSIG DNSKEY NSEC3PARAM
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 8 2 86400 20230303052249 20230224041249 36739 com. rXXhjgHhBHyFnZNsXtNvn2jSCLCInjirm5afZvn+wcu2dIQ/wGP9TAbt ZXDgA78A21Bgbtfm04wVemAUSg3dOBWZaPGJqftBUffy9mr8eSFeOfe4 cx35PzknJp6BVqUwYGQtogdUu9A7iFldK6AJhFWpeIL194qhtJY6kQMd HRmL3S8kgI5KbxzpzB90bWpetBPxs493GpP/R4pBvH2nsA==
;; Received 575 bytes from 192.31.80.30#53(d.gtld-servers.net) in 30 ms
See the IANA Root Servers and Root Server Technical Operations Association references below for more.
TLDs are are subdomains of the root domain, and can be fully assessed with the following dig command:
dig +trace +answer com.
; <<>> DiG 9.18.8 <<>> +trace +answer com.
;; global options: +cmd
. 6876 IN NS i.root-servers.net.
. 6876 IN NS e.root-servers.net.
...
;; Received 519 bytes from 127.0.0.53#53(127.0.0.53) in 0 ms
com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
...
com. 86400 IN DS 30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766
com. 86400 IN RRSIG DS 8 1 86400 20230311170000 20230226160000 951 . nunIoQWBjTgraJKjwOf5upBDnSOflTh7ytJexlVrAT3F20QFj7vlT05Z HJnvhPUVmKNYMxKA87mqYzRUH+F9QAY95WZYSOeH0dZXAPha1WSk7RfS lC0RHtJ1+pSS0JtUD7NUfYy55bjk2WSQID/7S2H+nGg2sxrpZHDyKMa4 rlhSaOnZyeNHJkf/CP6DY3C8Xwx1oFaHWx1bRV1LenP/Gy6kI2ywHyrF uLaJOGEjD9OT4itYbdarEaa/961ySoCkZFwJtYFbN8KVBDQmcTAiXzRN /nnfb3BAx4GfGNwgSQ1pplmQSnAFT1cF/nS5sAtYgqfgp3JaKC8Iwfi2 E46D9g==
;; Received 1163 bytes from 198.97.190.53#53(h.root-servers.net) in 83 ms
com. 900 IN SOA a.gtld-servers.net. nstld.verisign-grs.com. 1677478378 1800 900 604800 86400
com. 900 IN RRSIG SOA 8 1 900 20230306061258 20230227050258 36739 com. BBxr/BBBMlUdAhZO5BcLVfiH0Jb7OrUEZBWoMbNhHKBwq3g+tVkRPLo7 LW/A/HAmkf/Sado08lVzwP/I1Y9tkxcLSjc0KqyZANRdmkdhEwfXsH4S oPIe2ZicCYX9dfa0sD2hDwfaqXoLb7nmet7qllYGdO73/4z5RLLhPEkl pCKagrvNGWtiMRFy2AVfVW1mlFgI494SXWnkJuQjrDjTGQ==
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - CK0Q2D6NI4I7EQH8NA30NS61O48UL8G5 NS SOA RRSIG DNSKEY NSEC3PARAM
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 8 2 86400 20230303052249 20230224041249 36739 com. rXXhjgHhBHyFnZNsXtNvn2jSCLCInjirm5afZvn+wcu2dIQ/wGP9TAbt ZXDgA78A21Bgbtfm04wVemAUSg3dOBWZaPGJqftBUffy9mr8eSFeOfe4 cx35PzknJp6BVqUwYGQtogdUu9A7iFldK6AJhFWpeIL194qhtJY6kQMd HRmL3S8kgI5KbxzpzB90bWpetBPxs493GpP/R4pBvH2nsA==
;; Received 575 bytes from 192.31.80.30#53(d.gtld-servers.net) in 30 ms
Above the answer section shows the gtld servers responsible for this gTLD.
🗒️ TLD terminology includes "gTLD" to denote generic TLDs, and "ccTLD" to denote country-code TLDs. See RFC-4185.
- Several countries require approval from the Government, or that you be a citizen or registered business within that country, before a domain with their ccTLD can be obtained. This process can be lengthy, and not guaranteed. Keep this in mind when approaching market strategy, and technical implementation planning. Note specifically that even if a ccTLD is available now, their policy may change in the future.
- Domain squatters are a global problem, and present a real and ever-present threat (RISK) against business strategies that involve positioning specific domains across multiple TLDs. When launching such a strategy it is advisable to secure all required domains early, rather than risk a squatter recognizing a pattern in your domain scheme as you roll-out such a project. For example, launching a client web-presence against multiple region-specific domains such as highprofilesite.co.uk, highprofilesite.fi, highprofilesite.at, --serially-- may lead to someone snatching up highprofilesite.ca, highprofilesite.cn, etc.
- SOA Service Quality can be exceedingly poor. Not every country has top shelf service providers for this infrastructure, leading to both basic service management deficiencies and security issues. Depending on your service level objectives, ccTLDs may need to be avoided.
Apex records are subdomains of the TLD, and are typically where an entity will position their primary identifier (nike, google, etc.).
They can be fully assessed with the following dig command:
dig +trace +answer google.com.
; <<>> DiG 9.18.8 <<>> +trace +answer google.com.
;; global options: +cmd
. 6773 IN NS a.root-servers.net.
. 6773 IN NS h.root-servers.net.
...
;; Received 519 bytes from 127.0.0.53#53(127.0.0.53) in 0 ms
com. 172800 IN NS k.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
...
com. 86400 IN DS 30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766
com. 86400 IN RRSIG DS 8 1 86400 20230311170000 20230226160000 951 . nunIoQWBjTgraJKjwOf5upBDnSOflTh7ytJexlVrAT3F20QFj7vlT05Z HJnvhPUVmKNYMxKA87mqYzRUH+F9QAY95WZYSOeH0dZXAPha1WSk7RfS lC0RHtJ1+pSS0JtUD7NUfYy55bjk2WSQID/7S2H+nGg2sxrpZHDyKMa4 rlhSaOnZyeNHJkf/CP6DY3C8Xwx1oFaHWx1bRV1LenP/Gy6kI2ywHyrF uLaJOGEjD9OT4itYbdarEaa/961ySoCkZFwJtYFbN8KVBDQmcTAiXzRN /nnfb3BAx4GfGNwgSQ1pplmQSnAFT1cF/nS5sAtYgqfgp3JaKC8Iwfi2 E46D9g==
;; Received 1198 bytes from 192.36.148.17#53(i.root-servers.net) in 164 ms
;; UDP setup with 2001:503:d2d::30#53(2001:503:d2d::30) for google.com. failed: network unreachable.
google.com. 172800 IN NS ns2.google.com.
google.com. 172800 IN NS ns1.google.com.
google.com. 172800 IN NS ns3.google.com.
google.com. 172800 IN NS ns4.google.com.
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - CK0Q2D6NI4I7EQH8NA30NS61O48UL8G5 NS SOA RRSIG DNSKEY NSEC3PARAM
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 8 2 86400 20230303052249 20230224041249 36739 com. rXXhjgHhBHyFnZNsXtNvn2jSCLCInjirm5afZvn+wcu2dIQ/wGP9TAbt ZXDgA78A21Bgbtfm04wVemAUSg3dOBWZaPGJqftBUffy9mr8eSFeOfe4 cx35PzknJp6BVqUwYGQtogdUu9A7iFldK6AJhFWpeIL194qhtJY6kQMd HRmL3S8kgI5KbxzpzB90bWpetBPxs493GpP/R4pBvH2nsA==
S84BKCIBC38P58340AKVNFN5KR9O59QC.com. 86400 IN NSEC3 1 1 0 - S84BUO64GQCVN69RJFUO6LVC7FSLUNJ5 NS DS RRSIG
S84BKCIBC38P58340AKVNFN5KR9O59QC.com. 86400 IN RRSIG NSEC3 8 2 86400 20230304060135 20230225045135 36739 com. cXaYy0la+1W3vD6vMRJqyuTMycvYhTRWUBA2ytY9LPwTzcN6wP1WUp9D 9ZtFK5A4aTavzz28nFy53WLCDsWYWr3ogIb5M0BGjZqFZ3oHIwmqgRwh gG+8P/etYTW1TTfDQQXo0mGGc50D1GLzhTMiBnKJsTir3xLcbq8Mx1y0 Cp/DlRQkV+RC4o8USaWA4E3Ib0gbG36KMa2DBIYswFgpxA==
;; Received 836 bytes from 192.43.172.30#53(i.gtld-servers.net) in 52 ms
;; UDP setup with 2001:4860:4802:32::a#53(2001:4860:4802:32::a) for google.com. failed: network unreachable.
;; UDP setup with 2001:4860:4802:36::a#53(2001:4860:4802:36::a) for google.com. failed: network unreachable.
google.com. 300 IN A 172.217.165.14
;; Received 55 bytes from 216.239.36.10#53(ns3.google.com) in 30 ms
Subdomains are left of the apex domain, and are dependent upon the AUTHORITY of the apex domain as provided by the registrar. This authority can be delegated as necessary to other zone name servers.
Different levels of subdomains can be hosted by different name servers. For example, the production website for Nike exists on nike.com.. They might have a development environment hosted at dev.nike.com.. Obviously this environment would not be maintained in the same operational context as production, necessitating a separate DNS Zone to have authority over records for this subdomain. This authority is granted, or delegated by creating an ‘NS’ record within the parent domain with a hostname of dev.nike.com, and the name servers for that zone as a value.
⚠️ Within Route53, if you include the trailing periods of the name servers in the NS record, delegation will fail.
The following diagram is a representation of a domain hierarchy, demonstrating the name server authority delegation chain.
🗒️ When delegating authority for multiple levels of a DNS hierarchy, the authority must chain from the lowest level to the highest. See RFC-1034, and RFC-1035 for more on name server authority.
This is useful when determining the TTL or record value for a domain which is to be updated. See the TTL section below for more.
dig +noall +answer google.com
google.com. 294 IN A 142.251.41.78
The output above details the Domain, TTL, Class, Type, Value. The Class will be always be IN (internet). See RFC-5395 3.2.2 for more.
The Start of Authority, in DNS, is responsible for authoring records, and making them available to the global DNS infrastructure. Being able to identify the SoA and then query it directly is helpful when monitoring a DNS change in real time. Note the 'soa' segment of the command. This is specifying the records type to query, and can be substituted for any valid record type (A, CNAME, TXT, etc.)
dig soa +noall +answer google.com
google.com. 14 IN SOA ns1.google.com. dns-admin.google.com. 512410346 900 900 1800 60
As mentioned directly above, this allows you to monitor the SoA for DNS record changes directly at the source, without having to wait for the TTL to expire.
dig +noall +answer google.com @ns1.google.com
google.com. 300 IN A 172.217.165.14
The Apex record for a domain CANNOT be a CNAME. This is because CNAMEs cannot co-exist with other records of the same name, such as NS, or MX records.
Though the Apex is a subdomain of the TLD, subdomains to the Apex label are generally what people are referring to when using the term ‘subdomain’.
Everyone is familiar with the www subdomain, and are used to typing just the apex and then being redirected to the www. For example, nike.com redirects to www.nike.com. But why is this?
Many websites host on the 'www' (world wide web) subdomain, and redirect from <apex>.<tld> to www.<apex>.<tld>. This was a strategy adopted as a result of the DNS limitation of CNAMEs not being able to be used at the Apex level (RE: Apex Special Considerations), which severely limit the ability to engineer systems that were Highly Available and readily recoverable. Recent advances in CDN technologies, and the adoption of Anycast IPs has greatly mitigated this limitation, and companies are re-posturing their web-presence against their respective apex domains.
An endless argument. Here’s a great resource outlining many of the considerations. One that should be pointed out specifically is the portability concern as not all vendors can facilitate hosting a property at the apex in a highly reliable fashion.
⚠️ DO NOT migrate a website between the www and apex without thoroughly investigating SEO considerations.
Implementation of the redirect is critical. For UX, as much as a 301 redirect will be cached with the client, first impressions are important and site load times includes redirects. For SEO, the question is does site performance matter? That rabbit hole is there for you, but more performance is more better, so why not optimize your redirect portfolio.
Here’s an example of some apex to www redirects from Nike, Alphabet, and Fastly. Note the difference in latencies.
$ dnsTraceRedirects nike.com
94 ms : nike.com [ CloudFront:HTTP/1.1(301) ] >> https://www.nike.com/
101 ms : https://www.nike.com/ [ AkamaiGHost:HTTP/1.1(302) ] >> https://www.nike.com/ca/
405 ms : https://www.nike.com/ca/ [ unified-edge-router:HTTP/1.1(200) ] (Terminated)
Total Time (initial asset): 610 ms
$ dnsTraceRedirects alphabet.com
354 ms : alphabet.com [ nginx:HTTP/1.1(301) ] >> https://www.alphabet.com/
715 ms : https://www.alphabet.com/ [ nginx/1.20.0:HTTP/1.1(301) ] >> https://www.alphabet.com/en
510 ms : https://www.alphabet.com/en [ nginx/1.20.0:HTTP/1.1(301) ] >> https://www.alphabet.com/en-ww
436 ms : https://www.alphabet.com/en-ww [ nginx:HTTP/1.1(200) ] (Terminated)
Total Time (initial asset): 2024 ms
$ dnsTraceRedirects fastly.com
28 ms : fastly.com [ Artisanal:HTTP/1.1(301) ] >> https://www.fastly.com/
42 ms : https://www.fastly.com/ [ Artisanal:HTTP/1.1(200) ] (Terminated)
Total Time (initial asset): 79 ms
🗒️ See this GIST for the dnsTraceRedirects function if you would like to get setup with it.
The domains which people are most familiar with, such as 'nike.com', are marketing domains.
🗒️ Often phrased as "public" domains, this terminology is a dysfunction as both marketing and service domains are public.
Service domains, while publicly routable, are not for consumption by the general public, but are leveraged to establish separation of concern for a variety of operational objectives.
Service Domain Considerations
- Service domains are owned & maintained by Operational disciplines.
- Service domains are very specifically NOT marketing domains. This is a critical distinction as marketing domains are driven by business, while service domains are the concern of operations and are architected to facilitate their disciplinary mandates with minimal operational overhead, such as:
- Registration Origin:
- A marketing domain may be purchased by an individual in marketing, requiring its ownership to be transferred to the organization.
- Marketing domains may be owned and operated by a third party, such as a customer, in which case you are bound to their service desk.
- ccTLDs - See ccTLD Special Considerations for just some of the issues here.
- Registration Origin:
- Service domains are a defensive posture against:
- Domain flyovers
- May leak endpoints that may be undesirable to be generally known to the public, such as service origins or non-prod envs.
- May leak other information, such as marketing strategies, or other priviliged/protected information.
- TLS SAN sprawl
- May leak endpoints...
- May dramatically increase TLS spend depending on the CDN/TLS vendor. 💸
- Operational Overhead against both DNS and TLS management.
- Domain flyovers
- Service domains enhance the potential of Zero Trust postures.
- Service domains enable a great amount of operational capability. For example, your service deployments may result in an entirely new origin endpoint being stood up, which can be leveraged in a variety of operational tactics.
- Service domains naming schemes:
- The apex segment/label should include 'svc', or 'service' to ensure that they are understood to be service domains.
- The host segement may be anything, but ideally will include a random string to ensure that the same service can be stood up multiple times. Potentially you may incorporate other meta data encoded as base64. Eg:
hostname=$(echo n:foo,v:1.23.456,d:342 | base64 | tr -d = ) if [[ $hostname -gt 63 ]]; then echo "too long: https://www.freesoft.org/CIE/RFC/1035/9.htm"; exit; fi echo $hostname bjpmb286MS4yMy40NTYsZDozNDIK dns_record="$hostname.coolsvc.com" echo dns_record bjpmb286MS4yMy40NTYsZDozNDIK.coolsvc.com echo $hostname | base64 --decode 2>/dev/null # Silence the error from base64 due to the missing = n:foo,v:1.23.456,d:342
Somewhat out of scope for this document is the topic of internal domains, which are namespaces that exist only within private networks. For example, while in the office or logged into a corporate VPN, you may be able to access 'intranet.company.com' -- a domain that is not publically accessible.
Most certificates will be Wildcard, unless you need special SAN entries, or another level of subdomains. For Production, it will be like *.apex.tld and apex.tld, and for non-production, like *.dev.apex.tld and dev.apex.tld.
A DNS Record is simply an object registered with a DNS server that maps the domain to a target or value.
The following table describes the most common record types encountered.
| Type | Description |
|---|---|
| A | The "A" in A record stands for "address." An A record shows the IP address for a specific hostname or domain. |
| AAAA | Like A, but for IPv6. |
| CNAME | The "canonical name"—is a DNS record that points a domain name (an alias) to another domain. |
| NS | A nameserver (NS) record specifies the authoritative DNS server for a domain. |
| SOA | The "start of authority" record stores admin information about a domain. This information includes the email address of the admin and when the domain was last updated. |
| TXT | The "text" record allows the owner of a domain store text values in the DNS. Vendored services often use this record to verify ownership of a domain. |
All DNS records have a TTL (Time To Live) associated with them, which determines how long a DNS server can cache the value. This is a critical consideration to always keep in mind as it affects the delay between a record change, and when it is visible to the world.
For example, a record with a TTL of 604800 (seconds) will take a week to propagate fully across the global DNS infrastructure. With this in mind, as the time approaches to issue a record change, it is imperative to verify/lower the TTL of the record ahead of time.
Due to the previously mentioned restriction of not being able to create a CNAME record for the domain APEX, it is common practice to redirect from the APEX to the www subdomain.
🗒️ The Fastly solution for this is to provide anycast IP addresses for apex domains.
Akamai and AWS both have solutions for this, but only if you're hosting the domains on their DNS services.
Note that new DNS functionality is starting to be rolled out in web clients that sends DNS over HTTPS (DoH) to a few central "trusted resolvers", instead of doing lookups against local DNS servers.
This has a number of implications for testing DNS updates, and you if you're testing a DNS update it'd be a good idea to disable it -- unless the central DoH servers are more reliable than your local DNS servers.
🗒️ Do see the wikipedia article for much more on this.
There are a few operational points that often sneak up on everyone from hobbiests to Fortune 500 enterprise operations groups. Ensure the following are monitored to avoid these expensive and embarrasssing situations.
- - Domain Expirty
- - DNS Record Values (Monitor for changes.)
- - TLS Certificate Expiry
- - TLS Certificate Cipher Suite, Protocol, etc.
💡 ProTip: StatusCake offers world-class monitoring for these concenrs at an unbeatable price. I don't work for them, I've just used many, many products over the years and prefer theirs.
Here are some aliases/functions you can add to your .bashrc/.profile file.
⚠️ May or may not work with MacOS as its coreutils are bsd based, out of date, and cannot be updated by Apple. GNU version can be installed like:brew install coreutils jq gawk gdate gsed, etc, and can aliased by addingalias date=’gdate’to ~/.profile file.
# Usage: <command> <domain>
# EG: digna nike.com
# EG: digttl nike.com
# Get just the answer
alias digna='dig +noall +answer $1'
# Get the Name Server for a domain
alias digns='dig NS +noall +answer $1'
# Get the Start of Authority for a domain
alias digsoa='dig SOA +noall +answer $1'
# Get just the hostname of the SOA
function digsoahost() {
digsoa | awk '{gsub(/.$/,"",$5); print $5}'
}
# Get the TTL for a domain from the SOA (recursors have an actively expiring TTL)
function digttl() {
dig +noall +answer $1 @$(digns $1 | awk 'NR==1 {print $5}') | awk 'NR==1 {print $2}'
}
# Check the SOA for a record for the specified domain
function nslookupsoa() {
nslookup $1 $(digsoahost $1)
}
# Get location of IP address (Register with ipstack.com for a free API key)
function geoip_lookup() {
curl -sS "<http://api.ipstack.com/$1?access_key=><your api key>&output=json&fields=country_code,city" | jq -r '"\\(.city), \\(.country_code)"'
}Example: Compare local recursive resolver DNS records with those of the SOA
$ digna nike.com
nike.com. 60 IN A 13.33.165.56
nike.com. 60 IN A 13.33.165.75
nike.com. 60 IN A 13.33.165.97
nike.com. 60 IN A 13.33.165.23
$ nslookupsoa nike.com
Server: ns-n1.nike.com
Address: 205.251.197.8#53
...The records from the SOA should match those of other DNS servers.
This script is immensely helpful for validating a DNS change from the terminal.
Domain Name System (DNS) Parameters
- RFC-1034 : DOMAIN NAMES - CONCEPTS AND FACILITIES
- RFC-1035 : DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION
- RFC 4185 : National and Local Characters for DNS Top Level Domain (TLD) Name
- RFC-5395 : Domain Name System (DNS) IANA Considerations
- IANA Root Servers