Differences

This shows you the differences between two versions of the page.

--- dns:dnssec [2025/01/13 12:05] – [DNSSEC and Forwarding] bstafford
+++ dns:dnssec [2025/05/09 13:18] (current) – [Internal DNSSEC] bstafford
@@ Line 40: / Line 40: @@
 From [[https://wander.science/projects/dns/dnssec-resolver-test/|this site]].
-The following query will only return an IP if DNSSEC validation is turned off. If DNSSEC validation is turned on, the resolver will realise that teh record did not pass validation.
+The following query will only return an IP if DNSSEC validation is turned off. If DNSSEC validation is turned on, the resolver will realize that the record did not pass validation.
 <code>dig @192.168.12.222 +short sigfail.ippacket.stream</code>
 The following record should work regardless of wether or not DNSSEC validation is enabled because it is correctly DNSSEC signed.
@@ Line 88: / Line 88: @@
 When we paste the following into a shell, we get the desired result:
 <code>{ echo -en '\x00\x01\x01\x03\x08'; echo ‘put_the_public_ksk_here' | openssl base64 -d; } | openssl sha256</code>
+===== DNSSEC Flags =====
+Flags in DNS Query Packets ([[https://learn.microsoft.com/en-us/windows-server/networking/dns/validate-dnssec-responses|from Microsoft's page]])
+  * **DO**: The DO bit is included in a DNS query and is an abbreviation for "**DNSSEC OK**". If the DO bit is set (DO=1), then the client is **DNSSEC-aware**, and it's safe for the DNS server to return DNSSEC data in a response. If the DO bit isn't set (DO=0), then the client isn't DNSSEC-aware, and the DNS server can't include any DNSSEC data in a DNS response. DNS clients can still be protected using DNSSEC even if they're not DNSSEC-aware. In this context, a DNS client is any computer that sends a DNS query. When a recursive DNS server sends a query to the authoritative DNS server, the recursive DNS server must indicate that it's DNSSEC-aware so that the authoritative DNS server sends DNSSEC data in the response.
+  * **AD**: The AD bit is included in a DNS response and is an abbreviation for "**authenticated data**". If the AD bit is set (AD=1), then it means the DNS response is authentic because it was validated using DNSSEC. A nonvalidating DNSSEC-aware computer, such as one running Windows 8, doesn't perform DNSSEC validation but can be configured to require that DNS responses are authentic. If the AD bit isn't set (AD=0), the DNS response wasn't validated. The AD bit might not be set either because validation wasn't attempted, or because validation failed.
+  * **CD**: The CD bit is included in a DNS query and is an abbreviation for "**checking disabled**". If the CD bit is set (CD=1) in a query, then it means a DNS response should be sent whether or not validation was successfully performed. If the CD bit isn't set (CD=0), then a DNS response isn't be sent if validation was required and failed. If the CD bit is clear (CD=0), this means "checking enabled" and DNSSEC validation can occur. The CD bit might be set (CD=1) in a query because the host is capable of performing DNSSEC validation, such as a recursive DNS server running Windows Server 2012 or later. A nonvalidating stub resolver, such as a computer running Windows DNS client is always set CD=0.
+  * **AA**: A fourth important flag (bit) that can be present in a DNS packet header is the AA bit. This flag isn't new with DNSSEC, but it can be used when DNSSEC is deployed. The AA bit is included in a DNS response and is an abbreviation for "**authoritative answer**". If the AA bit is set, it means that the DNS response is authentic because it came directly from an authoritative DNS server. A client that requires DNSSEC validation (AD=1) accepts the AA bit instead (AA=1, AD=0). If the client directly queries an authoritative server because authoritative responses don't need to be validated. It would be redundant for an authoritative server to validate its own response.
 ===== Disabling DNSSEC =====
 Remove the DS records at the parent (via registrar)
@@ Line 98: / Line 106: @@
 ===== Internal DNSSEC =====
+[[https://csrc.nist.gov/pubs/sp/800/81/r3/ipd|NIST SP-800-81r3]] and [[https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-81r3.ipd.pdf|PDF]]. DNSSEC for Internal zones is covered in section 3.8.5.
 Internal domains should not be DNSSEC signed. If they are truly internal domains, connecting into the chain of trust would be challenging if not impossible. However, there is another concern if the internal domains are receiving DDNS updates, then they will constantly need to re-sign the domain, which could end up being a major performance impact. DNSSEC validation is done by DNS servers, not clients, so if the clients are going to be querying servers that have the authoritative data, there is absolutely nothing to validate.