Implement DNSSEC #65

sstreiner · 2014-04-06T17:24:18Z

Would be a cool feature!

blblack · 2014-04-06T19:12:15Z

Yes, it would!

My feelings on DNSSEC are complicated, but can probably be summed up as: "This thing really sucks, but someday we'll probably be forced to implement it due to widespread adoption, so we may as well get on it sooner rather than later."

Unfortunately DNSSEC makes DNS software a whole lot more complicated than it should have to be and is rife with negative security implications outside of the core security aims of DNSSEC itself (end-to-end (authserver-to-client) authenticity). Patching DNSSEC into gdnsd will be a major undertaking that will affect vast swaths of the code, especially in dnspacket.c and ltree.c. So far the pain:reward ratio hasn't made it favorable for me to divert significant attention from other feature-work and try my hand at it.

Others are welcome to take a stab, although it might be best to use some kind of public branch/fork so we can coordinate the changes a bit. Ideally, the DNSSEC work shouldn't have much negative impact (in terms of security, memory footprint, or performance) on those that choose to disable it. If nobody else does so and DNSSEC continues to slowly gain ground, I'll eventually do it myself, but at this stage that's looking quite far off in the future.

mayasd · 2015-02-03T09:50:19Z

Hi,
Do you think that it is possible that DNSSEC feature is available this year?

blblack · 2015-02-11T18:37:50Z

It's possible, but I wouldn't bet money on it at this time. I haven't even begun to work on it, and it's just not a top priority right now for me.

AnBuKu · 2016-10-09T13:38:36Z

What are the plans of mayor gdnsd users as e.g. Wikimedia Foundation? Maybe a bounty by main users could be some compensation for pain and suffering?

sunnybear · 2017-04-13T11:04:01Z

We will be very glad to hear any news about DNSSEC in gdnsd. Can you please summarize work estimation - in hours - and we will collect the sum by $100 per hour for example?

blblack · 2019-02-11T13:44:32Z

My latest thoughts on all related things are now recorded in the manual in the repo. DNSSEC is probably going to happen (for better or worse!), it's just a question of exactly when and how and priorities, as always!

