The Domain Name System (DNS)
DNS is a hierarchical naming system that serves as a directory of networked hosts and resources. Information in the directory maps network names to data and is maintained in logical entries known as resource records. The DNS hierarchy begins with the root domain at the top and branches downward to multiple next-level domains.
Each level of the DNS hierarchy is delineated by the "•" in domain names, with "•" as the top level. Domains such as com, net, and org occupy the second level of the hierarchy and domains such as example.com and redhat.com occupy the third level and so on.
When working with DNS, it is important to clarify some of the common terms used to refer to the structure of the DNS hierarchy, such as domain, subdomain, and zone.
Domain
A domain is a collection of resource records that ends in a common name and represents an entire subtree of the DNS name space, such as example.com. The largest possible domain is the root domain, "•", which includes the whole DNS namespace.
A top-level domain (TLD) is a domain that has only one component. Generic TLDs (gTLDs) were originally organized by theme, and include .com, .edu, .net, etc. Country code TLDs (ccTLDs) are organized on a national basis, and include .us, .uk, .en, .ru, etc.
Subdomain
A subdomain is a domain that is a subtree of a not her domain. This term is used when discussing the relationship of two domains to each other. For example, lab.example.com is a subdomain of example.com.
Zone
A zone is the portion of a domain for which a particular nameserver is directly responsible, or authoritative. This may be an entire domain, or just part of a domain with some or all of its subdomains delegated to other nameserver(s).
DNS resource records
DNS resource records (RRs) are entries in a DNS zone that specify information about a particular name or object in the zone.
Hosts and resource records
An A resource record maps a host name to an IPv4 address.
[student@serverx - ]$ host -v -t A example.com
An AAAA resource record ("quad-A" record) maps a host name to an IPv6 address.
[student@serverx -]$ host -v -t AAAA a.root-servers.net
A CNAME(canonical name) resource record aliases one name to another name (the canonical name), which should have A or AAAA records.
www-dev.example.com. IN CNAME lab.example.com.
[student@serverx -]$ host -v -t A ipa-ca.server0.example.com
A PTR(pointer) record maps IPv4 or IPv6 addresses to a host name. They are used for reverse DNS resolution.
[student@serverX-]$ host -v -t PTR 172.25.0.10
An NS(Name Server) record maps a domain name to a DNS name server which is authoritative for its DNS zone.
[student@serverx -]$ host -v -t NS example.com
An SOA(start of authority) record provides information about how a DNS zone works.
[student@serverX -]$ host -v -t SOA example.com
An MX (mail exchange) record maps a domain name to a mail exchange which will accept email for that name.
[student@serverX -]$ host -v -t MX example.com
A TXT(text) record is used to map a name to arbitrary human-readable text.
[student@serverx -]$ host -v -t TXT lwn.net
An SRV (service) record is used to locate the hosts which support a particular service for a domain.
[student@serverx -]$ host -v -t SRV _ldap. _tcp.servere.example.com
DNS on Linux
Configuring and administering unbound as a caching nameserver
Configuring unbound
1. install the unbound package.
[root@serverx-]# yum install -y unbound
2. Start and enable unbound.service.
[root@serverX -]# systemctl start unbound.service
[root@serverx -]# systemctl enable unbound.service
3. Configure the network interface to listen on.
By default, unbound only listens on the localhost network interface. To make unbound available to remote clients as a caching nameserver, use the interface option in the server clause of /etc/unbound/unbound.conf to specify the network interface(s) to listen on. A value of 0.0.0.0 will configure unbound to listen on all network interfaces:
interface : 0.0.0.0
4. Configure client access.
By default, unbound refuses recursive queries from all clients. In the server clause of /etc/unbound/unbound.conf, use the access-control option to specify which clients are allowed to make recursive queries.
access-control: 172.25.0.0/24 allow
5. Configure forwarding.
In /etc/unbound/unbound.conf, create a forward-zone clause to specify which DNS server(s) to forward queries to. DNS servers can be specified by host name using the forward-host option, or by IP address using the forward-addr option. For a caching nameserver, forward all queries by specifying a forward-zone of ".".
forward-zone :
name: "."
forward-addr: 172.25.254.254
6. If desired, bypass DNSSEC validation for select unsigned zones.
By default, unbound is enabled to perform DNSSEC validation to verify all DNS responses received. The domain-insecure option in the server clause of /etc/unbound/unbound.conf can be used to specify a domain for which DNSSEC validation should be skipped. This is often desirable when dealing with an unsigned internal domain that would otherwise fail trust chain validation.
domain-insecure: example.com
7. If desired, install trust anchors for select signed zones without complete chain of trust.
Since not all ccTLDs have completed implementation of DNSSEC, the subdomains of these ccTLDs can be DNSSEC-sig ned but still have a broken chain of trust. This problem can be overcome by using the trust-anchor option in the server clause of /etc/unbound/unbound.conf to specify a trust anchor for the zone. Obtain the DNSKEY record for the key signing key (KSK) of the zone using dig and input it as the value for the trust-anchor option.
[student@serverX-]$ dig +dnssec DNSKEY example.com
8. Save changes to /etc/unbound/unbound.conf.
9. Check the /etc/unbound/unbound.conf configuration file for syntax errors.
[root@serverX -]# unbound-checkconf
10. Restart unbound.service.
[root@serverx -]# systemctl restart unbound.service
11. Configure the firewall to allow DNS traffic.
[root@serverX -]# firewall-cmd --permanent --add-service=dns
[root@serverx -]# firewall-cmd --reload
Dumping and loading unbound cache
Administrators of caching nameservers need to dump out cache data when troubleshooting DNS issues, such as those resulting from stale resource records. With an unbound DNS server, the cache can be dumped by running the unbound-control utility in conjunction with the dump_cache subcommand.
[root@serverx -]# unbound-control dump_cache
Executing unbound-control with the dump_cache command dumps out the cache to stdout in a text format. This output can be directed to a file for storage and be loaded back into cache later with unbound-control load_cache, if desired. unbound-control load_cache reads from stdin to populate the cache.
[root@serverx -]# unbound-control load_cache < dump.out
Flushing unbound cache
Administrators of caching nameservers also need to purge outdated resource records from cache from time to time. Erroneous and outdated resource records in cache will keep their newly corrected counterparts from becoming available to clients until the TTLs on the outdated resource records expire. Rather than waiting for TTL expiration, administrators can forcibly purge the outdated records from cache by executing unbound-control with the flush subcommand.
[root@serverX -]# unbound-control flush www.example.com
If all resource records belonging to a domain need to be purged from the cache of an unbound DNS server, unbound-control can be executed with the flush_zone subcommand.
[root@serverX -]# unbound-control flush_zone example.com
Updating Local Caching unbound Configuration with dnssec-trigger
In addition to providing caching name service for a local subnet, unbound can also be useful as a local caching nameserver to provide secure DNS name resolution for local use on an individual system. For a local caching nameserver setup, the nameserver entry in /etc/resolv.conf will be configured to point to localhost where unbound is listening. The unbound configuration will forward DNS requests to upstream nameservers and validate their responses.
For DHCP systems running local caching name service, the upstream nameservers specified in unbound's configuration may become outdated if DNS servers provided by DHCP change. The dnssec-trigger tool supplied by the package of the same name can be leveraged to automatically update forwarder settings in unbound's configuration file to point to the new DNS servers. The use of the dnssec-trigger tool in conjunction with unbound is mostly useful for secure DNS name resolution on roaming client machines.
Troubleshooting DNS
1. Name resolution methods
Name resolution is attempted first with the hosts file /etc/hosts by default, per order specified in /etc/nsswitch.conf. Therefore, when beginning name resolution troubleshooting, do not leap to the assumption that the issue resides with DNS. Begin first by identifying the name resolution mechanism which is in play, rather than simply starting with DNS. The getent command from the glibc-common package, as well as the gethostip command from the syslinux package, can both be used to perform name resolution, mirroring the process used by most applications in following the order of host name resolution as dictated by /etc/nsswitch.conf.
[student@desktopX -)$ getent hosts example.com
[student@desktopX -)$ gethostip example.com
If the result of getent or gethostip differs from that produced by dig, then it's a clear indication that something besides DNS is responsible for the unexpected name resolution result. Consult /etc/nsswitch.conf to determine what other name resolution mechanisms are employed before DNS.
2. Client-server network connectivity
When using dig to troubleshoot a DNS issue, if a response is not received from a DNS server, it is a clear indication that the cause lies with the client-server network connectivity to the DNS server.
[student@desktopX-]$ dig A example.com
A possible cause is the inability to reach the DNS server due to incorrect DNS server IP address(es) in a system's DNS configuration. This could be in /etc/ resolv.conf in the case of a system acting as a DNS client or in the forward-zone clause of /etc/unbound/unbound.conf in the case of a system configured as an unbound caching nameserver.
Another possible cause are firewall rules, on either the client or server system, blocking DNS traffic on port 53. While DNS mostly uses the UDP protocol, it is important to note that when response data sizes exceed 512 bytes, or 4096 bytes in the case of DNS servers that support Extension Mechanism for DNS (EDNS), resolvers will fall back to using TCP to retry the query. Therefore, proper DNS configuration should allow for DNS traffic on port 53 for both UDP and TCP. Allowing port 53 traffic for UDP only will result in a truncation error when the resolver encounters a response that is larger than what it can handle over UDP.
[student@desktopX -)$ dig @serverX.example.com A labhost1.example.com
[student@desktopX -)$ dig +tcp A example.com
Using tcpdump, the administrator can determine information that cannot be ascertained with dig a lone, such as the destination IP address of the DNS request, if request packets leave the client, if request packets reach the server, if response packets leave the server, if response packets reach the client, etc.
3. DNS response codes
The status field in the HEADER section of dig's output re ports the response code generated by the DNS server in response to the client's query.
DNS Return Codes
SERVFAIL :The nameserver encountered a problem while processing the query.
NXDOMAIN : The queried name does not exist in the zone.
REFUSED : The nameserver refused the client's DNS request due to policy restrictions.
4. Outdated cached data
The most common cause for an incorrect answer is that the answer originated from cached data, which is no longer current.
In these situations, first confirm that the response is indeed nonauthoritative cached data. This can be easily determined by looking at the flags section of dig' s output. DNS responses, which are authoritative answers, will be indicated by the presence of the aa flag.
DNS responses that originate from cached data are not authoritative and therefore will not have the aa flag set.
5. Responses for nonexistent records
If a record has been removed from a zone and a response is still received when querying for the record, first confirm that the queries are not being answered from cached data. If the answer is authoritative as confirmed by the presence of the aa flag in dig's output. then a possible cause is the presence of a wildcard (*) record in the zone.
6. Non-FQDN name errors
In a zone file, host names which are not expressed as Fully Qualified Domain Names (FQDNs) are automatically expanded to FQDNs by appending the name of the zone. To indicate that a name is an FQDN in a zone file, it must be ended with a ".", i.e., "www.example.com.". Failure to do so can lead to different issues depending on the type of record that the mistake is made in. For example, such a mistake made in the type-specific data portion of NS records have the potential of incapacitating an entire zone, while a mistake made in MX records could cause a complete halt of email delivery for a domain.
7. Looping CNAME records
While technically feasible, CNAME records that point to CNAME records should be avoided to reduce DNS lookup inefficiency. Another reason this is undesirable is the possibility of creating unresolvable CNAME loops.
8. Missing PTR records
Many network services use DNS to perform reverse lookups of incoming connections from clients. The absence of PTR records in DNS may result in issues, the nature of which varies depending on the service. SSHD, by default, will perform reverse lookups of connecting client IPs. Absence of PTR records will lead to delays in the establishment of these connections.
9. Round-robin DNS
A name can have multiple A or AAAA records in DNS. This is known as round-robin DNS, and is often used as a simple, low-cost, load-balancing mechanism to distribute network resource loads across multiple hosts.
While round-robin DNS is a valid technical configuration, there are times when this configuration is inadvertently created. When a request to change the IP address of an A record is mistakenly implemented as a resource record addition rather than a resource record modification, then round-robin DNS is created. If the network resources on the old IP address is retired, the load distribution effect of the round-robin DNS will result in service failures for approximately half of the clients.
*****
Posts
0 Comments