DNSSEC Testing • NS Testing • DS Testing • Other RR Testing • Other Testing
Note: The details outlined here have been recently migrated to here and whilst I've tried to ensure I've tested everything, I may have missed something.
Please shout if you find anything not as described below, or if you want something added.
This page and domain is used for a variety of tests.
It started out with a bunch of DNSSEC test cases, some broken, some used for testing resolvers, etc.
However, over time, more tests have been added, as noted below.
If you want a particular test created, please let me know.
There are a number of delegations in nsec3.uk, as follows:
Each of the above delegations in turn has three delegations:
There are some more delegations, that have specific test cases applied:
NS Testing
Because the above two have both parent and child on the same NS infrastructure, I wanted to also test whether this breaks in the event that the broken child is a true delegation and not just getting served by a server serving the most specific data it is auth for during recursion.
karld.uk nameservers are in Cloudflare, and mismatchednameservers has proper delegation to ns.junesta.uk and ns.junesta.net.uk. from their nameservers.
The auth NS record data resolves to localhost so if a resolver is using auth data once it's retrieved it from the nameservers in the delegation, future queries should fail.
As above, but the delegation is signed. I wondered whether recursive resolvers would use the auth data when performing validation steps such as fetching the DNSKEY RR set.
This should not validate, and should return a SERVFAIL from a validating resolver that goes away if you repeat with CD set.
Resolvers that support extended DNS errors, should give you something like this:
# dig +dnssec @8.8.8.8 soa broken-ds.nsec3.uk ; <<>> DiG 9.16.33-Debian <<>> +dnssec @8.8.8.8 soa broken-ds.nsec3.uk ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 22836 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 512 ; EDE: 9 (DNSKEY Missing): (No DNSKEY matches DS RRs of broken-ds.nsec3.uk) ;; QUESTION SECTION: ;broken-ds.nsec3.uk. IN SOA ;; Query time: 52 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Thu Aug 03 20:21:57 UTC 2023 ;; MSG SIZE rcvd: 99
dnssec-policy normal {
dnskey-ttl PT1H;
keys {
ksk lifetime unlimited algorithm ecdsa384;
zsk lifetime 90D algorithm ecdsa384;
};
max-zone-ttl P1D;
parent-ds-ttl P1D;
parent-propagation-delay PT1H;
parent-registration-delay P1D;
publish-safety PT1H;
retire-safety PT1H;
signatures-refresh P5D;
signatures-validity P2W;
signatures-validity-dnskey P2W;
zone-propagation-delay PT5M;
};
The policy is then applied as follows (it's practically the same for static config):
rndc showzone auto-rolling-zsk.nsec3.uk
zone "auto-rolling-zsk.nsec3.uk" { type master; file "zones/auto-rolling-zsk.nsec3.uk"; dnssec-policy "normal"; inline-signing yes; };
Below alg-8, there are delegations for testing DS algorithms, so ds-alg-4.alg-8.nsec3.uk is signed with RSASHA256 and has a SHA-384 DS in the alg-8.nsec3.uk parent.
Currently configured:
The zone is signed, but the parent (unsigned.nsec3.uk) isn't. There's no DS in the unsigned parent.
There are some records of the form n.ttl.nsec3.uk where n is an integer and the TTL is set to that value.
They're there to aid testing of resolvers that may cap very low or very high values.
There are also non integer CNAME entries for things like 1w, 7d, etc
From the outset, values are:
$ORIGIN ttl 0 0 TXT "zero seconds" 1 1 TXT "one second" 2 2 TXT "2 seconds" 5 5 TXT "5 seconds" 10 10 TXT "10 seconds" 30 30 TXT "30 seconds" 60 60 TXT "60 seconds" 120 120 TXT "2 minutes" 180 180 TXT "3 minutes" 300 300 TXT "5 minutes" 600 600 TXT "10 minutes" 900 900 TXT "15 minutes" 14400 14400 TXT "4 hours" 86400 86400 TXT "24 hours" 172800 172800 TXT "2 days" 259200 259200 TXT "3 days" 604800 604800 TXT "7 days" 1209600 1209600 TXT "14 days" 2419200 2419200 TXT "28 days" 1m CNAME 60 2m CNAME 120 3m CNAME 180 5m CNAME 300 10m CNAME 600 15m CNAME 900 4h CNAME 14400 1d CNAME 86400 24h CNAME 86400 2d CNAME 172800 48h CNAME 172800 1w CNAME 604800 7d CNAME 604800 2w CNAME 1209600 14d CNAME 1209600 4w CNAME 2419200 28d CNAME 2419200If you want a value that's not listed, gimme a shout.