This is the code's first real foray into DNSSEC support. It's not even remotely close to being complete or correct yet. This is an experiment in how to integrate DNSSEC with the rest of the constraints and structures of this codebase. Bug Ref gdnsd#65 * Online DNSSEC signing for a zone is enabled by adding the statement "$BREAK_MY_ZONE" to the zonefile. * The statement can be repeated multiple times. Each such statement adds a unique random ed25519 ZSK (Zone Signing Key), with the SEP bit set like a Combined setup, to the zone. The keys will be re-created (with new random values) on zone reload or daemon restart/replace. * The zone loading code will create a DNSKEY RRSet at the apex which shows the public keys for all the ZSKs created above, and create RRSIGs which sign all static rrsets (including the generated apex DNSKEY) with all of the ZSKs. * The dnspacket code will emit the created RRSIGs immediately after any real RRSet, if the zone is signed and the query had the DO bit set to indicate client DNSSEC support. Known deficiencies (and really, it's hard to be exhaustive here, much is missing!): * Proper key management is completely ignored at this stage, intentionally. First we need to get the internal parts right, and random ZSKs are enough to work with for now. * The RRSIG dates are fixed at zone load/reload time. The inception date is set to ~1-2 days in the past (round down to nearest day start then subtract one day), and the expiration is set for 4 weeks after the inception. If no zone reload happens before expiry, they'll just become stale/invalid, for now. * There is no attempt yet at any negative proofs; there are no NSEC or NSEC3 records emitted for any cases, even for the simpler cases like NODATA for a missing RR type on a known name. Most likely we'll approach this in a minimal-coverage white and/or black lies sort of way, with NSEC for ENTs and true NODATA pre-generated, and true NXDOMAINs handled dynamically with a smart-ish per-thread cache and a miss ratelimiter. * No support for other DNSSEC-specific types (e.g. DNSKEY, RRSIG, DS, CDNSKEY, CDS, etc) are implemented in the zonefile parser yet, and thus the structural parts of the code also don't deal with the secure delegation of subzones yet, either. We'll probably later implement parsing them all and have real key management be done offline from the runtime and support offline KSKs, etc, hopefully by leveraging some existing key management tools out there to create a zone's DNSKEY RRset and DNSKEY-RRSIG (but not any other RRSIGs or NSEC), and then $BREAK_MY_ZONE would be replaced by some other statement that loads external ZSK privates which match one of the given DNSKEYs * Ephemeral ACME challenge records from gdnsdctl are not signed (but could/should be!) * Dynamic A/AAAA/CNAME from our legacy DYNA/DYNC RRs are not signed, and the code explicitly disallows these types in signed zones because we probably won't implement support for signing these deprecated types. A "better" (FSVO better to some people, as always!) replacement system is due later in 4.x development, which will integrate and have signed responses. * The code is still pretty ugly and poorly-factored, and even the data structure changes are not laid out in a very optimized way. It's likely to undergo a lot more seismic change at this early stage anyways, so there's no point expending too much effort on quality/perf right now. * There is no DNSSEC testsuite support at all yet, and I'm not yet sure which direction we'll go to attach that. This would be a good opportunity to start up some fresh, better testing infra in parallel with the existing tests and then eventually remove the old ugly testsuite. For now, I've very minimally verified that what we have so far appears to work correctly via manual testing with "drill" (using an initial DNSKEY query to fill out a keyfile to anchor checking RRSIG of further queries) Example manual test with "drill": $ cat etc_test/config options => { dns_port => 12345, run_dir => /tmp/gdnsd_tmp } $ cat etc_test/zones/example.com @ 900 SOA ns1 hostmaster 1 7200 30M 3D 900 $BREAK_MY_ZONE ; can be anyhwere in the file @ NS ns1 @ NS ns2 @ MX 0 host100 @ MX 1 host101 ns1 A 192.0.2.1 ns2 A 192.0.2.2 host100 A 192.0.2.100 host101 A 192.0.2.101 foo CNAME www bar SRV 5 500 80 host100 bar SRV 3 300 80 host101 baz TXT "some text data" $ timeout 60 src/gdnsd -c etc_test start & info: gdnsd version 3.99.0 @ pid 255110 info: DNS listener threads (2 UDP + 2 TCP) configured for 0.0.0.0:12345 info: DNS listener threads (2 UDP + 2 TCP) configured for [::]:12345 info: Zone example.com. with serial 1 loaded info: rfc1035: Loaded 1 zonefiles from 'etc_test/zones/' info: Raised open files soft limit to 1148 info: DNS listeners started $ drill -D @127.0.0.1 -p 12345 example.com DNSKEY | tee keyfile |grep ^example example.com. 4321 IN DNSKEY 257 3 15 +X7Ke4702Kh6n/YfvH2ANLVO2VG+fbTKAsMonaUQZvo= ;{id = 5742 (ksk), size = 256b} example.com. 4321 IN RRSIG DNSKEY 15 2 4321 20210204000000 20210107000000 5742 example.com. GSpRP++gLbUAzcgmW5zRzGgB5xdcH05MtiUofFp4hoRWyOlm5MIoUOXx+/YkGgVRkSwvNQQza8hgPhO521vTDQ== $ drill -V 3 -k keyfile -S -D @127.0.0.1 -p 12345 bar.example.com SRV ;; Number of trusted keys: 1 ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 26542 ;; flags: qr aa rd ; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;; bar.example.com. IN SRV ;; ANSWER SECTION: bar.example.com. 86400 IN SRV 3 300 80 host101.example.com. bar.example.com. 86400 IN SRV 5 500 80 host100.example.com. bar.example.com. 86400 IN RRSIG SRV 15 3 86400 20210204000000 20210107000000 5742 example.com. SXGPts0kEZqD77Xyz65i1I1fl8Go7wvatvwroSXYvxc64zDblcbEaC33N4sbLm2bXFGB2MFMQYC+qokokS8tDw== ;; AUTHORITY SECTION: ;; ADDITIONAL SECTION: ;; Query time: 0 msec ;; EDNS: version 0; flags: do ; udp: 1024 ;; SERVER: 127.0.0.1 ;; WHEN: Fri Jan 8 15:40:03 2021 ;; MSG SIZE rcvd: 229 ;; Chasing: bar.example.com. SRV DNSSEC Trust tree: bar.example.com. (SRV) |---example.com. (DNSKEY keytag: 5742 alg: 15 flags: 257) ;; Chase successful

