Re: named cpu usage pretty high because of dns_dnssec_findzonekeys2 -> file not found
> On 13 Mar 2019, at 2:42 am, Philippe Maechler > wrote: > > Hello Mark and bind users > > Thank you for the explanations. Some things are still not clear to me... > > > -Original Message- > > From: Mark Andrews > > Sent: Monday, March 11, 2019 8:53 AM > > To: Philippe Maechler > > Cc: bind-users@lists.isc.org > > Subject: 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. > > > > Possible, the machine was running all the time (uptime is ~92 days). I would > have to search in old logs to be sure. Since this domain is for testing > purposes, its not important. The "bad thing" is the cpu usage which is quite > high. > Is this something that will be addressed in further bind releases? E.g. > dns_dnssec_findzonekeys2 only search at a given interval for new keys or only > logs this message once in a minute/hour? Named was attempting to re-sign part of the zone and getting a error then re-trying a little bit later. > > 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. > > What exactly ist he sig-validy time? From my understanding this is the period > from "Activate" to “Inactive" "sig-validity-interval [ ];” it is for how long signatures are valid for when they are generated. The default is 30 days which results results in them being queued for re-signing 7.15 days before the signature expired. This is a named.conf setting. > # dnssec-settime -pall Kglattweb.ch.+013+06605 > Created: Mon Mar 11 10:03:49 2019 > Publish: Mon Mar 11 11:06:44 2019 > Activate: Tue Mar 19 10:02:19 2019 > Revoke: UNSET > Inactive: Thu Mar 21 10:06:44 2019 > Delete: Sun Mar 31 11:05:48 2019 > SYNC Publish: Mon Mar 11 11:06:44 2019 > SYNC Delete: Sun Mar 31 11:06:44 2019 > > In this case the sig-validity time is ~2d 4m The sig-validity-interval is not stored in the key. > The key has a delete Date of 2019-03-31 and I can delete (or move) the key at > 2019-04-02 or to be safe 2019-04-03? You are using the dnssec-signzone key management logic. dnssec-signzone signs the entire zone at particular times. Named uses a different strategy. It re-signs the records in a zone as they fall due. One don’t want named signing complete zones all at once as it takes it away from it primary job of serving the zone content. It re-signs the zone in small chunks. The initial signing of the zone spreads those chunks out so they don’t all fall at the same time. This make re-signing of a zone a continuous process rather than specific events. > > 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. > > When are these replacement RRSIGs created? The key reached it's delete date, > the new key is in place and new RRSIGs are created. > > > 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. > > Can you help me here? > # dnssec-importkey -v 99 -f /usr/local/etc/namedb/master/glattweb.ch.db > dnssec-importkey: error: dns_master_load: > /usr/local/etc/namedb/master/glattweb.ch.db:15: glattweb.ch: not at top of > zone > dnssec-importkey: fatal: can't load > /usr/local/etc/namedb/master/glattweb.ch.db: not at top of zone > > ok... yes makes sense, glattweb.ch is not at the top of zone > # head /usr/local/etc/namedb/master/glattweb.ch.db > $TTL300 > $ORIGIN glattweb.ch. > > @ 300 IN SOA dns1.glattnet.ch. hostmaster.glattnet. ( > 2019020400 ; serial > 600 ; refresh > 300 ; retry >3600 ; expire > 90 ; nttl > ) > > I don't think that I should use the .signed file... let’s test that anyway > # dnssec-importkey -v 99 -f /usr/local/etc/namedb/master/glattweb.ch.db.signed > dnssec-importkey: error: dns_master_load: > /usr/local/etc/namedb/master/glattweb.ch.db.signed:1: syntax error > dnssec-importkey: fatal: can't load > /usr/local/etc/namedb/master/glattweb.ch.db.signed: syntax error > > Maybe I have to change the zone format from raw to text... > # named-compilezone -j -fraw -F text -o tmp >
DynDB - handling arbitrary zones
Hi all, first of all, if this is not the right list for such questions, please redirect me. I am exploring the DynDB API of BIND whether it could help us to solve our needs. As I have played around with DLZ quite a few years ago, I was pleased to see a new interface seemingly resolving the problems of the first (mostly the lack of DNSSEC support). However, one thing I am missing, and looking at the demo driver, I did not get a real answer on that. That's why I am asking here. The DLZ driver had to provide a function to find a zone. This allowed it to generate responses for any zone that happened to be in the driver's repository (database or else). There was no need keep a list of known zones and easily scales up to thousands of zones. I did not find a corresponding function in the DynDB API. The whole dbmethods interface seems to handle only a single, specific zone with dns_db_t as an abstract handle to it. I expected somewhere a customizable function that gets a query name and returns the respective (driver specific) zone instance (or an indication if it is not available). Instead, it looks like that one has to enumerate all zones that shall be handled by the driver and register them at a provided "view" instance beforehand. Is this perception correct or do I misunderstand something completely? Thanks in advance for any hints. Regards, Klaus ___ 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: convert Knot DNS sigantures certs to BIND format.
Milan Jeskynka Kazatel wrote:
>
> I received a hint for a tool which allows converting .pem format used in
> Knot to .key and .private used in BIND, but it, unfortunately, does not
> support ECDSAP256SHA256 algorithm which I used.
Ah, sounds like Knot uses a relatively familiar key format, so we can hack
around with OpenSSL command line tools.
Unless I have missed something, BIND doesn't have any support for non-BIND
key files: it has its own code for reading and writing keys, which knows
about OpenSSL's in-memory key format. (I think this is related to support
for multiple crypto providers, and the fact that supporting PEM implies
supporting ASN.1 which is not a task any wise programmer would take on.)
So I think you'll have to get dirty with the key internals; fortunately
the modern key types handle the private material as a blob so you don't
have to fiddle around with half a dozen parameters.
If you have an ECDSA key in PEM format, you can break it open like
this. The short blob is the private key and the long one is the public
key.
$ openssl ec
;
print encode_base64 substr $k, 7, 32;
print encode_base64 substr $k, -64;'
read EC key
writing EC key
9WCSrP5vSTrPMrMWISz3N0aU6wZPcRHxcZKE9g0Wc94=
h9c2BtzXhjYHSdLC+XstMGQ6HBLgoerczR++pA/owtWv/jBxvhJiYLoH6gcXKJddCM3EVcGIv9u2
5TQSHQ7SrA==
The first line is the private key; the second and third lines are the
public key. We can check it matches:
$ cat /var/lib/knot/keys/zone_example.com.json
{
"policy": "\u0006policy",
"nsec3_salt": null,
"nsec3_salt_created": null,
"keys": [
{
"id": "c3e8539dc582bb2ceeca0ab9fb7b89d521a4f658",
"keytag": 19633,
"algorithm": 13,
"public_key":
"h9c2BtzXhjYHSdLC+XstMGQ6HBLgoerczR++pA/owtWv/jBxvhJiYLoH6gcXKJddCM3EVcGIv9u25TQSHQ7SrA==",
"ksk": false,
"created": "2019-03-12T15:44:02+"
}
]
}
Probably the easiest way to turn this into BIND key files is to run
`dnssec-keygen -a ecdsa256 example.com` and edit the output to insert the
short private and long public base64 blobs emitted by the perl. You will
also need to rename the files to match the keytag in knot's zone_*.json
file.
Tony.
--
f.anthony.n.finchhttp://dotat.at/
public services available on equal terms to all___
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.) On Mar 11, 2019, at 7:12 AM, Tony Finch wrote: 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. On 12.03.19 08:18, Chris Buxton wrote: Enabling minimal-responses on an authoritative server will break any other server with a stub zone declaration with this authoritative server listed as master. The implementation of stub zones assumes that an SOA query will retrieve all of the required information (SOA, NS, and supporting A/ records) to successfully insert the zone apex into the cache. isn't SOA response limited in an ongoing RFC draft? that would bereak stub zones too... -- 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. - Have you got anything without Spam in it? - Well, there's Spam egg sausage and Spam, that's not got much Spam in it. ___ 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
Hello Mark and bind users Thank you for the explanations. Some things are still not clear to me... > -Original Message- > From: Mark Andrews > Sent: Monday, March 11, 2019 8:53 AM > To: Philippe Maechler > Cc: bind-users@lists.isc.org > Subject: 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. > Possible, the machine was running all the time (uptime is ~92 days). I would have to search in old logs to be sure. Since this domain is for testing purposes, its not important. The "bad thing" is the cpu usage which is quite high. Is this something that will be addressed in further bind releases? E.g. dns_dnssec_findzonekeys2 only search at a given interval for new keys or only logs this message once in a minute/hour? > 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. What exactly ist he sig-validy time? From my understanding this is the period from "Activate" to "Inactive" # dnssec-settime -pall Kglattweb.ch.+013+06605 Created: Mon Mar 11 10:03:49 2019 Publish: Mon Mar 11 11:06:44 2019 Activate: Tue Mar 19 10:02:19 2019 Revoke: UNSET Inactive: Thu Mar 21 10:06:44 2019 Delete: Sun Mar 31 11:05:48 2019 SYNC Publish: Mon Mar 11 11:06:44 2019 SYNC Delete: Sun Mar 31 11:06:44 2019 In this case the sig-validity time is ~2d 4m The key has a delete Date of 2019-03-31 and I can delete (or move) the key at 2019-04-02 or to be safe 2019-04-03? > 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. When are these replacement RRSIGs created? The key reached it's delete date, the new key is in place and new RRSIGs are created. > 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. Can you help me here? # dnssec-importkey -v 99 -f /usr/local/etc/namedb/master/glattweb.ch.db dnssec-importkey: error: dns_master_load: /usr/local/etc/namedb/master/glattweb.ch.db:15: glattweb.ch: not at top of zone dnssec-importkey: fatal: can't load /usr/local/etc/namedb/master/glattweb.ch.db: not at top of zone ok... yes makes sense, glattweb.ch is not at the top of zone # head /usr/local/etc/namedb/master/glattweb.ch.db $TTL300 $ORIGIN glattweb.ch. @ 300 IN SOA dns1.glattnet.ch. hostmaster.glattnet. ( 2019020400 ; serial 600 ; refresh 300 ; retry 3600 ; expire 90 ; nttl ) I don't think that I should use the .signed file... let’s test that anyway # dnssec-importkey -v 99 -f /usr/local/etc/namedb/master/glattweb.ch.db.signed dnssec-importkey: error: dns_master_load: /usr/local/etc/namedb/master/glattweb.ch.db.signed:1: syntax error dnssec-importkey: fatal: can't load /usr/local/etc/namedb/master/glattweb.ch.db.signed: syntax error Maybe I have to change the zone format from raw to text... # named-compilezone -j -fraw -F text -o tmp glattweb.ch /usr/local/etc/namedb/master/glattweb.ch.db.signed zone glattweb.ch/IN: loaded serial 2019022800 (DNSSEC signed) dump zone to tmp...done OK # less tmp glattweb.ch. 300 IN SOA dns1.glattnet.ch. hostmaster.glattnet. 2019022800 600 300 3600 90 glattweb.ch. 300 IN RRSIG SOA 13 2 300 20190330214039 20190228204039 12809 glattweb.ch. WDhpay5Iwi3DumsZ3UQiwdfkkIY44t8ez8dRW6/xv3sXFOJrwYQTyxwx eO2iiRBZwwOI6oyT/0eNDJiF+FSIlg== ; resign=20190330214039 glattweb.ch. 300 IN NS dns1.glattnet.ch. glattweb.ch. 300 IN NS dns2.glattnet.ch. glattweb.ch. 300 IN RRSIG NS 13 2 300 20190318002703 20190215232756 12809 glattweb.ch. AJ3ez1YZEK6YzRlByyLJf3scpljMgZYjIRH55pG6oPhc7AP0qgo4dBqH MDvaVubxEWyulruRcOiD8jpym6gp2w== ; resign=20190318002703 glattweb.ch. 90 IN NSEC www.glattweb.ch. NS SOA RRSIG NSEC DNSKEY CDS CDNSKEY glattweb.ch. 90 IN RRSIG NSEC 13 2 90
Re: BIND 9.11 no longer respects edns-udp-size?
On Mar 11, 2019, at 7:12 AM, Tony Finch wrote: > > 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. Enabling minimal-responses on an authoritative server will break any other server with a stub zone declaration with this authoritative server listed as master. The implementation of stub zones assumes that an SOA query will retrieve all of the required information (SOA, NS, and supporting A/ records) to successfully insert the zone apex into the cache. Chris Buxton ___ 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
Undefined symbol: .isc_string_strlcpy compiling bind-9.11.6 on powerpc-ibm-aix7.1.0.0
Compiling bind-9.11.6 on AIX (powerpc-ibm-aix7.1.0.0) stops with ld: 0711-317 ERROR: Undefined symbol: .isc_string_strlcpy when trying to build bin/tests/system/dlzexternal/driver.so On the other hand, .isc_string_strlcpy seems to be defined in lib/isc/libisc.a, originating from lib/isc/string.o, both of which is built previously. bind-9.11.5-P4 compiled without problems using the same configuration. Any ideas? ... > making all in /u/nik/tarfiles/bind/bind-9.11.6/bind-9.11.6/bin/tests/system/dlzexternal gcc -I/u/nik/tarfiles/bind/bind-9.11.6/bind-9.11.6 -I../../../.. -I/u/nik/tarfiles/bind/bind-9.11.6/bind-9.11.6/lib/dns/include -I../../../../lib/dns/include -I/u/nik/tarfiles/bind/bind-9.11.6/bind-9.11.6/lib/isc/include -I../../../../lib/isc -I../../../../lib/isc/include -I../../../../lib/isc/unix/include -I../../../../lib/isc/pthreads/include -I../../../../lib/isc/powerpc/include-D_REENTRANT -D_THREAD_SAFE -g -O2 -Wa,-many -fPIC -fPIC -W -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wformat -Wpointer-arith -fno-strict-aliasing -fno-delete-null-pointer-checks -c driver.c gcc -shared -o driver.so driver.o ld: 0711-317 ERROR: Undefined symbol: .isc_string_strlcpy ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. collect2: error: ld returned 8 exit status make: 1254-004 The error code from the last command is 1. Stop. -- Michael Niksch /Zurich/IBM @ IBMCH IBM Zurich Research Laboratory n...@zurich.ibm.com Saeumerstrasse 4 http://www.zurich.ibm.com/~nik/ CH-8803 Rueschlikon / Switzerland P: +41-44-724-8913 F: +41-44-724-8080 ___ 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
convert Knot DNS sigantures certs to BIND format.
Hello Comunity, can I somehow convert Knot DNS stored certificates for a signed zone to BIND format? My use case is to change used topology for authoritative servers. I ´m manage existing zones in Knot, now I would like to transfer it to BIND and use existing certificates for signing it on BIND due to DS records in parent zones. The Knot will be reconfigured as a slave. Is it possible to achieve it? I received a hint for a tool which allows converting .pem format used in Knot to .key and .private used in BIND, but it, unfortunately, does not support ECDSAP256SHA256 algorithm which I used. (http://manpages.ubuntu.com/ manpages/xenial/en/man1/softhsm-keyconv.1.html) Have You any other advice? Thanks. -- Jeskyňka Kazatel ___ 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
