DNSSEC and DoH with BIND9

--- tags: ns-3 --- # DNSSEC and DoH with BIND9 *[DDNS]: Dynamic DNS *[DoH]: DNS-over-HTTPS *[DoT]: DNS-over-TLS *[DNSSEC]: DNS Security Extensions *[DANE]: DNS-based Authentication of Named Entities *[CAA]: Certification Authority Authorization *[PKC]: Public Key Cryptography *[PKI]: Public Key Infrastructure *[ECC]: Elliptic Curve Cryptography *[TLD]: Top Level Domain *[FQDN]: Fully Qualified Domain Name *[DER]: Distinguished Encoding Rules *[PEM]: Privacy Enhanced Mail *[GPG]: GNU Privacy Guard *[GnuPG]: GNU Privacy Guard *[PGP]: Pretty Good Privacy *[Tor]: The Onion Router *[CA]: Certificate Authority *[RA]: Registration Authority *[VA]: Validation Authority *[ACME]: Automated Certificate Management Environment *[LDAP]: Lightweight Directory Access Protocol *[SSL]: Secure Socket Layer *[TLS]: Transport Layer Security *[AAA]: Authentication, Authorization, and Accounting *[ISC]: Internet Systems Consortium *[TLD]: Top Level Domain *[DoS]: Denial of Service :::warning SSL and TLS are used interchangeably throughout this document. Both SSL and TLS refer to TLS in the strict sense. ::: Any sensible web server administrator knows that one should prove the integrity of one's site by providing a certificate issued by a CA; Let's Encrypt provides a free and easy way to do this. Any sensible browser knows to request the certificate (upon visiting a site) and check it against a chain of CA public keys. However, such prudence has been lacking when it comes to DNS. DNS servers don't prove their integrity, nor do DNS clients request any proof of the integrity of the DNS servers they are interacting with. To sort out this issue of trust in DNS, DNSSEC was invented, yet the adoption of DNSSEC remains poor after a decade has passed since its inception. Secondly, DNS traffic is in plaintext. This issue is addressed by DoT and DoH, which encrypt DNS traffic. DoH has an edge over DoT due to covertness. To elaborate, DoH is in fact HTTPS traffic, while DoT is still UDP and uses a dedicated service port. --- [TOC] --- ## DNS A famous distributed system from the early days of Internet. DNS is short for Domain Name System. DNS provides alphanumeric names for the otherwise purely numeric IPv4 and IPv6 addresses, i.e., DNS is a database of alternative names for IP addresses. From an architectural perspective, DNS is 1. an archetype of distributed system (like Git), and 2. an archetype of database (like MySQL). As a distributed database, DNS is much like Git. What concerns a distributed database are these questions: 1. What data are stored by DNS? 2. In what format are the data stored? 3. How are data distributed among nodes? 4. What is the syntax of a query or a reply? 5. How is the query carried out? Regarding security: 1. How is the integrity of the data guaranteed? 2. Is traffic encrypted? If so, how? 3. How robust is DNS against DoS attacks? We might still ask: 1. Hw can we take advantage of the omnipresence of DNS to do something else? - [What is DNS?](https://www.cloudflare.com/learning/dns/what-is-dns/) -- CloudFlare :::info The purpose of DNS is to translate strings called *domain names* to IP addresses (either IPv4 or IPv6). ::: ### A and AAAA Records DNS is a huge system of records, two of which are most fundamental: 1. *A* record: a pair of domain name and IPv4 address. 2. AAAA record: a pair of domain name and IPv6 address. A client sends a query of the domain name to be translated, and a DNS server replies the address paired with the query according to some A record or AAAA record. ## DNSSEC :::info DNSSEC protects the integrity of information stored in DNS. However, DNSSEC doesn't perform encryption. DNSSEC is to DNS zone files what PGP is to emails what CA certificates are to domain names. ::: - [Experts: DNSSEC protocol can't be worse than certificate authorities](https://searchsecurity.techtarget.com/news/4500257695/Experts-DNSSEC-protocol-cant-be-worse-than-certificate-authorities) - [How DNSSEC Works](https://www.cloudflare.com/dns/dnssec/how-dnssec-works/) -- CloudFlare - [How to use DNSSEC to keep PKI on a leash](https://atlarge.icann.org/files/38145/presentation-dnssec-pki-10apr13-en.pdf) - [Self-signed Certificate Recipe](https://dnsinstitute.com/documentation/dnssec-guide/ch07s05.html) - [A Best Practices Architecture for DNSSEC](https://www.infoblox.com/wp-content/uploads/2016/04/infoblox-whitepaper-dnssec-best-practices-architecture_0.pdf) -- InfoBlox Besides signing zone files to prove integrity of the DNS records, the DNSSEC standard introduced new DNS records and related semantics to support hosting a CA in DNS. This practice is much cheaper and conceptually more reliable than the traditional approach. Note that a service like Let's Encrypt only provides a certificate for a particular domain but doesn't grant one the ability to become a CA. To become a CA without going the DNSSEC path is extremely costly, and a self-signed CA runs into the huge pain of having to distribute the CA certificate. The 200 or so CA certificates (that are considered universally reputable for the time being) are installed in each system by the OS base package maintainers. A self-signed CA certificate doesn't receive partiality of this sort or anything remotely close, making the distribution of self-signed CA certificates very painful! Really, the pain cannot be overstated! - Vanilla DNSSEC secures DNS records. - [DANE](https://wiki.archlinux.org/title/DANE) supports TLS public key validation. - [SSHFP](https://cloud.google.com/dns/docs/dnssec-advanced#sshfp) supports SSH signature validation. - CAA supports CA certificates. - IPSECKEY supports IPSEC. ## Custom TLD for Private Network It is most recommended to use a publicly accepted TLD. However, the small office routers that I came across used `.lan`. The Fedora installer assumes `.localdomain`. Appendix G of rfc6762 contains some more. However, what does Google or Amazon uses internally? [This](https://serverfault.com/a/1041148) SE post indicates `.internal`; I will follow suit.