Sites With Good DNSSEC Signatures

• internetsociety.org
• dnssec-tools.org
• dnssec-deployment.org
• sigok.ippacket.stream 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 as per this page

On the web, they are:

• http://www.dnssec-failed.org/
• http://www.rhybar.cz/

When in doubt, set ZSK to 1 month lifespan, KSK to 1 year lifespan, Algorithm to RSA-SHA-256

• 256 = ZSK
• 257 = KSK

Root cert “.” - RSA/SHA-256 (8). You want KSK (type 257). In NIOS, DON'T FORGET TO SET THE ALGORITHM CORRECTLY.

AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3+/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kvArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+eoZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfdRUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwNR1AkUTV74bU=

You can test a DNS resolver to see if it is enforcing DNSSEC validation.

From 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 realize that the record did not pass validation.

dig @192.168.12.222 +short sigfail.ippacket.stream

The following record should work regardless of wether or not DNSSEC validation is enabled because it is correctly DNSSEC signed.

dig @192.168.12.222 +short sigok.ippacket.stream

dig +nocomments +nostats +nocmd +noquestion -t dnskey .

You will get something like this but you will find some whitespace added to the keys that you have to remove (example below has it shown)

.                       62739   IN      DNSKEY  257 3 8 AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3 +/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kv ArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF 0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+e oZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfd RUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwN R1AkUTV74bU=
.                       62739   IN      DNSKEY  256 3 8 AwEAAbF1LAxEQPtClEQno48k6u7JjCOfVfwdENOxQUrX0JbpN5DnKGMA KIfdiWa5oDeKQ3OoQ58yCC8vjtaaGFDgpJxoLwqzhBYHPGFgins5HIER cCQPGAJKWu/ku4XLh+Fu7UyBubDCelxKTbnj26EwbochltRqGIE8hbwS XEzRNo4g+NXkaRMq2FFbaBtEE82yTmZUgFRYAFUvfGTPWblyZGtkepVu HyNb0w/u24dpsz+uyCZZR04cHfRrWOKvqD3lDOwC4+sqd6f7F841R0N2 tqSh/WDUZzWdvPBaBOz0FWFLb9porIeZ3Jm08tAMHa+3SGRXfK4RAmxV CmIQQypGabE=
.                       62739   IN      DNSKEY  256 3 8 AwEAAcVnO2jZFx4756Rb/yAhJnsl72eemsObU43nclmXwqdJlp+kC5WQ jGYkqLT5xkaUCPhkr4NKLLrIBZXeSGazc6gx/yrrMtUpXcQvax6kfDJP Tu974OmeEbtjyyP7ZG5tUfSwNWt/4EuxDNmZTESG8jU0ZLjYIB11pK0g SXQbMVPyIyGtFGHMPx6UxWn6zUzpECWRFbqEvkA6Y13zeJ1jG2Rki/zs 7a/o13FTl/kI9013Eh6l6Kc2zxbc14GS8fpM0/xQIrZZyeiXj/2C4Rcs PeqWuNj9m0qSQrbrCZtLHb20U8x1uue4iwSX9y7LpwZd6vjYd1d6dgBa 1Xxgc/TC+m8=

Remember,

• 256 or 257: Flags that mean the DNSKEY is a ZSK (256) or a KSK (257)
• 3: The protocol that must be equal to 3
• 8: Algorithm. 8 = RSA/SHA-256
• AwEAAd7…; Public key

IANA has the DS Digest of the root key here (main page here

Validate the KSK you got from dig with the following command:

{ echo -en '\x00\x01\x01\x03\x08'; echo ‘put_the_public_ksk_here' | openssl base64 -d; } | openssl sha256

The output should match one of the digests given by IANA.

Explanation from 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 root-anchors.xml lists 2 as the digest type for the key with the id/tag 20326:

<KeyDigest id="Klajeyz" validFrom="2017-02-02T00:00:00+00:00">
  <KeyTag>20326</KeyTag>
  <Algorithm>8</Algorithm>
  <DigestType>2</DigestType>
  <Digest>E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D</Digest>
</KeyDigest>

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:

{ echo -en '\x00\x01\x01\x03\x08'; echo ‘put_the_public_ksk_here' | openssl base64 -d; } | openssl sha256

Flags in DNS Query Packets (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.

Remove the DS records at the parent (via registrar)

Then wait until DS is no longer being published by parent nameserver. Wait, wait, wait. Maybe a week. Take TTL into account.

Once all TTL have expired, no one should try to validate the zone any more.

Only at that moment it is safe for you to stop unsigning it, which means stop publishing DNSKEY, RRSIG and NSEC/NSEC3 records.

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.

DNSSEC for internal authoritative domains. Generally avoid it, it can be more hassle than it’s worth. The internal domain either needs to be a real fully resolvable from root domain or you have to make sure that any internal resolvers doing validation have a copy of the KSK. And if you are doing any DDNS then definitely avoid as it will need to constantly churn the signatures and NSEC records.

Also, to do it properly, you’ll have to split off internal recursive and internal authoritative into two servers. Most people combine internal recursive and internal authoritative on the same server(s) for practical reasons. But in DNSSEC, you cannot vouch for yourself. So the internal authoritative cannot return its own AD flag.

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.

Notes on DNSSEC validation when forwarding from one NIOS box to another DNS server.