named cpu usage pretty high because of dns_dnssec_findzonekeys2 -> file not found
Hello List Today our bind server started with the following log contents: 11-Mar-2019 07:41:06.599 general: warning: dns_dnssec_findzonekeys2: error reading /usr/local/etc/namedb/keys/glattweb.ch/Kglattweb.ch.+013+33518.private: file not found 11-Mar-2019 07:41:06.600 general: warning: dns_dnssec_findzonekeys2: error reading /usr/local/etc/namedb/keys/glattweb.ch/Kglattweb.ch.+013+33518.private: file not found 11-Mar-2019 07:41:06.602 general: warning: dns_dnssec_findzonekeys2: error reading /usr/local/etc/namedb/keys/glattweb.ch/Kglattweb.ch.+013+33518.private: file not found 11-Mar-2019 07:41:06.603 general: warning: dns_dnssec_findzonekeys2: error reading /usr/local/etc/namedb/keys/glattweb.ch/Kglattweb.ch.+013+33518.private: file not found 11-Mar-2019 07:41:06.604 general: warning: dns_dnssec_findzonekeys2: error reading /usr/local/etc/namedb/keys/glattweb.ch/Kglattweb.ch.+013+33518.private: file not found 11-Mar-2019 07:41:06.606 general: warning: dns_dnssec_findzonekeys2: error reading /usr/local/etc/namedb/keys/glattweb.ch/Kglattweb.ch.+013+33518.private: file not found 11-Mar-2019 07:41:06.607 general: warning: dns_dnssec_findzonekeys2: error reading /usr/local/etc/namedb/keys/glattweb.ch/Kglattweb.ch.+013+33518.private: file not found 11-Mar-2019 07:41:06.609 general: warning: dns_dnssec_findzonekeys2: error reading /usr/local/etc/namedb/keys/glattweb.ch/Kglattweb.ch.+013+33518.private: file not found 11-Mar-2019 07:41:06.610 general: warning: dns_dnssec_findzonekeys2: error reading /usr/local/etc/namedb/keys/glattweb.ch/Kglattweb.ch.+013+33518.private: file not found 11-Mar-2019 07:41:06.611 general: warning: dns_dnssec_findzonekeys2: error reading /usr/local/etc/namedb/keys/glattweb.ch/Kglattweb.ch.+013+33518.private: file not found 11-Mar-2019 07:41:06.613 general: warning: dns_dnssec_findzonekeys2: error reading /usr/local/etc/namedb/keys/glattweb.ch/Kglattweb.ch.+013+33518.private: file not found 11-Mar-2019 07:41:06.614 general: warning: dns_dnssec_findzonekeys2: error reading /usr/local/etc/namedb/keys/glattweb.ch/Kglattweb.ch.+013+33518.private: file not found 11-Mar-2019 07:41:06.616 general: warning: dns_dnssec_findzonekeys2: error reading /usr/local/etc/namedb/keys/glattweb.ch/Kglattweb.ch.+013+33518.private: file not found 11-Mar-2019 07:41:06.617 general: warning: dns_dnssec_findzonekeys2: error reading /usr/local/etc/namedb/keys/glattweb.ch/Kglattweb.ch.+013+33518.private: file not found 11-Mar-2019 07:41:06.618 general: warning: dns_dnssec_findzonekeys2: error reading /usr/local/etc/namedb/keys/glattweb.ch/Kglattweb.ch.+013+33518.private: file not found 11-Mar-2019 07:41:06.620 general: warning: dns_dnssec_findzonekeys2: error reading /usr/local/etc/namedb/keys/glattweb.ch/Kglattweb.ch.+013+33518.private: file not found 11-Mar-2019 07:41:06.621 general: warning: dns_dnssec_findzonekeys2: error reading /usr/local/etc/namedb/keys/glattweb.ch/Kglattweb.ch.+013+33518.private: file not found 11-Mar-2019 07:41:06.623 general: warning: dns_dnssec_findzonekeys2: error reading /usr/local/etc/namedb/keys/glattweb.ch/Kglattweb.ch.+013+33518.private: file not found 11-Mar-2019 07:41:06.624 general: warning: dns_dnssec_findzonekeys2: error reading /usr/local/etc/namedb/keys/glattweb.ch/Kglattweb.ch.+013+33518.private: file not found 11-Mar-2019 07:41:06.625 general: warning: dns_dnssec_findzonekeys2: error reading /usr/local/etc/namedb/keys/glattweb.ch/Kglattweb.ch.+013+33518.private: file not found 11-Mar-2019 07:41:06.627 general: warning: dns_dnssec_findzonekeys2: error reading /usr/local/etc/namedb/keys/glattweb.ch/Kglattweb.ch.+013+33518.private: file not found 11-Mar-2019 07:41:06.628 general: warning: dns_dnssec_findzonekeys2: error reading /usr/local/etc/namedb/keys/glattweb.ch/Kglattweb.ch.+013+33518.private: file not found 11-Mar-2019 07:41:06.630 general: warning: dns_dnssec_findzonekeys2: error reading /usr/local/etc/namedb/keys/glattweb.ch/Kglattweb.ch.+013+33518.private: file not found 11-Mar-2019 07:41:06.631 general: warning: dns_dnssec_findzonekeys2: error reading /usr/local/etc/namedb/keys/glattweb.ch/Kglattweb.ch.+013+33518.private: file not found 11-Mar-2019 07:41:06.633 general: warning: dns_dnssec_findzonekeys2: error reading /usr/local/etc/namedb/keys/glattweb.ch/Kglattweb.ch.+013+33518.private: file not found 11-Mar-2019 07:41:06.634 general: warning: dns_dnssec_findzonekeys2: error reading /usr/local/etc/namedb/keys/glattweb.ch/Kglattweb.ch.+013+33518.private: file not found 11-Mar-2019 07:41:06.635 general: warning: dns_dnssec_findzonekeys2: error reading /usr/local/etc/namedb/keys/glattweb.ch/Kglattweb.ch.+013+33518.private: file not found This is a FreeBSD 11.2 with bind compiled from Ports # named -V BIND 9.11.5 (Extended Support Version) running on FreeBSD amd64 11.2-RELEASE-p5 FreeBSD 11.2-RELEASE-p5 #0: Tue Nov 27 09:33:52 UTC 2018 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC built by make with
Re: Help: BIND _ Recursive query
>On 4 Mar 2019, at 16:20, Paul Kosinski wrote: >> provides our users with general caching DNS service for >> all other domains. > >[...] > >> Its "named.conf" file doesn't list any "forwarders" any more, and >> "forward-only" is gone, but it still has a leftover "recursion yes" >> clause. Am I correct is assuming that this is now useless and can >> be removed? On 04.03.19 16:33, Niall O'Reilly wrote: >If you want "general caching DNS service" to continue to work, >you'll need to keep "recursion yes". On Mon, 4 Mar 2019 19:30:36 +0100 Matus UHLAR - fantomas wrote: actually "recursion yes;" is the default, so if you remove it, it stays set to yes (unless it's set to "no" somewhere). recursion is the feature that allows BIND to resolve domains not configured locally, you surely need it enabled. On 09.03.19 13:33, Paul Kosinski wrote: I gather "recursion yes" (explicit or default) controls whether BIND *does* recursion itself, in the sense of querying other DNS servers for data it doesn't have, I believe that BIND does query other servers for data required for e.g. issuing notify messages, even if the recursion is disabled. not whether it *issues* queries with the "recursion desired" flag set. (Somewhat confusing terminology, in my opinion.) AFAIK "stub" or "static-stub" domains are queried without recursion desired (RD) flag set, but only if recursion is allowed. Thus, RD flag is not related to recursion status. So is the "recursion desired" flag only set when there are forwarders? Presumably it is set in the case of "forward only", but what happens if there are forwarders defined and both "recursion yes" (default) and "forward first" (default) are specified? if there are forwarders defined, they are queried with RD flag set. It doesn't matter if they are set globally or per-domain, not if there's "forward first" or "forward only" set. in the "recursion no" case, forwarders are not queried, only for cases I mentioned above (like resolving nameservers to send notifies to them). -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. One OS to rule them all, One OS to find them, One OS to bring them all and into darkness bind them ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.11 no longer respects edns-udp-size?
You are using the wrong control. Max-udp-size is what you want. -- Mark Andrews > On 11 Mar 2019, at 20:14, Stéphane Bortzmeyer wrote: > > This machine has 'edns-udp-size: 1432' and, indeed, in the reply, it > displays this buffer size. But it does not respect that limit. Here, > with a big DNSKEY RRset, BIND should have truncated the answer and set > the TC bit but it didn't: > > % dig @194.0.9.1 DNSKEY ma > > ; <<>> DiG 9.10.3-P4-Debian <<>> @194.0.9.1 DNSKEY ma > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54499 > ;; flags: qr aa rd; QUERY: 1, ANSWER: 7, AUTHORITY: 0, ADDITIONAL: 1 > ;; WARNING: recursion requested but not available > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags: do; udp: 1432 > ;; QUESTION SECTION: > ;ma.IN DNSKEY > > ;; ANSWER SECTION: > ma.1296000IN DNSKEY 256 3 8 ( >AwEAAcKOK/IPpC+iUOHmrMg76aV+hAimErdlpiCpTGlu >c1+ZCXCLYEpZwaME9vUl5eMDPuEKxa/PkWMsXa89b+Ow >YveMSlESiHv/Jh7lu13Ar+9Ba3vQlTmt/JMBJ0/hR+jD >UXZNLuSjOdcDRfgafQt+pufpClocDCZPdvyP8u466xIr >) ; ZSK; alg = RSASHA256; key id = 25503 > ma.1296000IN DNSKEY 256 3 8 ( >AwEAAagLY1Xa6PqbPvsC5zHybhLFaJtnA/6/i+3wnLyh >3uvWzCOP56VXkn44aYDII+4E/ZrsC7GR4u7/P71PGejD >HcYRvHdRcreIItU8Xtql+hz2BgEn/IeG/Gs67EEEXbE2 >t84pfyRzrcGQAz6nwwbzld1Ld+fQeS0ZT8w4XfMDBpa7 >) ; ZSK; alg = RSASHA256; key id = 51900 > ma.1296000IN DNSKEY 257 3 8 ( >AwEAAaa+pkZNOrS5ZBslnyPGF5BwSFaAAUp48zevzufu >qRKH8bhWGNCV1t7IjX9a7VlxDGoSZk3evYQI6d7h4jzZ >8y0RjVc2jxZMKQeKHTHLVbUcTTqEp2jRFXSCRjT5vkuD >gPfVbajQZOpv+IZxroDdX6UpppEcB7l2qn6QO9RkVuZ9 >Oy4CHhVre2vxL6TTcFGhP3ah/yaDYrmojbspdiCzW4nr >z1HClgy/VmNWQYWwx0ZgYIZiCbsS2gZTZYy8AX+40Y5Q >ZKGTPfF818g6OkEO9OJaZr/gKo+jqKYAIqkoHbsVlmII >jCcmt4rodAzWy59mrlLGiAZIlb93OAmo82SxmNU= >) ; KSK; alg = RSASHA256; key id = 15319 > ma.1296000IN DNSKEY 257 3 8 ( >AwEAAa2j7taBE5OkjqCWbfZ4k+A/lBedIt94dVhEfNpU >nskerqW5c+WL5thP/P3VdcHsPqdUv8fIqeGmVI1BwoUt >MqZmQiKkYntqagX1JpYXwgZmEyybfGUHls81dPIW74bd >aB5K4xcpfdEhnWxN3J9WGaDTRseCHWDKnMNhtqYi/4Sv >aXNH0eB1/8MZ/IH0ukPbwRSn8V8R6Qmn6HNjUpMtGh3e >7OROdDvMp/aTaKPUJ+Dgt74zlWCNwv/VmiEpC4AfHz5p >A23NR46qlIUED/aOuvCp3gZAp7R9uIqTMH0rRz4mB5ru >KJB/Xg5xLyqwOKx6cMHRSoA/nQQ4AKkZa4tWPhc= >) ; KSK; alg = RSASHA256; key id = 33982 > ma.1296000IN RRSIG DNSKEY 8 1 1296000 ( >20190401105301 20190302095632 15319 ma. >WD09LaVuAnrTMl8aZ4qVwiMz0r1qm98a68+vPdfHLsY4 >W2nAriwpSZ+asGiWhrq4P4S+PEOStIgTycsnoKNyR8cX >VwLzXM7w7J9wGaDmvg0j4l0617zG18SKKD4sQoUoxCGV >zBE2j7HgAKwQVLKNOnN1EKSciBZS3o361t80TsG5Iid/ >dNu2cYLIPTVblck/mA2CZaTzVz01zbUn5bGOx8GdEZvE >ld+1ej/jacaGCq80KXwEMxujPmp3tmi5kRpGgv4I+N82 >WS4kdCMuDO05hwwqg52h2QfOkkPDR7g2G0D/6XokYAkg >5pvoj94N5n5zBR2L4BZVmxVZ5DcoE9+q7Q== ) > ma.1296000IN RRSIG DNSKEY 8 1 1296000 ( >20190401105301 20190302095632 33982 ma. >ItE1M13I/Nq9iY1PusCghth9oUbo4+tigZadHvZxjQRY >KNMOtCsOJg0pIdUXbBlPqpu2AG6vCO4gX+cc5/ZdP0Og >IKiAtCagA6/em/JBqR3QObWkJlcBtMoSpcs+rhUckd73 >Y7MJYCMP6I08K1uD9KN6NqThjUEZ/RY9VUyVHlvZ+meJ >ajExJGDLJQ+dK4LPvmmS0JeXjIyOOmMt8411uzw+vTHc >iY4wleGbAfrfYiOsQWmoXJAU0piy5feUHBg8NdadCM6X >cG2k5pybSDEO2ghYK16P9cv0kvMchmTBvVJvDc4+YbWc >ocd9aqjmLCdWeeMQNi3gjZztLTe8Db6umw== ) > ma.1296000IN RRSIG DNSKEY 8 1 1296000 ( >20190401105301 20190302095632 51900 ma. >JUSYyoMbvmquVaxG3lPKBtNfcRYbx79xMKSSSDh8jP4b >TL10HIyYDpGBKujDX0E4TLIDcZWro97t4Mv8JTKL/n1H >0uphGTIFsHzBnp2w4o2/3TuRpoMBcqiTJDUL5PZz4tiO >YcQgwVgXcMjsoee6oFYTJ9O/B3z4eDlqaJQ6UQc= ) > > ;; Query time: 4 msec > ;; SERVER: 194.0.9.1#53(194.0.9.1) > ;; WHEN: Fri Mar 08 15:39:42 CET 2019 > ;; MSG SIZE rcvd: 1621 > > (If you repeat the test, be careful, this IP address is an anycasted > machine, and some instances run NSD, which does not have the bug.) > > You can see here this BIND 9.11 server returning a fragmented answer > (precisely > what we wanted to avoid with edns-udp-size): > > 16:38:37.506180 64:00:6a:78:28:40 > 00:1b:17:00:01:35, ethertype IPv4 > (0x0800), length 73: 10.10.86.133.50572 > 194.0.9.1.53: 45007+ [1au] DNSKEY? > ma. (31) > 16:38:37.510516 00:1b:17:00:01:35 > 64:00:6a:78:28:40, ethertype IPv4 >
BIND 9.11 no longer respects edns-udp-size?
This machine has 'edns-udp-size: 1432' and, indeed, in the reply, it displays this buffer size. But it does not respect that limit. Here, with a big DNSKEY RRset, BIND should have truncated the answer and set the TC bit but it didn't: % dig @194.0.9.1 DNSKEY ma ; <<>> DiG 9.10.3-P4-Debian <<>> @194.0.9.1 DNSKEY ma ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54499 ;; flags: qr aa rd; QUERY: 1, ANSWER: 7, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 1432 ;; QUESTION SECTION: ;ma.IN DNSKEY ;; ANSWER SECTION: ma. 1296000 IN DNSKEY 256 3 8 ( AwEAAcKOK/IPpC+iUOHmrMg76aV+hAimErdlpiCpTGlu c1+ZCXCLYEpZwaME9vUl5eMDPuEKxa/PkWMsXa89b+Ow YveMSlESiHv/Jh7lu13Ar+9Ba3vQlTmt/JMBJ0/hR+jD UXZNLuSjOdcDRfgafQt+pufpClocDCZPdvyP8u466xIr ) ; ZSK; alg = RSASHA256; key id = 25503 ma. 1296000 IN DNSKEY 256 3 8 ( AwEAAagLY1Xa6PqbPvsC5zHybhLFaJtnA/6/i+3wnLyh 3uvWzCOP56VXkn44aYDII+4E/ZrsC7GR4u7/P71PGejD HcYRvHdRcreIItU8Xtql+hz2BgEn/IeG/Gs67EEEXbE2 t84pfyRzrcGQAz6nwwbzld1Ld+fQeS0ZT8w4XfMDBpa7 ) ; ZSK; alg = RSASHA256; key id = 51900 ma. 1296000 IN DNSKEY 257 3 8 ( AwEAAaa+pkZNOrS5ZBslnyPGF5BwSFaAAUp48zevzufu qRKH8bhWGNCV1t7IjX9a7VlxDGoSZk3evYQI6d7h4jzZ 8y0RjVc2jxZMKQeKHTHLVbUcTTqEp2jRFXSCRjT5vkuD gPfVbajQZOpv+IZxroDdX6UpppEcB7l2qn6QO9RkVuZ9 Oy4CHhVre2vxL6TTcFGhP3ah/yaDYrmojbspdiCzW4nr z1HClgy/VmNWQYWwx0ZgYIZiCbsS2gZTZYy8AX+40Y5Q ZKGTPfF818g6OkEO9OJaZr/gKo+jqKYAIqkoHbsVlmII jCcmt4rodAzWy59mrlLGiAZIlb93OAmo82SxmNU= ) ; KSK; alg = RSASHA256; key id = 15319 ma. 1296000 IN DNSKEY 257 3 8 ( AwEAAa2j7taBE5OkjqCWbfZ4k+A/lBedIt94dVhEfNpU nskerqW5c+WL5thP/P3VdcHsPqdUv8fIqeGmVI1BwoUt MqZmQiKkYntqagX1JpYXwgZmEyybfGUHls81dPIW74bd aB5K4xcpfdEhnWxN3J9WGaDTRseCHWDKnMNhtqYi/4Sv aXNH0eB1/8MZ/IH0ukPbwRSn8V8R6Qmn6HNjUpMtGh3e 7OROdDvMp/aTaKPUJ+Dgt74zlWCNwv/VmiEpC4AfHz5p A23NR46qlIUED/aOuvCp3gZAp7R9uIqTMH0rRz4mB5ru KJB/Xg5xLyqwOKx6cMHRSoA/nQQ4AKkZa4tWPhc= ) ; KSK; alg = RSASHA256; key id = 33982 ma. 1296000 IN RRSIG DNSKEY 8 1 1296000 ( 20190401105301 20190302095632 15319 ma. WD09LaVuAnrTMl8aZ4qVwiMz0r1qm98a68+vPdfHLsY4 W2nAriwpSZ+asGiWhrq4P4S+PEOStIgTycsnoKNyR8cX VwLzXM7w7J9wGaDmvg0j4l0617zG18SKKD4sQoUoxCGV zBE2j7HgAKwQVLKNOnN1EKSciBZS3o361t80TsG5Iid/ dNu2cYLIPTVblck/mA2CZaTzVz01zbUn5bGOx8GdEZvE ld+1ej/jacaGCq80KXwEMxujPmp3tmi5kRpGgv4I+N82 WS4kdCMuDO05hwwqg52h2QfOkkPDR7g2G0D/6XokYAkg 5pvoj94N5n5zBR2L4BZVmxVZ5DcoE9+q7Q== ) ma. 1296000 IN RRSIG DNSKEY 8 1 1296000 ( 20190401105301 20190302095632 33982 ma. ItE1M13I/Nq9iY1PusCghth9oUbo4+tigZadHvZxjQRY KNMOtCsOJg0pIdUXbBlPqpu2AG6vCO4gX+cc5/ZdP0Og IKiAtCagA6/em/JBqR3QObWkJlcBtMoSpcs+rhUckd73 Y7MJYCMP6I08K1uD9KN6NqThjUEZ/RY9VUyVHlvZ+meJ ajExJGDLJQ+dK4LPvmmS0JeXjIyOOmMt8411uzw+vTHc iY4wleGbAfrfYiOsQWmoXJAU0piy5feUHBg8NdadCM6X cG2k5pybSDEO2ghYK16P9cv0kvMchmTBvVJvDc4+YbWc ocd9aqjmLCdWeeMQNi3gjZztLTe8Db6umw== ) ma. 1296000 IN RRSIG DNSKEY 8 1 1296000 ( 20190401105301 20190302095632 51900 ma. JUSYyoMbvmquVaxG3lPKBtNfcRYbx79xMKSSSDh8jP4b TL10HIyYDpGBKujDX0E4TLIDcZWro97t4Mv8JTKL/n1H 0uphGTIFsHzBnp2w4o2/3TuRpoMBcqiTJDUL5PZz4tiO YcQgwVgXcMjsoee6oFYTJ9O/B3z4eDlqaJQ6UQc= ) ;; Query time: 4 msec ;; SERVER:
Re: named cpu usage pretty high because of dns_dnssec_findzonekeys2 -> file not found
Because you removed the key from disk before it was removed from the zone. Presumably named was logging other error messages before you removed the key from disk or the machine was off for a period or you mismanaged the key roll and named keep the key alive. Named’s re-signing strategy is different to when you are signing the whole zone at once as you are signing it incrementally. You should be allowing most of the sig-validity interval before you delete the DNSKEY after you inactive it. One should check that there are no RRSIGs still present in the zone before deleting the DNSKEY from the zone. Inactivating it stops the DNSKEY being used to generate new signatures but it needs to stay around until all those RRSIGs have expired from caches which only happens after new replacement signatures have been generated. If you still have the .private file around reinstate it. If not you will need to import the DNSKEY using dnssec-importkey and manage its removal properly. [beetle:~/git/bind9] marka% dig dnskey glattweb.ch +rrcomm ;; BADCOOKIE, retrying. ; <<>> DiG 9.15.0-dev+hotspot+add-prefetch+marka <<>> dnskey glattweb.ch +rrcomm ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64267 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: 7b44693b86938f2bda7d25725c86082c5b24bafb90421a0a (good) ;; QUESTION SECTION: ;glattweb.ch. IN DNSKEY ;; ANSWER SECTION: glattweb.ch.300 IN DNSKEY 256 3 13 Y/m7vFPwhqc59OlfyJLnT66TNsHYMq4JvXN0hBChCD1UpanF/o18bLHh VVMMTK0iB4EeuIdbn1aWvdVeFmSgmg== ; ZSK; alg = ECDSAP256SHA256 ; key id = 12809 glattweb.ch.300 IN DNSKEY 256 3 13 WqIsxqVPQxDwLqB/rv7u2sSx0R4ZgdHM6NexcDs3Z551rHar015v+jB6 HdnZQ/gMscxz6XzFwEc3+xAzsMx3QA== ; ZSK; alg = ECDSAP256SHA256 ; key id = 33518 ;; Query time: 2454 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Mon Mar 11 18:03:08 AEDT 2019 ;; MSG SIZE rcvd: 228 [beetle:~/git/bind9] marka% > On 11 Mar 2019, at 6:00 pm, Philippe Maechler > wrote: > > Hello List > > Today our bind server started with the following log contents: > 11-Mar-2019 07:41:06.599 general: warning: dns_dnssec_findzonekeys2: error > reading > /usr/local/etc/namedb/keys/glattweb.ch/Kglattweb.ch.+013+33518.private: file > not found > 11-Mar-2019 07:41:06.600 general: warning: dns_dnssec_findzonekeys2: error > reading > /usr/local/etc/namedb/keys/glattweb.ch/Kglattweb.ch.+013+33518.private: file > not found > 11-Mar-2019 07:41:06.602 general: warning: dns_dnssec_findzonekeys2: error > reading > /usr/local/etc/namedb/keys/glattweb.ch/Kglattweb.ch.+013+33518.private: file > not found > 11-Mar-2019 07:41:06.603 general: warning: dns_dnssec_findzonekeys2: error > reading > /usr/local/etc/namedb/keys/glattweb.ch/Kglattweb.ch.+013+33518.private: file > not found > 11-Mar-2019 07:41:06.604 general: warning: dns_dnssec_findzonekeys2: error > reading > /usr/local/etc/namedb/keys/glattweb.ch/Kglattweb.ch.+013+33518.private: file > not found > 11-Mar-2019 07:41:06.606 general: warning: dns_dnssec_findzonekeys2: error > reading > /usr/local/etc/namedb/keys/glattweb.ch/Kglattweb.ch.+013+33518.private: file > not found > 11-Mar-2019 07:41:06.607 general: warning: dns_dnssec_findzonekeys2: error > reading > /usr/local/etc/namedb/keys/glattweb.ch/Kglattweb.ch.+013+33518.private: file > not found > 11-Mar-2019 07:41:06.609 general: warning: dns_dnssec_findzonekeys2: error > reading > /usr/local/etc/namedb/keys/glattweb.ch/Kglattweb.ch.+013+33518.private: file > not found > 11-Mar-2019 07:41:06.610 general: warning: dns_dnssec_findzonekeys2: error > reading > /usr/local/etc/namedb/keys/glattweb.ch/Kglattweb.ch.+013+33518.private: file > not found > 11-Mar-2019 07:41:06.611 general: warning: dns_dnssec_findzonekeys2: error > reading > /usr/local/etc/namedb/keys/glattweb.ch/Kglattweb.ch.+013+33518.private: file > not found > 11-Mar-2019 07:41:06.613 general: warning: dns_dnssec_findzonekeys2: error > reading > /usr/local/etc/namedb/keys/glattweb.ch/Kglattweb.ch.+013+33518.private: file > not found > 11-Mar-2019 07:41:06.614 general: warning: dns_dnssec_findzonekeys2: error > reading > /usr/local/etc/namedb/keys/glattweb.ch/Kglattweb.ch.+013+33518.private: file > not found > 11-Mar-2019 07:41:06.616 general: warning: dns_dnssec_findzonekeys2: error > reading > /usr/local/etc/namedb/keys/glattweb.ch/Kglattweb.ch.+013+33518.private: file > not found > 11-Mar-2019 07:41:06.617 general: warning: dns_dnssec_findzonekeys2: error > reading > /usr/local/etc/namedb/keys/glattweb.ch/Kglattweb.ch.+013+33518.private: file > not found > 11-Mar-2019 07:41:06.618 general: warning: dns_dnssec_findzonekeys2: error > reading > /usr/local/etc/namedb/keys/glattweb.ch/Kglattweb.ch.+013+33518.private: file > not found > 11-Mar-2019 07:41:06.620 general: warning:
Error: zone example.com/IN (signed): receive_secure_serial: unchanged
Hi list We're sometimes receiving the same error as described in https://gitlab.isc.org/isc-projects/bind9/issues/256 after reloading BIND. zone example.com/IN (signed): receive_secure_serial: unchanged What does this error exactly means? What can I do to prevent this error? It seems, that DNSSEC is working fine, but the error is confusing. Thank you. Kind regards, Tom ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.11 no longer respects edns-udp-size?
On Mon, Mar 11, 2019 at 09:39:58PM +1100, Mark Andrews wrote a message of 119 lines which said: > You are using the wrong control. > Max-udp-size is what you want. Thanks it works as expected now. % dig +ignore @194.0.9.1 DNSKEY ma ; <<>> DiG 9.10.3-P4-Debian <<>> +ignore @194.0.9.1 DNSKEY ma ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24200 ;; flags: qr aa tc rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 1432 ;; QUESTION SECTION: ;ma.IN DNSKEY ;; Query time: 3 msec ;; SERVER: 194.0.9.1#53(194.0.9.1) ;; WHEN: Mon Mar 11 15:02:18 CET 2019 ;; MSG SIZE rcvd: 31 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.11 no longer respects edns-udp-size?
On Mon, Mar 11, 2019 at 12:57:02PM +, Tony Finch wrote a message of 40 lines which said: > > ; <<>> DiG 9.10.3-P4-Debian <<>> @194.0.9.1 DNSKEY ma > > To properly diagnose UDP message size issues you need +ignore +notcp on > the command line. (You actually need both options to stop dig using TCP in > all situations.) The response you pasted looked to me like what I get when > dig retries over TCP (except the "Truncated, retrying" notice was > omitted). I know and this is why I both checked the absence and "Truncated, retrying" and used tcpdump to be sure UDP was used. > > ; EDNS: version: 0, flags: do; udp: 1432 > > Weirdly, the DO flag here implies you added the +dnssec option but it > wasn't mentioned on the command line. % cat ~/.digrc +bufsize=4096 +dnssec +multi IMHO, dig could add these options on the command-line it displays. > Mark answered this part of the question, but I recommend also using > minimal-responses and minimal-any Does minimal-responses make sense for an authoritative name server? (Note there was no glue involved.) ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.11 no longer respects edns-udp-size?
Stéphane Bortzmeyer wrote: > > Does minimal-responses make sense for an authoritative name server? > (Note there was no glue involved.) I think it helps reduce fragmentation if the max-udp-size is larger than the MSS, but apart from that it probably doesn't make much difference. As far as I can tell, clients and resolvers generally re-query for additional records when they are needed, and they already have the delegation records which should be the same as the authority records, so it seems pointless to me to add records to authoritative responses when they aren't used. Tony. -- f.anthony.n.finchhttp://dotat.at/ Berwick upon Tweed to Whitby: Northwest 5 or 6, backing south 6 to gale 8, then veering southwest 5 or 6 later. Moderate, occasionally rough, becoming slight or moderate later. Rain for a time. Good, occasionally poor for a time.___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.11 no longer respects edns-udp-size?
Stéphane Bortzmeyer wrote: > ; <<>> DiG 9.10.3-P4-Debian <<>> @194.0.9.1 DNSKEY ma To properly diagnose UDP message size issues you need +ignore +notcp on the command line. (You actually need both options to stop dig using TCP in all situations.) The response you pasted looked to me like what I get when dig retries over TCP (except the "Truncated, retrying" notice was omitted). > ; EDNS: version: 0, flags: do; udp: 1432 Weirdly, the DO flag here implies you added the +dnssec option but it wasn't mentioned on the command line. > You can see here this BIND 9.11 server returning a fragmented answer > (precisely > what we wanted to avoid with edns-udp-size): Mark answered this part of the question, but I recommend also using minimal-responses and minimal-any to further reduce the need for fragmentation or truncation. Tony. -- f.anthony.n.finchhttp://dotat.at/ Lough Foyle to Carlingford Lough: Southwest 4 or 5, backing south 7 to severe gale 9, then veering southwest 5 to 7 later. Slight or moderate at first in east, otherwise moderate or rough, occasionally very rough for a time. Fair then rain, showers later. Good becoming moderate or poor for a time.___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: named cpu usage pretty high because of dns_dnssec_findzonekeys2 -> file not found
On 11-Mar-19 03:52, Mark Andrews wrote:
> Because you removed the key from disk before it was removed from the zone.
> Presumably named
> was logging other error messages before you removed the key from disk or the
> machine was off
> for a period or you mismanaged the key roll and named keep the key alive.
>
> Named’s re-signing strategy is different to when you are signing the whole
> zone at once as
> you are signing it incrementally. You should be allowing most of the
> sig-validity interval
> before you delete the DNSKEY after you inactive it. One should check that
> there are no RRSIGs
> still present in the zone before deleting the DNSKEY from the zone.
> Inactivating it stops the
> DNSKEY being used to generate new signatures but it needs to stay around
> until all those RRSIGs
> have expired from caches which only happens after new replacement signatures
> have been generated.
There are a lot of these "administrator should know" events and timeouts
in DNSSEC. One could argue that these complexities are one of the
barriers to adoption.
It seems worth considering ways to make life easier, for administrators
and automation alike.
A few thoughts come immediately to mind - no doubt there are more:
- Rather than documenting "wait for n TTLs (or sig-validity interval)",
have bind log events that require/enable administrator actions (at
non-debug levels), such as:
"key (keyid) /foo/bar/.. no longer required and can be removed" - issue
at inactivation + max TTL of any RRSIG is signed. Allows an admin (or
script) to know when it's safe rather than requiring research and/or math.
"key (keyid) /foo/baz... is now signing zone(s)
example.net,example.org. It expires on <> and will be removed on <>"
- Provide an "obsolete-keys" directory - have named move keys that are
no longer required there. (Or delete the files. But emptying
obsolete-keys, like emptying /tmp, can be automated, and deleting a key
might be a problem if forensics - or audits - is required.) The key idea
is that an admin never removes a file from "keys". And that should
prevent mistakes.
- Rather than relying on the keys directory for signing, use it only to
import/update keys. Once named starts using a key, put a copy (or move
it) to ".active-keys" - or a database file - that persists as long is
the protocol requires it. If the file in the keys directory is updated
with new dates, generate the appropriate events - but work from
.active-keys. If the file disappears from "keys" before it should, use
.active-keys to restore it -- and add a comment explaining why. ("#
Restored by named at 1-apr-2411: sig-validity interval for
lost.example.net (internal) extends to 15-may-2412")
- Provide an rndc show class command (or stats channel output) that
explains the status/fate of each signing key. Perhaps a table:
Key Zone view State created publish active deactivate remove
next_event
key (keyid) /foo/baz... example.net external Published 1-jan-2000
1-jun-2000 1-Jul-2000 31-dec-2000 1-feb-2001 activate 1-Jun-2000 #
Assumes today is 11-Mar-2000
key (keyid) /foo/baz... example.org external Published 1-jan-2000
1-jun-2000 1-Jul-2000 31-dec-2000 1-feb-2001 activate 1-Jun-2000 # Same
key, different zone
- Think more about what admins want to do, rather than how named (and
the protocols) do it. E.g. "sign a zone", "roll key now|every month",
"use latest|specified|safest signature algorithm | key length",
"enable/disable nsec|nsec3", "unsign zone"... Provide scripts and/or
named primitives that do this. "dnssec settime -xyz" doesn't do a good
job of specifying intent - one has to do a lot of math, and the intent
isn't logged - just the date change.
I'm aware of the dnssec keymgr effort - it's still more oriented to
timeouts and e.g. coverage periods than to what one wants to
accomplish. (As far as I can tell, it also doesn't support multiple
views - which makes it unusable for me. I don't think this is an
unusual configuration...)
If you look at validate() in policy.py.in, there are 6 different errors
for conditions involving timer relationships. [And the errors are
reported in seconds, not even as something vaguely human - such as
57w2d1h30m12s.] Why not (by default) adjust the timers & log the result?
I'm sure someone will opine that for every case, there's a choice
between shrinking one timer and extending the other. This is undoubtedly
true. But better to pick a strategy that is consistent with safe
practice than to kick back each error to an admin. An admin who has
particular requirements can read the log. But for those who "just want
things to work", I suspect that we can identify a driver (I nominate key
lifetime) & adjust everything else to fit...
I'm sure there are some challenges in the details - but I hope the
message is clear. Avoid blaming the admin for trying to make things
work. Instead, package actions at admin-oriented levels of
abstraction. Guard data that named needs, and
Re: BIND 9.11 no longer respects edns-udp-size?
I actually HATE this behaviour by TLDs. There is no need to restrict the EDNS UDP size at the authoritative server to prevent fragmentation. If the path block fragments the client will adjust their EDNS UDP size to match. If the path supports fragmentation (which is the actual RFC requirement) then the client doesn’t need to switch to TCP. Stop forcing me to use TCP because others can’t configure their firewalls correctly. It’s not your job to correct for their stupidity. The network doesn’t drop fragments. Firewalls at the client end may and if so it it the clients responsibility to fix the firewalls. This is self inflicted pain. If you have local equipment that is dropping fragments FIX IT. Mark > On 12 Mar 2019, at 1:02 am, Stéphane Bortzmeyer wrote: > > On Mon, Mar 11, 2019 at 09:39:58PM +1100, > Mark Andrews wrote > a message of 119 lines which said: > >> You are using the wrong control. >> Max-udp-size is what you want. > > Thanks it works as expected now. > > % dig +ignore @194.0.9.1 DNSKEY ma > > ; <<>> DiG 9.10.3-P4-Debian <<>> +ignore @194.0.9.1 DNSKEY ma > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24200 > ;; flags: qr aa tc rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 > ;; WARNING: recursion requested but not available > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags: do; udp: 1432 > ;; QUESTION SECTION: > ;ma. IN DNSKEY > > ;; Query time: 3 msec > ;; SERVER: 194.0.9.1#53(194.0.9.1) > ;; WHEN: Mon Mar 11 15:02:18 CET 2019 > ;; MSG SIZE rcvd: 31 > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