This is experimental prototype code! While a lot of the DNSSEC code here now works correctly as intended AFAICS (RRSIGs, minimal-cover NSEC NODATA, online synthesized NXDOMAINs, secure delegations with parsed DS records, etc!) many other parts are still a Work In Progress. The quick list of key things that are missing: * Key management is non-existent; we autogenerate Combined ZSKs using ED25519 or P256 for testing for now, when a zone contains "$BREAK_MY_ZONE_ED25519" and/or "$BREAK_MY_ZONE_P256". * Zonefile parser doesn't yet support the types needed for key management, either (DNSKEY, RRSIG(DNSKEY), CDNSKEY, CDS, etc). * Wildcards aren't dealt with properly yet * Ephemeral ACME isn't dealt with properly yet * DYN[AC] isn't dealt with (and probably won't be; something better should replace them before this makes it to a release) * Caching+ratelimiting for dynamic online signing cases (e.g. NXDOMAIN, wildcard) isn't done yet * Needs testsuite stuff for DNSSEC in general, and now would be a good time to make a clean break from our old ugly testsuite * DNSSEC code and rrset data structures are ugly; needs refactoring, QA, and optimization work, but I'm waiting till things stabilize a bit and we have a testsuite * Needs a DNSSEC Implementation Notes document to describe our implementation choices and rationales clearly [WIP] Bug Ref gdnsd#65

This is experimental prototype code! A DNSSEC implementation doc is now included as docs/DNSSEC.md, which describes all our implementation decisions and progress status in detail (sometimes a bit too much detail!). While a lot of the DNSSEC code here now works correctly as intended AFAICS (RRSIGs, minimal-cover NSEC NODATA, online synthesized NXDOMAINs, secure delegations with parsed DS records, etc!) many other parts are still a Work In Progress. Both OpenSSL's libcrypto and GnuTLS are build-time options for P256 algorithm support. If neither are present, the server only supports Ed25519 ZSKs via libsodium (which is a hard requirement), and if at least one of them is present, P256 is supported. Autoconf checks for both libraries and and will use them both if available (to provide both deterministic and fast-nondeterministic P256 options). They can be explicitly required or disabled via --(with|without)-(libcrypto|gnutls). A benchmarking tool "gdnsd_dnssec_bench" is provided which reports the signing speeds of the various algorithm/library choices as-built on your own host(s). The quick list of key things that are TODO: * Key management is non-existent; we autogenerate Combined ZSKs using ED25519 or P256 for testing for now, when a zone contains "$BREAK_MY_ZONE_ED25519" and/or "$BREAK_MY_ZONE_P256". * Zonefile parser doesn't yet support the types needed for key management, either (DNSKEY, RRSIG(DNSKEY), CDNSKEY, CDS, etc). * Ephemeral ACME isn't dealt with properly yet * DYN[AC] isn't dealt with (and probably won't be; something better should replace them before this makes it to a release) * NXDOMAIN is our true online-signing case, and while it "works" now, it's too easy to DoS the server CPU this way. Some caching, ratelimiting, etc is in order here! * Needs testsuite stuff for DNSSEC in general, and now would be a good time to make a clean break from our old ugly testsuite * DNSSEC -related changes to rrset data structures are ugly and some of the code needs refactoring, QA, and optimization work, but I'm waiting till things stabilize a bit and we have a testsuite Bug Ref gdnsd#65

This adds caching for synthesized NXDOMAIN responses and a ratelimiter for cache misses to mitigate online-signing CPU impact. Some new stats counters are provided for how the cache and ratelimiter are holding up with the traffic, and there's some new params for tuning all this. This commit also adds explicit NXDOMAIN tombstone RRs to the zone parser. Even in unsigned zones, these can be useful as policy or history communication mechanisms. For signed zones, they create static, pre-signed NXDOMAIN responses at zone load time which are not subject to caching or ratelimiting, for cases where the admin knows that certain NXDOMAIN responses will be common and/or important, e.g. after removing a popular name. Bug Ref gdnsd#65