| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| dns:dnssec [2025/01/19 10:09] – [Disabling DNSSEC] bstafford | dns:dnssec [2025/05/09 13:18] (current) – [Internal DNSSEC] bstafford |
|---|
| <code>{ echo -en '\x00\x01\x01\x03\x08'; echo ‘put_the_public_ksk_here' | openssl base64 -d; } | openssl sha256</code> | <code>{ echo -en '\x00\x01\x01\x03\x08'; echo ‘put_the_public_ksk_here' | openssl base64 -d; } | openssl sha256</code> |
| ===== DNSSEC Flags ===== | ===== DNSSEC Flags ===== |
| Flags in DNS Query Packets | 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. | * **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. | * **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. | * **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. |
| |
| ===== Internal DNSSEC ===== | ===== 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. | 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. |
| |
