GitLab

Summary

At startup, when requests done by managed-keys-zone are issued, they could fall back to no EDNS and induce key invalidation. Bind version : 9.11.3

Steps to reproduce

Bind with stock conf (dnssec-validation auto) Kill the internet access of the computer, start bind, wait a few seconds (~5-6s), re-enable the Internet access.

What is the current bug behavior?

root key are invalidated, all requests fails

What is the expected correct behavior?

Bind must not in this case/context fallback to no EDNS and must retry the requests to get the "." DNSKEY with EDNS. If the request completely fail (validation timeout because of no connectivity at all during the validation), and the data in the managed-keys-zone still valids, they should be used and revalidatio/refresh attempted later as usual.

Relevant logs and/or screenshots

When ip connectivity is ok before bind statup:

* Aug 23 12:47:52 named[3075]: configuring command channel from '/etc/bind/rndc.key'
* Aug 23 12:47:52 named[3075]: command channel listening on 127.0.0.1#953
* Aug 23 12:47:52 named[3075]: managed-keys-zone: journal file is out of date: removing journal file
* Aug 23 12:47:52 named[3075]: managed-keys-zone: loaded serial 34558
* Aug 23 12:47:52 named[3075]: zone 0.in-addr.arpa/IN: loaded serial 1
* Aug 23 12:47:52 named[3075]: zone 127.in-addr.arpa/IN: loaded serial 1
* Aug 23 12:47:52 named[3075]: zone 255.in-addr.arpa/IN: loaded serial 1
* Aug 23 12:47:52 named[3075]: zone localhost/IN: loaded serial 2
* Aug 23 12:47:52 named[3075]: all zones loaded
* Aug 23 12:47:52 named[3075]: running
* Aug 23 12:47:52 systemd[1]: Started BIND Domain Name Server.
* Aug 23 12:47:53 named[3075]: managed-keys-zone: Key 19036 for zone . acceptance timer complete: key now trusted
* Aug 23 12:47:53 named[3075]: managed-keys-zone: Key 20326 for zone . acceptance timer complete: key now trusted
* Aug 23 12:47:53 named[3075]: resolver priming query complete

When ip connectivity take time to establish after bind startup:

