Another book in progress about DNS ... We have over 200 pages of an unreleased DNSSEC book to integrate, plus courseware used 20 to 10 years ago to rewrite into this book ...
DNS is one of the key building blocks of the Internet and is used by nearly every device and human on the Internet, internal network including ATMs, cameras, printers, car navigation system, and more. DNS is the Domain Name System. Its primary and common use is looking up Internet (IPv4) addresses using a name, such as a website domain name. But it is so much more than that.
DNS is a database system. The database looked at is massive. It contains over 365 million domain names and many times more sub-domain names. A standard domain name requires at least a couple record values, and commonly has around eight different values. Some domain names contain or reference thousands to even millions of sub-domain records within it. The Domain Name System represents billions of unique records which are managed by tens of millions of individuals and organizations. The changes are done using different tools and techniques - some changed infrequently (like less than once a year) and others many times per second. Some of the records are queried rarely while others are queried hundreds of thousands of times per second. Accordingly, no single database system scales like DNS.
DNS is a distributed database - the largest distributed database in the world. It allows owners or administrators to define their record values which are shared to others when queried. It also allows load balancing by distributing even identical queries to multiple systems.
This database, the DNS system, is structured in a tree format. It begins with a root DNS server where an initial lookup is done. A root server does not have (and cannot have) all the answers for the entire DNS. It simply knows about and tells you about the next servers to ask. These next servers, known as the Top Level Domain (or TLD) servers, are like .COM, .NET, .UK, .EDU, and others domain names for example. They also don't know about all the possible data, but do have information for finding all the "second-level" domains (SLD) under them. Generally a third server is asked to get answers for most of the Internet use. When a server refers to another server, this is called a delegation.
. root (the dot)
/ \
com. gov. TLD (top level domain)
| |
disney.com. whitehouse.gov. SLD (second level or final domain)
The database contains resource records. The resources are domain names, a class, and a record type. (In database terms, this is the "key".) The domain name is read from left to right, but used from right to left with period-delimited words known as labels. The class basically defines the schema for the record data associated with the resource. For the common use, this is the Internet (IN) class. The resource record type identifies the format for different types of data. Together these define the query format. The most common query is for an IPv4 address type (A).
The resource record data (RDATA) is the data or value associated with that query label/class/type tuple. There may be multiple data entries or values for a single resource record. This is called a resource record set (RRSET). The database can also contain multiple data entries for the same domain name but for different types. The resource record also contains a time-to-live counter, TTL, which tells a client how long it can store or reuse the values. All the records contained in a single database, usually under a single domain name, is commonly known as a zone.
DNS is a network client/server protocol commonly used over both UDP and TCP.
The clients may be identified in different ways. An end-user client or application layer asks a network server directly or utilizes a local system DNS API or service which can forward the query on or intelligently attempt to find the answer itself. Simple forwarding of a query is called a stub client. Finding the answer from the "root" server and its descendents is called iteration and the service is called a recursive resolver.
A DNS resolver server is effectively a client itself. It accepts incoming queries and returns an answer, It may contain the data locally to return, or on behalf of its questioner, it can iteratively ask other servers the same question. Normally, a resolver server is also a caching server. It stores, reuses, and shares previously looked up answers (resource records) to save time and network resources. These resource records have a TTL provided to them that tell the cache how long they can keep and share that data. These servers handling DNS, whether they are serving original data or sharing cached data, are known as nameservers.
As an example, a lookup for www.stanford.edu (for its address record) against an empty caching resolver will do these steps:
1) Ask a single root server for the www.stanford.edu address record. (It has the IP address for the root servers hard-coded or locally configured.)
The root server will return the server names for the nameservers to ask instead, such as f.edu-servers.net, and their IP addresses. (It will tell the resolver it can cache this information for 2 days.)
2) The resolver will then ask one of these next nameservers for the www.stanford.edu address.
The responsible name server for "edu" doesn't have the answer, but will return the server names for the nameservers that know about stanford.edu, such as argus.stanford.edu (and possibly an IP address). (It also tells the resolver it can cache this information for 2 days.)
3) The resolver then asks one of these next nameservers the same question.
This server has an answer which the resolver also can cache and returns to the client.
Note if it doesn't have the IP address for the intermediate nameservers, the resolver will need to follow the same steps to get the address for the nameservers. When addresses are provided by default when a nameserver tells you what other nameserver to use, this is called "glue".
On a next query for some other domain name under "edu" the resolver doesn't need to ask the root server again (as long as the TTL timer hasn't expired), but can use the cached nameserver(s) instead.
Nearly all use of DNS is to lookup a name to get an address. The DNS lookup support is included with an operating system and some applications also provide their own client implementation. Client tools are available to do lookups, such as the command-line tools: host, getent, ping, nslookup, dig, and many others. The following are a few examples.
The host command looks up IPv4 and IPv6 addresses (known as DNS A and AAAA records, respectively) and the mail servers and priorities (known as the DNS MX record) for the name:
$ host wikipedia.org wikipedia.org has address 208.80.154.224 wikipedia.org has IPv6 address 2620:0:861:ed1a::1 wikipedia.org mail is handled by 10 mx1001.wikimedia.org. wikipedia.org mail is handled by 50 mx2001.wikimedia.org.
The getent tool uses the local hostname address lookup database to lookup an address:
$ getent hosts wikipedia.org 2620:0:861:ed1a::1 wikipedia.org
The ping command is example of a tool that will lookup a single address before it does other work:
$ ping -c 1 wikipedia.org PING wikipedia.org (208.80.154.224) 56(84) bytes of data. 64 bytes from text-lb.eqiad.wikimedia.org (208.80.154.224): icmp_seq=1 ttl=60 time=0.714 ms --- wikipedia.org ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.714/0.714/0.714/0.000 ms
The nslookup command-line tool is an interactive client for looking up details via DNS, but can also be used one at a time:
$ nslookup wikipedia.org Server: 127.0.0.1 Address: 127.0.0.1#53 Non-authoritative answer: Name: wikipedia.org Address: 208.80.154.224
A well-known DNS client tool is DiG which can provide full details from DNS. Here is an example of an abbreviated response with a single answer only:
$ dig +short wikipedia.org 208.80.154.224
These tools can also do lookups of IP addresses to find hostnames, if available, such as in the previous ping example and in the following:
$ host 208.80.154.224 224.154.80.208.in-addr.arpa domain name pointer text-lb.eqiad.wikimedia.org.
Some of the examples above query DNS directly while some of them use local name lookup routines to get results before trying DNS. This book will cover these types of lookups and much more. It will teach how the queries work behind the scenes, including what data is sent and received and from where.
As a simplified explanation, when a normal query is done, first a cache is looked at to see if the name and answer for the query type was previously and still stored. If so, that answer is provided. If not, it falls back to use DNS to iterate asking questions of possibly multiple servers leading to the best source to retrieve the answer. Before we get into detail, let's cover more about the data that is stored.
When providing addresses for a name or looking up addresses for a name, the key record types are the A record for IPv6 addresses, AAAA for IPv6 addresses, and the NS record to define the nameserver names that are responsible - or authoritative - for the name to lookup.
The common or standard way these are represented or stored in human-readable formats is: name, time-to-live, class, type, and value (or answer) separated by spaces and defined on a single line. Notice the following two related examples.
wikipedia.org. 86154 IN NS ns0.wikimedia.org. wikipedia.org. 402 IN A 198.35.26.96 ns0.wikimedia.org. 86346 IN A 208.80.154.238 wikimedia.org. 86128 IN NS ns0.wikimedia.org.
In the first example, a NS record for the name on the left is defined by the name on the right. The address for that name on the right is defined in the second example's A record entry. The first column is the domain name. Notice it ends with a period which indicates it is the end of the name. (If it does not end with a period in a DNS storage file, it is likely to get a name appended to it. This is covered later.)
The second column is the time-to-live or TTL. This is the time in seconds that this entry may be stored and reused locally or may be shared with others, before having to lookup this answer again (for the specific name and type). These examples show real world TTLs that have already started to decrement as counters.
The third column is the DNS class. These examples and basically all DNS usages uses the Internet class, abbreviated as IN. (As mentioned before, this defines a database schema for the available types.)
The type in the fourth column is also called a resource record type or record type and commonly abbreviated as RRTYPE. There are 14 common record types which this book will cover in detail, plus many others which will be introduced.
The final columns provide the values for the name/class/type tuplets. Two of the most common types are the A address record and the NS record which only have a single value for a single record. The address record is simply a human-readable dotted quad IPv4 address. The nameserver field is a hostname of DNS server which is responsible for the domain name. This is used for delegation or for identification.
A name with a record type may have multiple values. This is called a set or resource record set, abbreviated as an RRSET. The following is an RRSET which is a set of three records in this example:
wikimedia.org. 85980 IN NS ns1.wikimedia.org. wikimedia.org. 85980 IN NS ns2.wikimedia.org. wikimedia.org. 85980 IN NS ns0.wikimedia.org.
A single query asking for that name within that class for that type may get a multiple-part answer. Often, the same value may be repeated (duplicated) in an RRSET. The order they are delivered and used varies, but the point is a single question can result in multiple answers and one (or more) can be used. The TTL is not part of the query but is returned in the answers. For brevity in this book, the IN (Internet) class will be assumed in all queries and examples unless specifically teaching about alternate classes.
A DNS query or question has multiple options and flags which are covered through out this book. A DNS response has multiple flags and parts also covered in this book. The most common part of a response is the ANSWER section, but there are also response sections known as the AUTHORITY section which tells where to query instead via a list of NS records; and the ADDITIONAL section which provides supplement information such as corresponding A addresses (the "glue") for the AUTHORITY NS records. Examples are shown in the following.
Using this same name as an example, looking up its address the first time would commonly involve the following iterative steps by a recursive resolver.
First, ask a root server to learn who is responsible for wikipedia.org. The root servers are the starting point. Twelve organizations run hundreds to thousands of servers for 13 IPv4 and and IPv6 addresses using distributed routing technologies (such as Anycast). Their alphabet-labeled names are a.root-servers.net. through m.root-servers.net. The IP addresses for the root servers are builtin or already configured and primed into the DNS resolver. You don't have to do this priming step as this is done automatically (and this will be covered in detail later). Nor do you have to do the initial query, but if you did it would look like the following:
$ dig @j.root-servers.net wikipedia.org ; <<>> DiG 9.10.5-P1 <<>> @j.root-servers.net wikipedia.org ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60180 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 13 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1472 ;; QUESTION SECTION: ;wikipedia.org. IN A ;; AUTHORITY SECTION: org. 172800 IN NS a0.org.afilias-nst.info. org. 172800 IN NS a2.org.afilias-nst.info. org. 172800 IN NS b0.org.afilias-nst.org. org. 172800 IN NS b2.org.afilias-nst.org. org. 172800 IN NS c0.org.afilias-nst.info. org. 172800 IN NS d0.org.afilias-nst.org. ;; ADDITIONAL SECTION: a0.org.afilias-nst.info. 172800 IN A 199.19.56.1 a2.org.afilias-nst.info. 172800 IN A 199.249.112.1 b0.org.afilias-nst.org. 172800 IN A 199.19.54.1 b2.org.afilias-nst.org. 172800 IN A 199.249.120.1 c0.org.afilias-nst.info. 172800 IN A 199.19.53.1 d0.org.afilias-nst.org. 172800 IN A 199.19.57.1 a0.org.afilias-nst.info. 172800 IN AAAA 2001:500:e::1 a2.org.afilias-nst.info. 172800 IN AAAA 2001:500:40::1 b0.org.afilias-nst.org. 172800 IN AAAA 2001:500:c::1 b2.org.afilias-nst.org. 172800 IN AAAA 2001:500:48::1 c0.org.afilias-nst.info. 172800 IN AAAA 2001:500:b::1 d0.org.afilias-nst.org. 172800 IN AAAA 2001:500:f::1 ;; Query time: 40 msec ;; SERVER: 192.58.128.30#53(192.58.128.30) ;; WHEN: Wed Jan 06 21:08:24 CST 2021 ;; MSG SIZE rcvd: 444
In the above DiG example, a single root server was asked for an A address record. This remote server did not know about the name queried and did not provide any answers. But it did know about the org. Top Level Domain so it provided an AUTHORITY section with six NS records. One or more of these NS targets can be used to ask about the initial query name. (By default, DiG asks for the A address record type. Further details about the DiG command and its outputs will be explained in this book.)
This root server knows about the addresses for those NS hostnames, so it provided 13 records for them in the ADDITIONAL section.
The root servers know about all 1500-plus Top Level Domains - the right-hand side, last label of domain names. This includes the original com, org, net, edu, gov, mil, and arpa domain names; 255 country-code top level domains (also known as ccTLD) such as uk, us, and jp; and many generic top level domains (gTLD) like actor, news, and wedding.
The root servers can provide the nameservers names (NS) and their addresses for the many TLDs, such as in the previous org example. These second level of servers can provide answers closer to the names to lookup.
The second step in this simple recursing example is to query against one of those IP addresses above. For example, one of the AUTHORITY section records has a NS of c0.org.afilias-nst.info and the ADDITIONAL section has 199.19.53.1 as its IP address - which can be used for next query:
$ dig @199.19.53.1 wikipedia.org ; <<>> DiG 9.10.5-P1 <<>> @199.19.53.1 wikipedia.org ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10355 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 4 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;wikipedia.org. IN A ;; AUTHORITY SECTION: wikipedia.org. 86400 IN NS ns0.wikimedia.org. wikipedia.org. 86400 IN NS ns1.wikimedia.org. wikipedia.org. 86400 IN NS ns2.wikimedia.org. ;; ADDITIONAL SECTION: ns0.wikimedia.org. 86400 IN A 208.80.154.238 ns1.wikimedia.org. 86400 IN A 208.80.153.231 ns2.wikimedia.org. 86400 IN A 91.198.174.239 ;; Query time: 36 msec ;; SERVER: 199.19.53.1#53(199.19.53.1) ;; WHEN: Thu Jan 07 19:18:36 CST 2021 ;; MSG SIZE rcvd: 154
The above example again has no answers but does point to more NS nameservers (with corresponding glue addresses) to try, in this case specific for the queried name.
So continuing with this example, we will do a DNS query using one of these newly found nameservers:
$ dig @208.80.153.231 wikipedia.org ; <<>> DiG 9.10.5-P1 <<>> @208.80.153.231 wikipedia.org ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20540 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1024 ;; QUESTION SECTION: ;wikipedia.org. IN A ;; ANSWER SECTION: wikipedia.org. 600 IN A 208.80.153.224 ;; Query time: 7 msec ;; SERVER: 208.80.153.231#53(208.80.153.231) ;; WHEN: Thu Jan 07 19:21:24 CST 2021 ;; MSG SIZE rcvd: 58
Notice here that it has one answer which may be cached and reused for 600 seconds. It also doesn't have any AUTHORITATIVE nor ADDITIONAL section records in the response. This simple iterative resolution is done. To summarize as if this was done automatically with a resolver: it started with one of the root nameservers hardcoded or primed in the resolver; then iteratively asked the same question to one new nameserver for each depth until it finally gets an answer.
There are other variations in this resolution, such as using intermediate nameservers already known from a cache (and not expired from their TTL), asking for and utilizing security features, trying multiple nameservers simultaneously (including via IPv6), and others.
Some of the previous examples show header "flags" as reported back from a remote nameserver. The final simple example above showed an "aa" flag which indicates that sending nameserver is authoritative for the name asked about - in other words, it is a nameserver where that domain name is officially configured to serve its official record answers. (We will talk about EDNS Flags later.)
The DNS message flags are sent in original queries and also sent back in responses. They are also called "bits".
As seen earlier, two other common flags are "qr" meaning it is a response to the query and "rd" (recursion desired) which means you asked for the remote nameserver to do the entire recursion for you (versus you doing each iteration). In those previous DiG examples, there were DiG comments saying that this recursion was requested but not provided. If a nameserver can do recursion for others, then it will return back an "ra" flag indicating it is available.
Another response flag is the "tc" flag which indicates that the remote server truncated the response over a UDP connection. This tells the client to try again using TCP instead. This will be covered in detail later in this book.
DNS queries are sent with a transaction identification number (also known as a TXID), such as seen in the previous ``id: 20540'' example. A response is sent back with the corresponding ID number which the resolver or client uses to match answers with the question. It also matches on the UDP or TCP source port and the query tuple too. The ID number ranges from 0 to 65535.
This question/answer matching is insecure and can be abused by malicious senders by racing to send back an alternative spoofed answer instead with both a predicted or guessed source port number and TXID. This will be covered further in the cache poisoning section. Additional values for comparisons include 0x20 and DNS Cookies. DNS Security (DNSSEC) data may also be used to confirm that responses are not modified in transit.
DNS servers also return a status code, also known as a RCODE, when responding. (Such as seen in the previous DiG examples showing ``status: NOERROR'' comments.) The common RCODEs are:
If a nameserver knows about the query and sends back an answer or AUTHORITY section records, it will provide a NOERROR response code meaning there wasn't a problem.
If a query for a name exists but for a different resource record type, no ANSWER section will be returned (and the answers count will be zero) and, instead, a SOA record will be returned in the AUTHORITY section. This is not an error so a NOERROR status will be provided. An example of known name with an unknown type follows:
$ dig wikipedia.org -t TYPE2021 ; <<>> DiG 9.10.5-P1 <<>> wikipedia.org -t TYPE2021 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37545 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;wikipedia.org. IN TYPE2021 ;; AUTHORITY SECTION: wikipedia.org. 3397 IN SOA ns0.wikimedia.org. hostmaster.wikimedia.org. 2020120918 43200 7200 1209600 3600 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sat Jan 23 15:00:23 CST 2021 ;; MSG SIZE rcvd: 103
The SOA, or Start of Authority, record type is a special type with multiple purposes. It will be explained in this book.
If no record exists for the queried name and type (and class), the NXDOMAIN status is returned (for no such domain). The responding nameserver won't provide any answer, but will return a SOA record in the AUTHORITY section. See the following status and AUTHORITY section example from querying for a domain that does not exist:
$ dig doesnotexist.wikipedia.org ; <<>> DiG 9.10.5-P1 <<>> doesnotexist.wikipedia.org ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 5945 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;doesnotexist.wikipedia.org. IN A ;; AUTHORITY SECTION: wikipedia.org. 3114 IN SOA ns0.wikimedia.org. hostmaster.wikimedia.org. 2020120918 43200 7200 1209600 3600 ;; Query time: 6 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sat Jan 23 15:05:06 CST 2021 ;; MSG SIZE rcvd: 116
If the nameserver is not configured to provide an answer for the client - or is specifically configured to not provide answers for a client, a REFUSED status code is returned. When the client's query is refused, no records are returned. The following example shows that a nameserver refuses to provide an answer for an unrelated domain:
$ dig @ns0.wikimedia.org. army.mil ; <<>> DiG 9.10.5-P1 <<>> @ns0.wikimedia.org. army.mil ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 49185 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1024 ;; QUESTION SECTION: ;army.mil. IN A ;; Query time: 39 msec ;; SERVER: 208.80.154.238#53(208.80.154.238) ;; WHEN: Sat Jan 23 15:11:51 CST 2021 ;; MSG SIZE rcvd: 37
Note that the client may be able to get answers for other queries from the same target nameserver, so a REFUSED doesn't indicate that all possible queries from the client are rejected.
If the nameserver has a problem, it may return a SERVFAIL status. This is an overloaded return code that is returned for many different reasons which in standard DNS are not easily explained for the client. When this server failure is returned, the DNS response will not include any answers or records.
Server failure examples may include: the nameserver is configured to know about the domain, but couldn't load its domain data (so had nothing to share); all nameservers delegated to provide answers are unvailable; a nameserver name didn't have any corresponding address; or a security validation failed. These and other SERVFAIL statuses with examples will be covered further in this book.
DNSSEC (Domain Name System Security Extensions) adds resource records and message header bits which can be used to verify that the requested data matches what the zone administrator put in the zone and has not been altered in transit.
The 1987 specifications of the Domain Name System define a 16 bit identifier to be sent with queries and copied in the corresponding responses -- and the resolver should use this to match up replies.
Basically, the DNS protocol defines a query to include:
On some old DNS implementations, the ``query ID'' (or DNS ID) was not randomized and, in some cases, it didn't even change or was simply sequential and easy to guess.The malicious party just needs to provide back the DNS response with the above information before the real legitimate server replies. This can be a race - or a technique.It is easily done if the attacker has a working packet sniffer on the network - they simply just provide back their own answer first.
The original DNS protocol implementors and DNS administrators didn't assume or foresee that there may be malicious (or accidental) abuse -- that some may provide back their own answers to spoof DNS.It's obvious that forged DNS can cause problems, such as redirect and steal from customers, distort public perception, change news, intercept communications, bypass some address-based security methods, and other impersonation situations.
In 1988, Project Athena at MIT added an authentication extension to BIND. Their Hesiod name server used the DNS additional information section to include a Kerberos ticket.
Security researcher Steven M. Bellovin's ``Security Problems in the TCP/IP Protocol Suite'' paper published in 1989 clearly identified a sequence number attack against a particular user but didn't specifically suggest poisoning an entire cache.
Christoph Schuba's 1993 ``Addressing Weaknesses in the Domain Name System Protocol'' thesis outlined problems with predictable IDs, spoofing referrals, cache poisoning, and documented a mechanism to use signatures and public keys stored in DNS.
The first DNS Protocol Security Extensions IETF draft specification (draft-ietf-dnssec-secext-00.txt) was published in February 1994. This proposed using digital signatures and authentication keys added as resource records to assure data integrity or authentication.
The IETF working group for DNSSEC started in March 1994 with a goal of specifying digital signature enhancements to the DNS protocol to protect against unauthorized modification of data (i.e. add data integrity) and protect against faking the DNS origin.
The final Security Extensions draft (draft-ietf-dnssec-secext-09.txt) was published in January 1996.The Internet standards track protocol for Domain Name System Security Extensions (RFC 2065) was published in January 1997 based on the draft.
In April 1997, Secure Networks Inc. and CORE Seguridad de la Informacion published a security advisory that showed how ``[t]he usage of predictable IDs in queries and recursed queries allows for remote cache corruption.'' (It also provided a patch to help reduce this problem.)
RFC 2065 was made obsolete in March 1999 by a new Internet standard for Domain Name System Security Extensions, RFC 2535.
Then that became obsolete by new Internet standards -- ``DNS Security Introduction and Requirements'' (RFC 4033), ``Resource Records for the DNS Security Extensions'' (RFC 4034), and ``Protocol Modifications for the DNS Security Extensions'' (RFC 4035).
All current versions of BIND implement these latest DNSSEC protocol extensions.
As DNSSEC was proposed and then developed, most of the researchers and implementors agreed that the standard DNS protocol should be able to work the same and DNSSEC must be designed with backwards compatibility in mind. In other words, it must co-exist with existing DNS clients and servers that don't support DNSSEC.
They also agreed that data available in the DNS is to be considered public information. So they didn't design or implement standards for access control or data confidentiality as part of DNSSEC.
It is important to note that it doesn't prove that the destination content is correct -- use PGP, HTTPS/TLS, etc. for that. DNSSEC is just for the DNS part.
DNSSEC doesn't provide a secure tunnel; it doesn't encrypt or hide DNS data. While SSL and DNSSEC use many of the same underlying public key cryptography techniques, they are packaged up differently and provide different results.
A DNSSEC-validating resolver will request DNSSEC records and the DNSSEC-enabledserver will automatically send back the corresponding signature (in a DNS Resource Record).
The public key for verifying the signature is available in another Resource Record (and it has corresponding signature too).
If the DNSSEC-aware parent tells the resolver to look elsewhere (aka a referral), it may also automatically send back a record to help authenticate the child -- this is a hash of the public key.
DNSSEC also provides a mechanism to verify that a record does not exist.
DNSSEC requires Extension Mechanisms for DNS (EDNS0).
EDNS0 provides support for new flags, return codes, and label types. It also allows the DNS Message Size / UDP Payload Size to go beyond 512 bytes.
EDNSO provides a new pseudo Resource Record called OPT that may be sent with transport messages. To ask for DNSSEC resource records, a validator sets the the DNSSEC OK bit (DO) in the OPT record in the additional section of the query.
EDNS has been available for over eight years and many servers (and all root servers) support it. Nevertheless, some broken servers and network devices cause problems with EDNS0.
It is important to make sure firewalls don't block EDNS0 packets larger than 512 bytes.
Two DNS flags and a few resource records were introduced for DNSSEC. The DNSSEC flags and resource record types are covered in detail in upcoming chapters.
You may see documentation or configurations using NXT, SIG, and DLV. These are from obsolete DNSSEC specifications and this book doesn't cover them.
The additional message header bits provided for DNSSEC are:
In the standard use of DNSSEC, all DNS resource records sets have corresponding RRSIG resource records. It is for a record set not per individual records; for example, if a signed zone has four NS records with same label (name), class, and type then it will have one corresponding RRSIG.
The RRSIG resource record includes the signature which is a hash of the resource record set data encrypted with a private key. (The creation of the private key is covered in Section [*].)
DNSSEC-enabled servers automatically provide the RRSIG for records that have been setup with DNSSEC when the DNSSEC OK bit (DO) in the OPT record is set in the additional section of the query. This is sent in addition to the answer to the query.
Note that DNSSEC changes the rule where a CNAME RR can't exist with same name as another record.
The RRSIG is not generated at the time of the request. The dnssec-signzone tool included with BIND generates RRSIG records. (This is covered in Section [*].)
Or authoritative servers can sign data for dynamic zones.
In the following example, the RRSIG is automatically sent back in the ANSWER section in addition to the answer to the original question.
$ dig +dnssec +multi www.isc.org ; <<>> DiG 9.4.1-P1 <<>> +dnssec +multi www.isc.org ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3864 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 5, ADDITIONAL: 1
;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION: ;www.isc.org. IN A
;; ANSWER SECTION:
www.isc.org. 360 IN A 204.152.184.88
www.isc.org. 360 IN RRSIG A 5 3 600 20080811233247 (
20080712233247 23919 isc.org.
QHb4cd4CPX002BO81TozDOzHpr9vH7sUFN4Thc7YXYnM
Po2D8YQEKVud9B7lv02PxsG1IAIjteAA/CdpFPPX6i3l
/cgXh8gD9/XPPexISI0I3XNKcReEvPCMbVdlnQ1uijfy
D9GfafK/oFc+rb9COk7lij7v8M9RLmSCO0tOqyc= )
;; AUTHORITY SECTION:
isc.org. 852 IN NS ns-ext.isc.org.
isc.org. 852 IN NS ns-ext.sth1.isc.org.
isc.org. 852 IN NS ns-ext.nrt1.isc.org.
isc.org. 852 IN NS ns-ext.lga1.isc.org.
isc.org. 3360 IN RRSIG NS 5 2 3600 20080811233247 (
20080712233247 23919 isc.org.
x9lZ66UNrwTVixJndWSlG/BDGPuCq00cyvVLNp4lrgPH
QrNoq/4UHWZoQyHySxVcsV21y9/BEjzWC2HcPvzUkwnt
essyxq2+TSOKOKu4o5aL8qUvDMvXSG6apQuMY7kYxcoH
NDh3LppbUpxuIV0Mm8zwharO2PEUb6UYQZNvs60= )
;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Thu Jul 17 09:49:55 2008 ;; MSG SIZE rcvd: 489
If the zone contains a KSK and a ZSK, then multiple RRSIGs will be generated for the DNSKEY resource record sets. The RRSIG's key tag will identify the KSK or ZSK used to sign the record set. Other record sets (non DNSKEY) will only be signed by the ZSK.
The RRSIG record data includes:
The signature expiration and inception time is specific to the second and may be recorded using epoch time or in YYYYMMDDHHMMSS format. It based on the UTC timezone. An example is 1552194000 or 20190310050000 for March 10, 2019 at 05:00:00 a.m. UTC. Note that the expiration time is listed first.
The RRSIG record data includes:
;; ANSWER SECTION:
www.isc.org. 360 IN A 204.152.184.88
www.isc.org. 360 IN RRSIG A 5 3 600 20080811233247 (
20080712233247 23919 isc.org.
QHb4cd4CPX002BO81TozDOzHpr9vH7sUFN4Thc7YXYnM
Po2D8YQEKVud9B7lv02PxsG1IAIjteAA/CdpFPPX6i3l
/cgXh8gD9/XPPexISI0I3XNKcReEvPCMbVdlnQ1uijfy
D9GfafK/oFc+rb9COk7lij7v8M9RLmSCO0tOqyc= )
The DNSKEY can be generated using the dnssec-keygen tool included with BIND. (Creating this public key is covered in Section [*].)
The DNSKEY is for the zone, not for individual labels. It is stored in the same zone.
The RRSIG is generated with the private (secret) key.
The DNSKEY is the public key used to validate that signature.
A hash of it is provided to the parent. (DS key covered later.)
Secure entry point to a zone; first link in the chain of trust.
First a dig +dnssec:
$ dig +multi +dnssec 5.97.27.216.in-addr.arpa. PTR
...
;; ANSWER SECTION:
5.97.27.216.in-addr.arpa. 79292 IN PTR weasel.cool.magpi.net.
5.97.27.216.in-addr.arpa. 79292 IN RRSIG PTR 5 6 86400 20081031000000 (
20080630000226 44016 97.27.216.in-addr.arpa.
aPvV3IGFQTlbZFhhW/x8QI+mT11W9PRZrTTNCnn3GEPW
cWRLowEc++RC/JT1iicKoJbJs1ylKt9JayBce+bOBb2C
WtXTr2li6DoiGVUfFSmLiRR3EkfGnu5yMtmFuJaMzjXw
w2NyCnmc1ay9WijjkkX54xTW8ujwBq+rkNJkNHk= )
... ;; AUTHORITY SECTION: 97.27.216.in-addr.arpa. 79292 IN NS dns-01.magpi.net. 97.27.216.in-addr.arpa. 79292 IN NS dns-02.magpi.net. ...
$ dig +multiline 97.27.216.in-addr.arpa. DNSKEY
...
;; ANSWER SECTION:
97.27.216.in-addr.arpa. 3521 IN DNSKEY 256 3 5 (
AwEAAcHtWTTzG23znibGN984gWfciDjDaeR7kU0iD0Bm
//n2kuVpgrQSBbxznUkt+fUvUTADmUngESp6e4EbJxIX
jiZ/kfHt8Anp9Zfw2X1PqZWa848uUYtVDzseKnG0MJGE
cShBCZoatPkzlu3gEYMmNnvi4ZZCOVkEUzQ4km1p0gNl
) ; key id = 44016
97.27.216.in-addr.arpa. 3521 IN DNSKEY 257 3 5 (
AwEAActJrxoI+TUlEMLeh3S76JONO28TzALmLPtTjd03
...
1niRkifBYNzYJuAfy/+yqvaw//RZlg6S4HV/HYc=
) ; key id = 45973
...
The dig +multiline option is used to better format for long output and also provides useful comments such as DNSSEC ``key id'' for quick comparisons.
The keyid is only a hint; there is no uniqueness guarantee. It is at most a simple checksum; it has no crypto property.
Dig again
;; ANSWER SECTION:
97.27.216.in-addr.arpa. 3343 IN DNSKEY 256 3 5 (
AwEAAcHtWTTzG23znibGN984gWfciDjDaeR7kU0iD0Bm
//n2kuVpgrQSBbxznUkt+fUvUTADmUngESp6e4EbJxIX
jiZ/kfHt8Anp9Zfw2X1PqZWa848uUYtVDzseKnG0MJGE
cShBCZoatPkzlu3gEYMmNnvi4ZZCOVkEUzQ4km1p0gNl
) ; key id = 44016
...
97.27.216.in-addr.arpa. 3343 IN RRSIG DNSKEY 5 5 3600 20081031000000 (
20080630000226 44016 97.27.216.in-addr.arpa.
ld7XP1cMo71J1kT7agDtjla4EkX+Tr8CrtB3z1VHbgtJ
uhufGLaxw425hQMPp+6DM2CQOLr/uN41ZYrAvqPMF+Jo
P6mIn1JXzz2RQsKsmK63jO8LcrE5N/8Y7Y+w2G6VwWwL
LNiMA6exIU4YvBRcnQhIeW4Wf+pvKVQfOEQf61E= )
You can not generate both NSEC and NSEC3 records at the same time -- it is pointless for dnssec-signzone to do so.
97.27.216.in-addr.arpa. 3521 IN DNSKEY 256 3 5 (
AwEAAcHtWTTzG23znibGN984gWfciDjDaeR7kU0iD0Bm
//n2kuVpgrQSBbxznUkt+fUvUTADmUngESp6e4EbJxIX
jiZ/kfHt8Anp9Zfw2X1PqZWa848uUYtVDzseKnG0MJGE
cShBCZoatPkzlu3gEYMmNnvi4ZZCOVkEUzQ4km1p0gNl
) ; key id = 44016
97.27.216.in-addr.arpa. 3521 IN DNSKEY 257 3 5 (
AwEAActJrxoI+TUlEMLeh3S76JONO28TzALmLPtTjd03
...
1niRkifBYNzYJuAfy/+yqvaw//RZlg6S4HV/HYc=
) ; key id = 45973
record has a KeyID, Key Algorithm Type, a Digest Type (like ``1'' for SHA-1 and ``2'' for SHA-256), and a digest of the key. The KeyID is not guaranteed to be unique; it is a hint, really
The dnssec-signzone tool creates multiple files: the signed zone, a dsset-example.org. file, and a keyset-example.org. file.
This dsset file contains the SHA-1 and SHA-256 DS records corresponding to the Key Signing Key (257) for the parent. This dsset file may be shared to a parent. The keyset file contains the DNSKEY record for the zone's Key Signing Key (257).
When ran with the -g option, if the zone being signed has a child NS record (there is a delegation) with a corresponding keyset file, then DS records are generated for that child label and included in the zone (which is the parent). It looks for the child keyset files in the same directory or in directory defined by -d option.
You can generate the DS records without re-signing the zone by using dnssec-dsfromkey.
tcpdump showing A request to parent (D.NS.se):
14:16:51.837895 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 67) 192.168.1.2.55604 > 81.228.8.16.53: [udp sum ok] 59555 [1au] A? www.iis.se. ar: . OPT UDPsize=4096 OK (39)And returning answer also includes DS:
14:16:51.992328 IP (tos 0x0, ttl 47, id 0, offset 0, flags [DF], proto UDP (17), length 418) 81.228.8.16.53 > 192.168.1.2.55604: [udp sum ok] 59555- q: A? www.iis.se. 0/6/4 ns: iis.se. NS ns.nic.se., iis.se. NS ns2.nic.se., iis.se. NS ns3.nic.se., iis.se. DS, iis.se. DS, iis.se. RRSIG ar: ns.nic.se. A 212.247.7.228, ns2.nic.se. A 194.17.45.54, ns3.nic.se. A 212.247.3.80, . OPT UDPsize=4096 OK (390)
; authauthority
iis.se. 3594 NS ns.nic.se.
...
; authauthority
3594 RRSIG NS 5 2 3600 20080809115418 (
20080730115418 35613 iis.se.
kpVqDEWpNWE/0Kn+CQIhK4Y0fKt75wuPnUjr
zWGcSnXtEyrVqjddZMwXzedu0Tm/VE5ChQtc
wG8jGMJjsieLHkYyXdAkOY6aDBxeOwuIaiGH
y5CrnslSGbZH0bkPZfCgs+dRni3aznw3M/J9
8mm+We3GG5Wm5zkBjpHcR0+1pAg= )
; additional
3593 DS 18937 5 1 (
10DD1EFDC7841ABFDF630C8BB37153724D70
830A )
3593 DS 18937 5 2 (
B5C422428DEA4137FBF15E1049A48D27FA5E
ADE64D2EC9F3B58A994A6ABDE543 )
; additional
3593 RRSIG DS 5 2 3600 20080804152937 (
20080730021242 23073 se.
FXk7xLmAv8Sjj7y9rsIIBG/o2Trwq9nmdFoK
atSjMh6lnFEc31O94QGX/EHP1aFxyeLWFRIC
QY5ykZpITzoQFuymWvJdSyMEC2e+Lzvz/D6K
PRbBAFLIZlDevL3pEHcSv5iTvzbVfZQr3XI+
1bLuvRciKgHvSBKJiggaMdpSu3Y= )
; authanswer
ext.prod.iis.se. 54 A 212.247.7.210
; authanswer
54 RRSIG A 5 4 60 20080809115418 (
20080730115418 35613 iis.se.
BHuoA+dORSqntSZdhsmMstMg7QUSRy/QFsnn
fJMU+im7p7oabpTottjoe2oBN2eAGdUZ+hAv
YL45lZu9GHE6Jj9DURVHvwPZWBVniA+0aXZ9
PVjnhVB4JcF1zuuVv04AYd/SWlT2o/lSX9SV
zhTkcivyD6KpOs+ykY+Oj1W1WGY= )
; authanswer
www.iis.se.54 CNAME ext.prod.iis.se.
An NSEC record lists the types for published label and class pairs.
In the case that the status is NOERROR (such as the name exists but for a different RRTYPE) and the server returns no answers for the question, the DNSSEC-enabled server will return in the Authority section: the SOA (normal to return in DNS), plus its signature(s), and an NSEC record for the same requested label and class, and the signature(s) for that NSEC record. This NSEC will show that the requested type is not listed.
If the status is NXDOMAIN (the name does not exist for any RRTYPE), the DNSSEC-enabled server will return (in the AUTHORITY section) one or two NSEC records. (In the case of NSEC3, it may be more than two records.)It may provide an NSEC record for previous label that refers to the next label. (The next label is in the NSEC resource data.)This NSEC record is used to prove that the desired label doesn't exist by showing the alphabetically previous and next label.
For example asking for non-existent ``ftp.example.net'' may return with:
family.example.net. 10800 IN NSEC lists.example.net. A RRSIG NSEC
(Where family and lists labels do exist.)
An example of walking a signed zone:
$ dig +short gov NSEC 2010CENSUSJOBS.gov. NS SOA RRSIG NSEC DNSKEY $ dig +short 2010CENSUSJOBS.gov. NSEC 211ARIZONA.gov. NS RRSIG NSEC $ dig +short 211ARIZONA.gov. NSEC 211AZ.gov. NS RRSIG NSEC $ dig +short 211AZ.gov. NSEC 404.gov. NS RRSIG NSEC ... $ dig +short SCIENCE.gov. NSEC SCIENCE360.gov. NS RRSIG NSEC $ dig +short SCIENCE360.gov. NSEC SCIENCEACCELERATOR.gov. NS RRSIG NSEC $ dig +short SCIENCEACCELERATOR.gov. NSEC SCIENCEEDUCATION.gov. NS RRSIG NSEC
$ dig +multi +dnssec registro.br ; <<>> DiG 9.4.1-P1 <<>> +multi +dnssec registro.br ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56725 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 6, ADDITIONAL: 1
;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;registro.br. IN A
;; ANSWER SECTION:
registro.br. 172800 IN A 200.160.2.3
registro.br. 172800 IN RRSIG A 5 2 172800 20080911160740 (
20080703160740 54964 registro.br.
CPY1Sdb2V/Nf/khuZr2pv8rjXTuUN7WV5YVy+RHOgJ/9 Dgk5V8oSo0gB9coyvofru/DiKHIY+o10oyPNWjcGI4mi
HkwWHQV2lL4+vQWZAEcrUGBuRWL90/6fTvjUJk+LqzvL
MInS64xdW8KumW55zspq0jKPehNfL40fN5zFSInSkZ0Q
BtxKy+yZleckYQs5 )
...
trusted-keys {
# https://registro.br/ksk/
"br." 257 3 5
"AwEAAcmqkFULGgm1VlBbUYQEuCzSbEByjAcNInY9gxft
bTK+CSYwlGAfxl5hwx7kxOQAZ2ZMLrxD+sTQVC4StoAP
PcUhFqEGOV+9GI6SsD/fikQ0IhtXaS6INKk0POkfBqot
k6C5QbbVXcsML54/dtZYWi/Z7CaG2Hz93ouyUMQzIPoh
ER+gkbFYq3ewDajqJKNsVm8caT9/mkNw+CQHR+QNmWM=";
};
; <<>> DiG 9.4.1-P1 <<>> +multi +dnssec registro.br ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54989 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 6, ADDITIONAL: 13
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;registro.br. IN A
;; ANSWER SECTION:
registro.br. 172800 IN A 200.160.2.3
registro.br. 172800 IN RRSIG A 5 2 172800 20080911160740 (
20080703160740 54964 registro.br.
CPY1Sdb2V/Nf/khuZr2pv8rjXTuUN7WV5YVy+RHOgJ/9
Dgk5V8oSo0gB9coyvofru/DiKHIY+o10oyPNWjcGI4mi
HkwWHQV2lL4+vQWZAEcrUGBuRWL90/6fTvjUJk+LqzvL
MInS64xdW8KumW55zspq0jKPehNfL40fN5zFSInSkZ0Q
BtxKy+yZleckYQs5 )
The root trust anchor can be a key file for Knot Resolver, BIND named, and Unbound.
Or the root trust anchor can be automatically fetched from IANA.
Negative Trust Anchors, or NTA, are used to temporarily disable validation for specific domains or labels under a domain. This may be needed if some important domains validate as Bogus but you need to return their answers (hoping they are correct) instead of SERVFAIL.
RFC5011 hold-down timer is 30 days (change with knot: trust_anchors.hold_down_time)
RFC5011 defines the refresh time for updating trust anchors.
knot resolver testing RFC5011 refresh timer: trust_anchors.refresh_time
knot-resolver: trust_anchors.keep_removed default is 0 on how many removed keys to keep in key file (before being purged)
knot-resolver can add DS or DNSKEYs for testing or files containing them.
The unbound-anchor tool may be used to update the root trust anchor prior to starting the Unbound server. It wil first try doing an RFC5011 update (like Unbound does) and if it fails, it will fetch it in an XML format over HTTPS and verifies it using a certificate.
PowerDNS Recursor's rec_control tool can be used to add and remove trust anchors and negative trust anchors.
These are only known at run-time. To permanently configure a NTA use the addNTA() Lua configuration function, for example:
addNTA('example.', "Someone messed up the delegation")
(Restart the Recursor to use the Lua config to use it or use the rec_control add-nta command in addition to that.)
The configured negative trust anchors can be listed with rec_control get-tas
All negative trust anchors ay be removed by running rec_control clear-nta '*'
(Be sure to put quotes around the wildcard asterisk so it won't be expanded by the Unix shell.)
The configured trust anchors can be listed with rec_control get-tas
Unbound and PowerDNS Recursor provide diagnostic lookups to see status of trust anchors.
PowerDNS Recursor has trustanchor.server CH TXT and negativetrustanchor.server CH TXTThis is disabled by default for PowerDNS Recursor. To enable this feature set the allow-trust-anchor-query option to yes.
If a name results in NXDOMAIN (as it doesn't exist), then no names could be under it (as documented in RFC 8020). If a name doesn't exist with NXDOMAIN and has corresponding signed NSEC or NSEC3 (without OPTOUT), then any queried names under it can be answered with NXDOMAIN too using a previously-cached response.
By default, if Unbound or PowerDNS Recursor has cached a NXDOMAIN with DNSSEC validated records, then it will respond with the NXDOMAIN and the corresponding DNSSEC records for any name under that tree. For Unbound this is defined using the harden-below-nxdomain option and it will only be used for DNSSEC validated NXDOMAINs.
With PowerDNS Recursor this is defined by default with the nothing-below-nxdomain=dnssec option. Setting it to "yes" will use any NXDOMAIN record from its cache even if it wasn't DNSSEC signed -- as long as it didn't fail validation.
If the zone is signed, it also validates the nameserver NS records and nameserver addresses used to find it. This is not an RFC standard and it is said extra queries could cause performance problems.
If there are multiple DS records with different algorithms, then a DNSKEY using the same algorithms should be provided and the zone also signed with each algorithm. CITE: RFC6840 5.11/3
The NSEC records supplementing NXDOMAIN responses help identify what names and record types actually exist in the zone. This can be used to stop further lookups (as long as this data is cached) which should return the same NXDOMAIN.
If using name server features to modify the results, such as Unbound's "private-address" feature which excludes addresses from answers, DNSSEC validation would fail as the signature hash would not match.
When a DS record is seen in a referral, if the Unbound prefetch-key option is enabled, then also immediately lookup the corresponding DNSKEY record also. It will be needed anyways, so this will save a moment as it is done simultaneously as the next lookup (using the referral).
Lame means that the nameserver that should be authoritative doesn't know about it. DNSSEC Lame means that it does not serve DNSSEC signatures. Unbound will try up to four nameservers, looking for a response with signatures. To stop the additional lookups, enable the Unbound disable-dnssec-lame-check option.(Note this will not stop a DNSSEC failure, but may make it happen faster.)
To reduce or change the amount of time that the new trust anchor must be visible before using it, set the Unbound add-holddown option to a time in seconds. (For example, 1296000 is for 15 days.)
The older trust anchors are revoked and are removed after 30 days (per RFC5011). To change how long the revoked trust anchors are kept, set the Unbound del-holddown option to the time in seconds.
If a trust anchor hasn't been seen for 366 days, Unbound will automatically remove it. This is useful for rollovers not using trust anchor revocations. To disable removing the missing trust anchors automatically, set the Unbound keep-missing option to 0 (zero). Or to change the amount of time, set that option to the time in seconds (such as 15811200 for half a year).
By default per the RFC 5011 specification, the probe interval, retry, and wait times are capped to at least one hour. To allow smaller times, set the Unbound permit-small-holddown option to yes.
Unbound will report it using the new root key via a query with the key tag encoded in the query name. (An alternative method using a EDNS option code is also available, but is rarely used.)
Again the key tag identifies the key.
This reporting is enabled by default in Unbound using the trust-anchor-signaling option and in BIND named using the trust-anchor-telemetry option.
In addition to the validating nameserver reporting what root anchor(s) it is using, it can also be queried by its own clients to check if it is using or not using a particular root key signing key.
Unbound has this enabled with the root-key-sentinel option.
The PowerDNS Recursor is built knowing the DS record for the root key. But it doesn't have any automated trust anchor support nor does it record trust anchors to the disk.
"rec_control add-ta" won't save the DS record to the disk. To make the DS record available at startup, use the Lua configuration addTA() function. For example:
addTA('.', "20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d") - 2017-02-02
The DNSSEC Lookaside Validation (DLV) was a method for testing or implementing signed zones before the roots were signed. A root operator and non-profit DNS service provider (and author and maintainer of BIND), Internet Systems Consortium (ISC) hosted a DNS zone dlv.isc.org with DLV records for third-parties from 2006 to 2017.
Validating nameservers enabled to use DLV who didn't find a root trust anchor would then lookaside by appending the DLV domain name (like dlv.isc.org) to the name being validated to see if a DLV record was available and use it for its chain of trust.
Unbound features dlv-anchor-file and dlb-anchor (to define the DLV keys using DS or DNSKEY formats) should not be used.
BIND removed its DLV support and ISC decommissioned its DLV service in September 2017.
If not using the automated root server trust anchor management with Unbound, you can manually enter the keys using DS or DNSKEY records in the Unbound trust-anchor option or in the file pointed to by the trust-anchor-file option. This is not recommended since the root servers will periodically publish new keys and later remove their old keys.
Unbound can also use a BIND9 named.conf style "trusted-keys" configuration by pointing to the named.conf file using the Unbound trusted-keys-file option.
If there are public DS records for a working chain of trust, but the domain is used internally unsigned, you can disable the validation for it. To not even try validating a domain, enter its name in the Unbound domain-insecure option. This option may be used multiple times for different names. It implies that the chain of trust is not used.
With Unbound, all RRSIG inception and expiration timestamps can be ignored by setting the val-override-date option to "-1". For testing and debugging, that val-override-date option can also be set to a time and date (using the same RRSIG inception and expiration format) to use instead of the system's real time.
Unbound allows some mistakes in RRSIG inception and expiration times. By default, it will allow them to be off by 10-percent. For example, if the difference between the inception and expiration is 30 days, it could allow the inception to be three days earlier or the expiration to be three days later. It has restrictions for these with the Unbound val-sig-skew-min and val-sig-skew-max options, which by default are set to 3600 seconds (one hour) and 86400 seconds (one day), respectively, for the smallest and largest amount of times it may be off. Using the previous example of 3 days, it will be capped to only 86400 seconds, so will allow the inception to be one day earlier or the expiration to be one day later. The minimum skew prevents the 10-percent to be less than one hour (using the default) so always allows at least one hour of fudge time which may be helpful with signers' mistakes with time zones.
To purposely work with short-lived signatures or to be strict on the times, set the Unbound settings very low or to 0 (zero).
PowerDNS Recursor will allow the signature inception to be ahead by 60 seconds by default. This can be adjusted with the signature-inception-skew option.
When a name fails to validate, it is still cached (as bogus) to prevent quickly repeated lookups and validation attempts. Its own TTL is not honored. With Unbound, it will be cached for 60 seconds (as set with the val-bogus-ttl option).
With PowerDNS Recursor it will cache for one hour (as set with its max-cache-bogus-ttl option in seconds).
Nameservers often provide helper or related information as records in the ADDITIONAL section. When returning a successfully validated signed response, Unbound will remove any records in the ADDITIONAL section that are also not properly signed. This feature can be disabled by setting the Unbound val-clean-additional option to no.
To still return answers even when DNSSEC indicates a failure, set the Unbound val-permissive-mode option to yes. It will still do and log the validation. And it will still set the AD bit if is considered secure.
The CD (Checking Disabled) flag is set by clients to tell the validating resolver to not do the DNSSEC validation checks. With Unbound, to ignore the CD flag and still do the checks and refuse to respond with failed answers, set the ignore-cd-flag option to yes. This may be useful for providing DNSSEC for clients that don't do any DNSSEC validation themselves while they still set the CD flag.
Unbound doesn't log about failed validations by default. To enable logging set val-log-level to 1 to show the failed query. Set it to 2 to also log the IP of the remote server that provided the failing data and the reason why it was bad.
The server will need to support the hash algorithm as defined in the NSEC3PARAM record if it is to respond with NSEC3 authenticated denials.
To not disclose existing names in a zone, NSEC3 instead uses hashed names. It can be hashed multiple times (iterations) to reduce chance of dictionary attack (to figure out the original name). The NSEC3 record's third field is the count of additional iterations. This iteration field defines a cost of computing the hash -- a high count causes additional load for the DNSSEC server and validating resolvers.
For example, the NET zone uses 0 (zero) for the NSEC3 iterations, so it is only hashed once.
To prevent expensive computations (which could cause denial of service), the validator has a maximum iterations. If the provides NSEC3 iterations count is too high, then the status becomes Insecure if the NSEC3's signature is validated and then no NSEC3 hashing or further validation is done.
For Unbound, the maximums are defined per key size with the val-nsec3-keysize-iterations option. Its default is "1024 150 2048 500 4096 2500" which is the list of key sizes and maximum iterations; so for key size of 1024 only up to 150 iterations are allowed and key size of 4096 allows up to 2500 iterations. With Unbound, there must be at least one key size and iteration entry. If this is set to "1024 65535" there is no restriction. The key sizes must be defined in ascending order and a long list could cause slow performance.
For PowerDNS Recursor, it will allow up to 2500 NSEC3 iterations (regardless of key size). This maximum can be set using its nsec3-max-iterations option.
Unbound will cache in memory up to 4 Megabytes of keys. To change the amount of memory to use for caching keys, set the Unbound key-cache-size option in bytes (or append "k", "m", or "G" for kilobyte, megabyte, or gigabyte units).
Unbound organizes its memory usage in hash tables called slabs. With multiple processors, this improves performance by limiting how much memory is locked for different uses. The memory cache of keys uses four slabs by default. To change this, set the Unbound key-cache-slabs option to a number with a power of 2. A higher number reduces lock contention. It is recommended to set it to the number of CPU cores on the system.
Unbound can cache in memory about NSEC proofs of absence of types and non-existance so these don't have to be looked up again prior to their TTL timeouts. It will use up to 1 Megabyte of memory for this DNSSEC negative cache. To change this, set the Unbound neg-cache-size option to the number of bytes (or append with the "k", "m", or "G" units) of memory to use.
To disable validation for the Unbound defined local zones (local-zone), set the insecure-lan-zones option to yes. (By default, Unbound defines the in-addr.arpa zones for RFC 1918 local use addressing, so when insecure-lan-zones is enabled, the reverse lookups for these private addresses are not validated.)
Default is disabled. If enabled, then reverse lookups in private address space are not validated. This is usually required whenever unblock-lan-zones is used.
The ed25519 and Ed448 DNSSEC algorithms (15 and 16) may require additional dependency requirements.
PowerDNS Resolver by default doesn't do its own validation, but it will set the DO flag on all outgoing queries and will respond with DNSSEC records when its queries contain the DO flag. This is its "dnssec=process-no-validate" configuration.
To disable DNSSEC by ignoring the DO and AD bits set in the query, set the "dnssec" option to "off". Also outbound queries will not set the DO bit.
The "dnssec=validate" option will validate all queries even when DNSSEC is not requested. It will return a SERVFAIL to the clients for bogus responses.
To have PowerDNS Recursor do normal validation only for queries that have the DO or AD bit set, use the "dnssec=process" option. It will respond with the AD bit for successful validations and respond with SERVFAIL for bogus validations.
The PowerDNS Recursor "dnssec=log-fail" option will also try to validate all responses even when the DO or AD bits in the query aren't set. It will also attempt validation even if the CD bit is set, But it won't response with the AD bit (for success) or SERVFAIL (for Bogus) unless the query asked for the validation (and the CD bit is not set). The validation results will be logged.
By default, DNSSEC validation failures are not logged by the PowerDNS Recursor. To log for bogus validations, set the dnssec-log-bogus=yes option.
PowerDNS Recursor debug tracing will also log about DNSSEC. This is enabled with the "trace" option or enabled per domain using the rec_control tool.
PowerDNS Recursor records various DNSSEC statistics which are available via different mechanisms including rec_control.
The counters include:
Serving DNSSEC is enabled by default for NSD if the zone's SOA record has a corresponding RRSIG signature and the query has the DO bit set. NSD will not set the AD or DO bits on responses (even when signed). If it sees the CD bit set, it will respond with it still set.
NSD doesn't respond with the DNSKEYs in the ADDITIONAL section for NS or SOA queries.
The NSD software doesn't include the key creation nor zone signing tools.
DNSSEC can be abused with DDoS (distributed denial of service) amplification attacks by spoofing small queries that respond with large answers (such as signatures and keys). These can be alleviated by using Response Rate Limiting (RRL) and DNS Cookies.
Gab
Twitter