Differences

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

--- dns:dnssec [2024/04/24 07:52] – [Test DNS Resolver] bstafford
+++ dns:dnssec [2025/05/09 13:18] (current) – [Internal DNSSEC] bstafford
@@ Line 1: / Line 1: @@
 ====== DNSSEC ======
+===== Test Sites =====
+Sites With Good DNSSEC Signatures
+  * internetsociety.org
+  * dnssec-tools.org
+  * dnssec-deployment.org
+  * sigok.ippacket.stream [[https://wander.science/projects/dns/dnssec-resolver-test/|as per this page]]
+If you are testing web validation, the addresses are:
+  * http://www.internetsociety.org/
+  * http://www.dnssec-tools.org/
+  * http://www.dnssec-deployment.org/
+Sites With Bad DNSSEC Signatures
+  * dnssec-failed.org   (operated by Comcast)
+  * rhybar.cz        (operated by cz.nic)
+  * sigfail.ippacket.stream [[https://wander.science/projects/dns/dnssec-resolver-test/|as per this page]]
+On the web, they are:
+  * http://www.dnssec-failed.org/
+  * http://www.rhybar.cz/
+===== DNSSEC =====
 When in doubt, set ZSK to 1 month lifespan, KSK to 1 year lifespan, Algorithm to RSA-SHA-256
@@ Line 14: / 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 33: / Line 59: @@
   * 8: Algorithm. 8 = RSA/SHA-256
   * AwEAAd7…; Public key
+===== Validate Root Key =====
+IANA has the DS Digest of the root [[http://data.iana.org/root-anchors/root-anchors.xml|key here]] (main page [[https://www.iana.org/dnssec/files|here]]
+Validate the KSK you got from dig with the following command:
+<code>{ echo -en '\x00\x01\x01\x03\x08'; echo ‘put_the_public_ksk_here' | openssl base64 -d; } | openssl sha256</code>
+The output should match one of the digests given by IANA.
+Explanation from [[https://security.stackexchange.com/questions/269116/how-can-i-validate-the-root-dns-key-signing-key-on-the-command-line|here]].
+We have to concatenate the following data:
+  * \x00: the wire format of the root zone
+  * \x01\x01: 257 in the flags field (KSK)
+  * \x03: 3 in the protocol field
+  * \x08: 8 in the algorithm field (RSA/SHA-256)
+  * the public key (remove the white space that the dig commands into the returned KSK)
+The [[http://data.iana.org/root-anchors/root-anchors.xml|root-anchors.xml]] lists 2 as the digest type for the key with the id/tag 20326:
+<code><KeyDigest id="Klajeyz" validFrom="2017-02-02T00:00:00+00:00">
+  <KeyTag>20326</KeyTag>
+  <Algorithm>8</Algorithm>
+  <DigestType>2</DigestType>
+  <Digest>E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D</Digest>
+</KeyDigest></code>
+According to this list, this means that we have to hash the above data with SHA-256.
+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 43: / 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.
@@ Line 51: / Line 116: @@
 Even if they only sign the external copy, if they enabled validation (depending on how many caching/recursive layers) they may end up with servfail’s on the internal names even if the auth data is on the caching appliance the client is querying.
+===== DNSSEC and Forwarding  =====
+[[infoblox_nios:forwarding#dnssec|Notes on DNSSEC validation]] when forwarding from one NIOS box to another DNS server.