* Aug 23 14:27:56 named[2731]: configuring command channel from '/etc/bind/rndc.key'
* Aug 23 14:27:56 named[2731]: command channel listening on 127.0.0.1#953
* Aug 23 14:27:56 named[2731]: managed-keys-zone: journal file is out of date: removing journal file
* Aug 23 14:27:56 named[2731]: managed-keys-zone: loaded serial 34560
* Aug 23 14:27:56 named[2731]: zone 255.in-addr.arpa/IN: loaded serial 1
* Aug 23 14:27:56 named[2731]: zone localhost/IN: loaded serial 2
* Aug 23 14:27:56 named[2731]: zone 0.in-addr.arpa/IN: loaded serial 1
* Aug 23 14:27:56 named[2731]: zone 127.in-addr.arpa/IN: loaded serial 1
* Aug 23 14:27:56 named[2731]: all zones loaded
* Aug 23 14:27:56 named[2731]: running
* Aug 23 14:27:56 systemd[1]: Started BIND Domain Name Server.
* Aug 23 14:27:56 systemd[1]: Reached target Host and Network Name Lookups.
* Aug 23 14:27:56 systemd[1]: Starting LSB: LDAP connection daemon...
* Aug 23 14:27:56 nslcd[2747]:  * Starting LDAP connection daemon nslcd
* Aug 23 14:27:56 instsvcdrv[1929]: Starting ipmi driver:
* Aug 23 14:27:56 nslcd[2772]: version 0.9.9 starting
* Aug 23 14:27:56 instsvcdrv[1929]:  * Already started
* Aug 23 14:27:56 systemd[1]: Started LSB: Systems Management Device Drivers.
* Aug 23 14:27:56 dataeng[1590]: Starting instsvcdrv (via systemctl): instsvcdrv.service.
* Aug 23 14:27:56 dataeng[1590]: Starting Systems Management Data Engine:
* Aug 23 14:27:59 kernel: [   52.798786] tg3 0000:04:00.2 p3p3: Link is up at 1000 Mbps, full duplex
* Aug 23 14:27:59 kernel: [   52.798802] tg3 0000:04:00.2 p3p3: Flow control is on for TX and on for RX
* Aug 23 14:27:59 kernel: [   52.798807] tg3 0000:04:00.2 p3p3: EEE is disabled
* Aug 23 14:27:59 kernel: [   52.799389] tg3 0000:01:00.1 em2: Link is up at 1000 Mbps, full duplex
* Aug 23 14:27:59 kernel: [   52.799395] tg3 0000:01:00.1 em2: Flow control is on for TX and on for RX
* Aug 23 14:27:59 kernel: [   52.799399] tg3 0000:01:00.1 em2: EEE is disabled
* Aug 23 14:27:59 kernel: [   52.892053] bond1: link status up for interface em2, enabling it in 0 ms
* Aug 23 14:27:59 kernel: [   52.892056] bond1: link status up for interface p3p3, enabling it in 2000 ms
* Aug 23 14:27:59 kernel: [   52.892089] bond1: link status definitely up for interface em2, 1000 Mbps full duplex
* Aug 23 14:27:59 kernel: [   52.892092] bond1: making interface em2 the new active one
* Aug 23 14:27:59 kernel: [   52.892160] bond1: first active interface up!
* Aug 23 14:27:59 kernel: [   53.115431] tg3 0000:01:00.0 em1: Link is up at 1000 Mbps, full duplex
* Aug 23 14:27:59 kernel: [   53.115444] tg3 0000:01:00.0 em1: Flow control is on for TX and on for RX
* Aug 23 14:27:59 kernel: [   53.115448] tg3 0000:01:00.0 em1: EEE is disabled
* Aug 23 14:27:59 kernel: [   53.120049] bond0: link status up for interface em1, enabling it in 0 ms
* Aug 23 14:27:59 kernel: [   53.120080] bond0: link status definitely up for interface em1, 1000 Mbps full duplex
* Aug 23 14:27:59 kernel: [   53.120082] bond0: making interface em1 the new active one
* Aug 23 14:27:59 kernel: [   53.120146] bond0: first active interface up!
* Aug 23 14:27:59 kernel: [   53.134289] tg3 0000:04:00.3 p3p4: Link is up at 1000 Mbps, full duplex
* Aug 23 14:27:59 kernel: [   53.134304] tg3 0000:04:00.3 p3p4: Flow control is on for TX and on for RX
* Aug 23 14:27:59 kernel: [   53.134309] tg3 0000:04:00.3 p3p4: EEE is disabled
* Aug 23 14:27:59 kernel: [   53.224049] bond0: link status up for interface p3p4, enabling it in 2000 ms
* Aug 23 14:28:01 kernel: [   54.972078] bond1: link status definitely up for interface p3p3, 1000 Mbps full duplex
* Aug 23 14:28:01 nslcd[2772]: accepting connections
* Aug 23 14:28:01 nslcd[2747]:    ...done.
* Aug 23 14:28:01 systemd[1]: Started LSB: LDAP connection daemon.
* Aug 23 14:28:01 systemd[1]: Started Regular background program processing daemon.
* Aug 23 14:28:01 cron[2836]: (CRON) INFO (pidfile fd = 3)
* Aug 23 14:28:01 cron[2836]: (CRON) INFO (Running @reboot jobs)
* Aug 23 14:28:01 kernel: [   55.304084] bond0: link status definitely up for interface p3p4, 1000 Mbps full duplex
* Aug 23 14:28:02 named[2731]: validating ./NS: got insecure response; parent indicates it should be secure
* Aug 23 14:28:02 named[2731]: insecurity proof failed resolving './NS/IN': 192.58.128.30#53
* Aug 23 14:28:02 named[2731]: success resolving './DNSKEY' (in '.'?) after disabling EDNS
* Aug 23 14:28:02 named[2731]: managed-keys-zone: No DNSKEY RRSIGs found for '.': success
* Aug 23 14:28:02 named[2731]: validating ./NS: no valid signature found
* Aug 23 14:28:02 named[2731]: no valid RRSIG resolving './NS/IN': 198.41.0.4#53
* Aug 23 14:28:02 named[2731]: validating ./NS: no valid signature found
* Aug 23 14:28:02 named[2731]: no valid RRSIG resolving './NS/IN': 199.7.83.42#53
* Aug 23 14:28:03 named[2731]: validating ./NS: no valid signature found
* Aug 23 14:28:03 named[2731]: no valid RRSIG resolving './NS/IN': 198.97.190.53#53

Possible fixes

My actual workaround is to use dnssec-validation yes instead of dnssec-validation auto.

Query for managed-keys maintenance should not fall-back to disabling EDNS. (see "What is the expected correct behavior?")