DNS
DNS (Domain Name Server)
How I have my websites' DNS records set up
Before proceeding with the Let's Encrypt steps to configure SSL cert, I configured my DNS records with the following (on namecheap):
- A record - @ - 23.20.238.64
- A record - www - 23.20.238.64
DNS
https://en.wikipedia.org/wiki/Domain_Name_System Good video to watch if you need a refresher: https://www.youtube.com/watch?v=mpQZVYPuDGU maps IP addresses to domain names. the phone book for the Internet by translating human-friendly computer hostnames into IP addresses A domain name consists of one or more parts, technically called labels, that are conventionally concatenated, and delimited by dots, such as example.com. Top level domain, belongs to the right-most label in the domain name. ‘.com’ The hierarchy of domains descends from right to left; each label to the left specifies a subdivision/subdomain of the domain to the right. I.e. the label example in ‘example.com’ specifies a subdomain of the ‘com’ domain. And www is a subdomain of ‘example.com’. Nameserver: The domain name system is maintained by a distributed database system, which uses the client-server model. The nodes of this database are the Nameservers. Each domain has at least one AUTHORITATIVE DNS server that publishes information about that domain and the name servers of any domains subordinate to it. The top of the hierarchy is served by the ROOT NAME SERVERS, the servers to query when looking up (resolving) a TLD.
Authoritative Nameserver: An authoritative nameserver is a nameserver (DNS server) that holds the actual DNS records (A, CNAME, PTR, etc) for a particular domain/address. Recursive resolver would be a DNS server that queries an authoritative nameserver to resolve a domain/address.
How does DNS work? When you query a domain name, the first step is your system will first check /etc/hosts. If nothing is there, then your browser will ask your local resolving name server (your ISP) if they have the DNS records for that domain cached. In this case you would skip everything else (below). IN LINUX, THE FIRST THING IT ACTUALLY DOES IS LOOK AT THE /ETC/HOSTS FILE. This file is used as a first point of lookup for DNS hostname resolution. Popular websites are most likely cached in your ISP’s/resolving name servers records. These records only last for a certain amount of time (TTL; 30 secs to a week) DNS uses Root Nameservers to store the locations of the TLD (Top Level Domains). TLD’s are the two or three character like ‘.com’, ‘.edu’, that end a domain name. Each TLD has their own set of nameservers that store the info that says who is authoritative for storing the DNS records for that domain. Authoritative nameserver is typically the DNS provider or the DNS registar (GoDaddy). Here is where we can find the DNS record that maps example.com to the IP address 127.xx.x.x.
In summary:
Browser ->/etc/hosts -> recursive/resolving name server (isp) cache; if not -> Root nameservers -> TLD (.com) -> Authoritative nameserver (DNS registrar like godaddy), get the IP address for that domain.
Mentor’s explanation How DNS works; what happens when you type Amazon.com into your browser First looks in /etc/hosts (which is defined in /etc/nsswitch.conf) man nsswitch.conf Maps hostnames to IP addresses Unlike remote DNS resolvers, the hosts file is under the direct control of the local computer’s admin. Systems implement name service switches (nsswitch.conf) to provide customization. After that: recursive resolver/resolving name server => root server (root server knows information about TLD (.com)) Recursive resolver asks root name server for DNS information about TLD (.com) Each TLD DNS name server (.com) stores information for second level domains (amazon.com) When query reaches the TLD authoritative server, the TLD authoritative server answers with IP address of domain’s name server Recursive resolver sends the query to the domain’s name server
In short: What if the record we are looking for isn’t cached? Then the (recursive) resolving name server will ask the root name servers for the TLD for that domain, which will point you to the provider authoritative for hosting the records.
This process happens in just a couple millisecs.!
Reverse DNS lookup is a query of the DNS for domain names when the ip address is known. What DNS server am I using? How can you find that info? (KNOW THIS!) Cat /etc/resolv.conf ( The file resolv.conf typically contains directives that specify the default search domains; used for completing a given query name to a fully qualified domain name when no domain suffix is supplied. It also contains a list of IP addresses of nameservers available for resolution. esolv.conf is usually located in the /etc directory of the file system. The file is either maintained manually, or when DHCP is used, it is usually updated with the utility resolvconf.) Nslookup google.com (this will give you googles IP along with your nameserver / DNS server) Nmcli dev show | grep DNS dig yourserver.somedomain.xyz DNS Record Types https://my.bluehost.com/hosting/help/508#mxentry https://simpledns.com/help/dns-record-types A Record (Address Record) Points a domain or subdomain to an IP address. (i.e. points “google.com” to the IP address of Google’s hosting server) Allows for human-readable domain, while the system can continue to work with numbers.
CNAME (Canonical Name) Points one domain or subdomain to another domain name, allowing you to update one A Record each time you make a change, regardless of how many Host Records need to resolve to that IP address. Can be used to alias one name to another. I.e. example.com and www.example.com pointing to the same application and hosted by the same server. A CNAME record must always point to another domain name, and never directly to an IP address.
MX Entry MX (mail exchanger) entry or record directs email to a particular mail server. Like a CNAME, MX entries must point to a domain and never point directly to an IP address.
TXT Records The TXT value is what the record ‘points to’. But these records aren’t used to direct any traffic. Instead they’re used to provide needed information to outside sources.
SRV Records An SRV (service) record points one domain to another domain name using a specific destination port. SRV records allows specific services, such as VOIP or IM, to be directed to a separate location.
AAAA Record Similar to the A record, but it allows you to point the domain to an IPv6 address. PTR Records PTR records (domain name pointer) are primarily used as “reverse records” to map IP addresses to domain names (reverse of A/AAAA records).
Zone File Where all the DNS records are stored for a domain. Host Record This is the domain/subdomain you wish to use . The @ symbol is used to indicate the root domain itself. In our example the Host Record ‘ftp’ would be for the subdomain ftp.google.com and ‘@’ would be google.com (???) Points to This is the destination server that the domain / subdomain is sending the traffic to. TTL Time to live, value indicates the amount of time the record is cached by a DNS server, such as your ISP. The default (lowest accepted) value is 14400 seconds (4 hrs). You do not normally need to modify this value. The TTL serves to tell the recursive server or local resolver how long it should keep said record in its cache. The longer the TTL, the longer the resolver holds that information in its cache. The shorter the TTL, the shorter amount of time the resolver holds that information in its cache. Anyone else who uses that same resolver will get the same answer, and on the authoritative side, there will be no query to the server unless the TTL runs out. Short TTLs are useful for domains that frequently change their records. One of the most common use cases is where domains rely on DNS-based load balancing and failover services. Longer TTLs are mostly appropriate for sites hosted on a single server that don’t frequently change their IP configurations. Longer cache times equate to fewer lookups, lower costs and better performance. A delayed response to any DNS change is one downside, however.
Action Allows you to modify or remove existing records. Weight This is similar to priority, as it controls the order in which multiple records are used. Records are grouped with other records that have the same Priority value. Port This is used by the server or computer to process traffic to specific services, ensuring that all traffic comes through the door that it’s expected on. Target This is the destination that the record is sending the traffic to. SOA (Start of Authority) Every domain/dns zone must have a SOA record at the cutover point where the domain is delegated from its parent domain.
start of authority (SOA) record is information stored in a domain name system (DNS) zoneabout that zone and about other DNS records. A DNS zone is the part of a domain for which an individual DNS server is responsible. Each zone contains a single SOA record. SOA records are defined in IETF RFC 1035, Domain Names - Implementation and Specification
The SOA record includes the following details: The SOA record stores information about the name of the server that supplied the data for the zone; the administrator of the zone; the current version of the data file; the number of seconds a secondary name server should wait before checking for updates; the number of seconds a secondary name server should wait before retrying a failed zone transfer; the maximum number of seconds that a secondary name server can use data before it must either be refreshed or expire; and a default number of seconds for the time-to-live file on resource records. DNS USES UDP AND TCP. DNS switches to TCP if the data its sending/receiving is > 512 Bytes ZONE TRANSFERS
to replicate DNS databases across a set of DNS servers.
DNS and some other services work on both the protocols. We will take an example of DNS Service. Two protocols are somewhat different from each other. TCP is a connection-oriented protocol and it requires data to be consistent at the destination and UDP is connection-less protocol and doesn't require data to be consistent or don't need a connection to be established with host for consistency of data.
UDP packets are smaller in size. UDP packets can not be greater then 512 bytes. So any application needs data to be transferred greater than 512 bytes require TCP in place. For example, DNS uses both TCP and UDP for valid reasons described below. Note that UDP messages are not larger than 512 Bytes and are truncated when greater than this size. DNS uses TCP for Zone transfer and UDP for name queries either regular (primary) or reverse. UDP can be used to exchange small information whereas TCP must be used to exchange information larger than 512 bytes. If a client doesn't get response from DNS it must re-transmit the data using TCP after 3-5 seconds of interval.
There should be consistency in DNS Zone database. To make this, DNS always transfer Zone data using TCP because TCP is reliable and make sure zone data is consistent by transferring the full zone to other DNS servers who has requested the data
DIG + DNS= https://www.youtube.com/watch?v=hYZY75xMjlY
The command dig is a tool for querying DNS nameservers for information about host addresses, mail exchanges, nameservers, and related information. This tool can be used from any Linux (Unix) or Macintosh OS X operating system. The most typical use of dig is to simply query a single host.
Resolv.conf (Ubuntu 18.04+)
When you check /etc/resolv.conf in Ubuntu 18.04, you will see the IP 127.0.0.53, not the amazon provided DNS IP (x.x.x.2):
$ cat /etc/resolv.conf ... nameserver 127.0.0.53 options edns0 search ca-central-1.compute.internal $ ls -al /etc/resolv.conf lrwxrwxrwx 1 root root 39 Jun 11 2020 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf
It seems to be a bug in the Ubuntu version 18.04 where 'systemd-resolved' appends 127.0.0.53 to resolv.conf alongside existing entries.
- Really good article that explains why we see 127.0.0.53 in Ubuntu: https://unix.stackexchange.com/questions/612416/why-does-etc-resolv-conf-point-at-127-0-0-53
Or it may not be a bug: http://manpages.ubuntu.com/manpages/bionic/man8/systemd-resolved.service.8.html#/etc/resolv.conf
But really it is in /run/systemd/resolve/resolv.conf:
$ cat /run/systemd/resolve/resolv.conf ... nameserver 172.31.0.2 search ca-central-1.compute.internal
You can confirm the DNS nameservers that are being in use by running:
$ systemd-resolve --status
Global
DNSSEC NTA: 10.in-addr.arpa
16.172.in-addr.arpa
168.192.in-addr.arpa
17.172.in-addr.arpa
18.172.in-addr.arpa
19.172.in-addr.arpa
20.172.in-addr.arpa
21.172.in-addr.arpa
22.172.in-addr.arpa
23.172.in-addr.arpa
24.172.in-addr.arpa
25.172.in-addr.arpa
26.172.in-addr.arpa
27.172.in-addr.arpa
28.172.in-addr.arpa
29.172.in-addr.arpa
30.172.in-addr.arpa
31.172.in-addr.arpa
corp
d.f.ip6.arpa
home
internal
intranet
lan
local
private
test
Link 2 (eth0)
Current Scopes: DNS
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
DNS Servers: 172.31.0.2 <---------------
DNS Domain: ec2.internal
- If you want to know how to set a static/custom DNS IP: https://aws.amazon.com/premiumsupport/knowledge-center/ec2-static-dns-ubuntu-debian/#Ubuntu_18.04
What is a DNS PTR Record
Really good article: https://www.cloudflare.com/learning/dns/dns-records/dns-ptr-record/
What is a DNS PTR record?
The Domain Name System, or DNS, correlates domain names with IP addresses. A DNS pointer record (PTR for short) provides the domain name associated with an IP address. A DNS PTR record is exactly the opposite of the 'A' record, which provides the IP address associated with a domain name.
DNS PTR records are used in reverse DNS lookups. When a user attempts to reach a domain name in their browser, a DNS lookup occurs, matching the domain name to the IP address. A reverse DNS lookup is the opposite of this process: it is a query that starts with the IP address and looks up the domain name.
What are some of the main uses for PTR records?
PTR records are used in reverse DNS lookups; common uses for reverse DNS include:
Anti-spam: Some email anti-spam filters use reverse DNS to check the domain names of email addresses and see if the associated IP addresses are likely to be used by legitimate email servers.
Troubleshooting email delivery issues: Because anti-spam filters perform these checks, email delivery problems can result from a misconfigured or missing PTR record. If a domain has no PTR record, or if the PTR record contains the wrong domain, email services may block all emails from that domain.
Logging: System logs typically record only IP addresses; a reverse DNS lookup can convert these into domain names for logs that are more human-readable.
How to set up a DNS Server on EC2 (BIND)
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/managin[…]iguring-a-bind-dns-server_networking-infrastructure-services