Bug #45629 for bind9-public: when update add CDS is REFUSED

I've been trying to get a test setup for CDS/CDNSKEY and I've hit a snag... I think (after the investigation below) this is a documentation bug - the ARM should have a section on what you can't do with inline-signing zones that you can do with UPDATE on non-inline signed zones. I'm not entirely sure what those things are - I guess most of section 4.9 of the ARM? Instead you have to use dnssec-settime to configure the signer and rndc for more fancy stuff (such as reloading keys, NSEC3 wrangling). Except that you can still use `update del dnskey` to go insecure. Confusing. I have a signed zone... 2017-07-27.17:30:15.053 general: info: received control channel command 'sign fanf2.ucam.org in auth' 2017-07-27.17:30:15.053 general: info: zone fanf2.ucam.org/IN/auth (signed): reconfiguring zone keys 2017-07-27.17:30:15.070 general: info: zone fanf2.ucam.org/IN/auth (signed): next key event: 27-Jul-2017 18:30:15.053 I try adding a CDS record... 2017-07-27.17:30:24.315 update-security: info: client @0x7f824c136f10 127.0.0.1#7551/key local-ddns: view auth: update 'fanf2.ucam.org/IN' signer "local-ddns" allowed by ACL 2017-07-27.17:30:24.315 update: info: client @0x7f824c136f10 127.0.0.1#7551/key local-ddns: view auth: updating zone 'fanf2.ucam.org/IN': adding an RR at 'fanf2.ucam.org' CDS 15364 5 2 72675A4FFAD8BA229507BF48544E292CB04FCBEC1797A387B8B42B0A 18934AF7 2017-07-27.17:30:24.315 general: info: zone fanf2.ucam.org/IN/auth (unsigned): fanf no DNSKEY 2017-07-27.17:30:24.315 update: info: client @0x7f824c136f10 127.0.0.1#7551/key local-ddns: view auth: updating zone 'fanf2.ucam.org/IN': update rejected: bad CDS RRset OK, something weird is going on. I added some debug logging (see below), which is where the "fanf" log line came from. Somehow it thinks the zone is unsigned? Ah, but it's an inline-signing zone, and in ns_update_start() there's a comment: /* * If there is a raw (unsigned) zone associated with this * zone then it processes the UPDATE request. */ which I think means most of the dnssec-update-related functionality will be weirdly broken. For example, try adding a DNSKEY record and get a SERVFAIL because: 2017-07-27.17:53:25.055 update: info: client @0x7f2c38161f60 127.0.0.1#11635/key local-ddns: view auth: updating zone 'fanf2.ucam.org/IN': adding an RR at 'fanf2.ucam.org' DNSKEY 257 3 5 [snip] 2017-07-27.17:53:25.055 general: warning: dns_dnssec_findzonekeys2: error reading (null)/Kfanf2.ucam.org.+005+15364.private: file not found 2017-07-27.17:53:25.055 update: error: client @0x7f2c38161f60 127.0.0.1#11635/key local-ddns: view auth: updating zone 'fanf2.ucam.org/IN': found no active private keys, unable to generate any signatures 2017-07-27.17:53:25.055 update: error: client @0x7f2c38161f60 127.0.0.1#11635/key local-ddns: view auth: updating zone 'fanf2.ucam.org/IN': RRSIG/NSEC/NSEC3 update failed: not found Why is the key directory null? Well, looks like in zoneconf.c the setting isn't copied to the raw version of the zone. --- a/lib/dns/zone.c +++ b/lib/dns/zone.c @@ -17915,6 +17915,7 @@ dns_zone_cdscheck(dns_zone_t *zone, dns_db_t *db, dns_dbversion_t *version) { result = dns_db_findrdataset(db, node, version, dns_rdatatype_dnskey, dns_rdatatype_none, 0, &dnskey, NULL); if (result == ISC_R_NOTFOUND) { + dns_zone_log(zone, ISC_LOG_INFO, "fanf no DNSKEY"); if (dns_rdataset_isassociated(&cds)) result = DNS_R_BADCDS; else Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ - I xn--zr8h punycode Tyne, Dogger: South 4 or 5, veering southwest 5 or 6. Slight or moderate. Thundery showers. Mainly good.

---

With inline signing DNSSEC records (other than DS) are modified by other paths than using UPDATE. I would be using these mechanisms instead of UPDATE even with normal signed zones. dnssec-settime and dnssec-keygen -P sync date/offset Sets the date on which CDS and CDNSKEY records that match this key are to be published to the zone. -D sync date/offset Sets the date on which the CDS and CDNSKEY records that match this key are to be deleted. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

---

Mark Andrews via RT <bind9-public@isc.org> wrote: > > With inline signing DNSSEC records (other than DS) are modified by > other paths than using UPDATE. I would be using these mechanisms > instead of UPDATE even with normal signed zones. Yes, I'm aware of those mechanisms. But for quick fiddling, and for testing broken CDS RRsets, I hoped I could use UPDATE. I think something the patch below would have helped avoid confusion. (Is this the right test for the security status of a zone?) --- bin/named/update.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/bin/named/update.c b/bin/named/update.c index cd62c5d..5023dff 100644 --- a/bin/named/update.c +++ b/bin/named/update.c @@ -3100,9 +3100,14 @@ update_action(isc_task_t *task, isc_event_t *event) { if (! ISC_LIST_EMPTY(diff.tuples)) { result = dns_zone_cdscheck(zone, db, ver); if (result == DNS_R_BADCDS || result == DNS_R_BADCDNSKEY) { + isc_boolean_t secure = + dns_zone_getkeyopts(zone) & + (DNS_ZONEKEY_ALLOW|DNS_ZONEKEY_MAINTAIN); update_log(client, zone, LOGLEVEL_PROTOCOL, - "update rejected: bad %s RRset", - result == DNS_R_BADCDS ? "CDS" : "CDNSKEY"); + "update rejected: bad %s RRset%s", + result == DNS_R_BADCDS ? "CDS" : "CDNSKEY", + !secure ? " (zone is unsigned" + " or inline-signing)" : ""); result = DNS_R_REFUSED; goto failure; } -- 2.10.1.445.g3cdd5d1

---