Re: Regarding HMAC-SHA256 and RSASHA512 key generation algorithm in dnssec-keygen
On Thu, Mar 06, 2014 at 08:55:28AM +0100, Carsten Strotmann wrote: I agree that it might be nice to change dnssec-keygen to make the tool more userfriendly. The current state-of-things is because of historic developments in how DNSSEC came to birth. ...and lots of people dealing with dnssec-keygen's user-unfriendliness by writing shell scripts to run it, which will break if we change its interface now. A lot of old mistakes have gotten chiseled into stone by that. I've long wanted to write a replacement for the zone key functions of dnssec-keygen (or at least a sensible wrapper), so that DNSSEC keys could be generated according to a configured policy rather than command-line alphabet soup. For generating host keys, I suggest ddns-confgen rather than dnssec-keygen. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: Regarding HMAC-SHA256 and RSASHA512 key generation algorithm in dnssec-keygen
Nothing is ever set in stone that hard. Sorry they wrote scripts for it. All apologies they decided to use Elmer's glue instead of high tensile strength super carbon based cement. They will just have to amend those temp scripts with some test cases or you can write a compatibility shim with an expiration clause with an annoying warning message. I recall spending a LOT of time with DNSSEC figuring out all the nonsense but like anything else stability and friendliness has to start somewhere. And development should not be impeded by adoption of bad practices. Fix the root cause not the symptom. -- Jason Hellenthal Voice: 95.30.17.6/616 JJH48-ARIN On Mar 6, 2014, at 3:11, Evan Hunt e...@isc.org wrote: On Thu, Mar 06, 2014 at 08:55:28AM +0100, Carsten Strotmann wrote: I agree that it might be nice to change dnssec-keygen to make the tool more userfriendly. The current state-of-things is because of historic developments in how DNSSEC came to birth. ...and lots of people dealing with dnssec-keygen's user-unfriendliness by writing shell scripts to run it, which will break if we change its interface now. A lot of old mistakes have gotten chiseled into stone by that. I've long wanted to write a replacement for the zone key functions of dnssec-keygen (or at least a sensible wrapper), so that DNSSEC keys could be generated according to a configured policy rather than command-line alphabet soup. For generating host keys, I suggest ddns-confgen rather than dnssec-keygen. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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 smime.p7s Description: S/MIME cryptographic signature ___ 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: Regarding HMAC-SHA256 and RSASHA512 key generation algorithm in dnssec-keygen
Jason Hellenthal jhellent...@dataix.net wrote: I recall spending a LOT of time with DNSSEC figuring out all the nonsense but like anything else stability and friendliness has to start somewhere. And development should not be impeded by adoption of bad practices. Fix the root cause not the symptom. dnssec-keygen actually has quite sane defaults, but unfortunately the man page is not great at saying which options can be ignored because they are cruft from the 1990s. It could do with better examples too. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ South Utsire, Forties: Southwesterly 5 to 7, perhaps gale 8 later. Moderate or rough. Rain. Moderate or poor. ___ 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: Regarding HMAC-SHA256 and RSASHA512 key generation algorithm in dnssec-keygen
On 06/03/14 08:53, Tony Finch wrote: Jason Hellenthal jhellent...@dataix.net wrote: I recall spending a LOT of time with DNSSEC figuring out all the nonsense but like anything else stability and friendliness has to start somewhere. And development should not be impeded by adoption of bad practices. Fix the root cause not the symptom. dnssec-keygen actually has quite sane defaults, but unfortunately the man Agreed. The first couple of times you figure the options takes a bit of time, but once you've done that, dnssec-keygen is really quite inoffensive. Frankly there are a bucketload of Unix tools whose more esoteric behaviour I've never bothered to memorise; the key is for help and man pages to be sane. I'm constantly doing man find... ___ 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: Regarding HMAC-SHA256 and RSASHA512 key generation algorithm in dnssec-keygen
Hi Evan, Evan Hunt e...@isc.org writes: On Thu, Mar 06, 2014 at 08:55:28AM +0100, Carsten Strotmann wrote: I agree that it might be nice to change dnssec-keygen to make the tool more userfriendly. The current state-of-things is because of historic developments in how DNSSEC came to birth. ...and lots of people dealing with dnssec-keygen's user-unfriendliness by writing shell scripts to run it, which will break if we change its interface now. A lot of old mistakes have gotten chiseled into stone by that. there could be a hard-link from a name like tsig-keygen to dnssec-keygen which changes the type of key created to -n HOST. That would not require any change to the existing interface. Just an idea. I'm not suggesting to change the existing interface, as it will break existing stuff. -- Carsten ___ 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: Regarding HMAC-SHA256 and RSASHA512 key generation algorithm in dnssec-keygen
there could be a hard-link from a name like tsig-keygen to dnssec-keygen which changes the type of key created to -n HOST. That would not require any change to the existing interface. Just an idea. Thanks, Carsten. I had actually had the same thought after writing my post last night, though I was thinking of making it a hard link to ddns-confgen rather than dnssec-keygen. (Question: is ddns-confgen -q an appropriate and useful format? I've never understood why anybody would want TSIG keys in .key/.private form, but there may be a use case for it that I've overlooked.) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: Regarding HMAC-SHA256 and RSASHA512 key generation algorithm in dnssec-keygen
At the time of posting this question, I didn't think that this thread will cause this much of discussion. :) Thanks to all for nice explanation and help. Regards, Gaurav Kansal -Original Message- From: bind-users-bounces+gaurav.kansal=nic...@lists.isc.org [mailto:bind-users-bounces+gaurav.kansal=nic...@lists.isc.org] On Behalf Of Evan Hunt Sent: Thursday, March 6, 2014 10:08 PM To: Carsten Strotmann Cc: bind-users@lists.isc.org Subject: Re: Regarding HMAC-SHA256 and RSASHA512 key generation algorithm in dnssec-keygen there could be a hard-link from a name like tsig-keygen to dnssec-keygen which changes the type of key created to -n HOST. That would not require any change to the existing interface. Just an idea. Thanks, Carsten. I had actually had the same thought after writing my post last night, though I was thinking of making it a hard link to ddns-confgen rather than dnssec-keygen. (Question: is ddns-confgen -q an appropriate and useful format? I've never understood why anybody would want TSIG keys in .key/.private form, but there may be a use case for it that I've overlooked.) -- Evan Hunt -- mailto:e...@isc.org e...@isc.org Internet Systems Consortium, Inc. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list mailto:bind-users@lists.isc.org bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users https://lists.isc.org/mailman/listinfo/bind-users ___ 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: Converting an inline-signed zone to unsigned
On Feb 19 2014, Alan Clegg wrote: On 2/19/14, 8:59 PM, Chris Thompson wrote: What is the right way ... or maybe I should be asking IS there a right way ... to change a zone that has been signed by inline signing (i.e. with inline-signing yes; auto-dnssec maintain; in it zone statement) to unsigned? When I change the zone statement to remove the inline signing part, and update the SOA serial in the zone file for good measure, and then do either rndc reload or rndc reconfig, I get messages like named[22954]: general: error: zone playground.test/IN: journal rollforward failed: journal out of sync with zone named[22954]: general: error: zone playground.test/IN: not loaded due to errors. and the zone goes into SERVFAIL state. The only way I found out of this was to remove the [zone-file].signed and [zone-file].signed.jnl files manually, and *then* do rndc reconfig. Surely there must be something better than that? Have you tried setting dnssec-secure-to-insecure then setting all of the keys to deleted? Thanks - I have now tried that (set the deletion date to now with dnssec-settime), and it does work. You end up with a [zone-file].signed which is not actually signed being served, but being maintained from [zone-file] in an incremental way. I suppose this is indeed the way to go with the flow of inline signing. You don't even have to have any keys for the zone in the key directory initially. It's the transition between having inline-signing yes and inline-signing no in the zone definition that seems to expose rough edge cases. I still have to investigate the problem that Graham Clinch reported, and see whether that might be a show-stopper for the application of inline signing that I have in mind. More generally: it's a pity that there isn't any real documentation of inline signing in the ARM, just the examples in ISC's KB articles. Some clearer explanation of which options inline-signing yes is (in)compatible with would be helpful. For example, it obviously turns on some sort of moral equivalent of ixfr-from-differences yes on the unsigned version of the zone, but would turning inline signing on (or off) work better if this were specified explicitly? And the examples have auto-dnssec maintain, but would auto-dnssec allow work? -- Chris Thompson Email: c...@cam.ac.uk ___ 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: Regarding HMAC-SHA256 and RSASHA512 key generation algorithm in dnssec-keygen
Hello Evan, Evan Hunt e...@isc.org writes: there could be a hard-link from a name like tsig-keygen to dnssec-keygen which changes the type of key created to -n HOST. That would not require any change to the existing interface. Just an idea. Thanks, Carsten. I had actually had the same thought after writing my post last night, though I was thinking of making it a hard link to ddns-confgen rather than dnssec-keygen. a link to ddns-confgen would work well (Question: is ddns-confgen -q an appropriate and useful format? I've never understood why anybody would want TSIG keys in .key/.private form, but there may be a use case for it that I've overlooked.) Yes, it is most useful. I do not have a use-case for the .key/.private form (except existing scripts that expect these formats). -- Carsten ___ 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: Converting an inline-signed zone to unsigned
Thanks - I have now tried that (set the deletion date to now with dnssec-settime), and it does work. You end up with a [zone-file].signed which is not actually signed being served, but being maintained from [zone-file] in an incremental way. I suppose this is indeed the way to go with the flow of inline signing. You don't even have to have any keys for the zone in the key directory initially. It's the transition between having inline-signing yes and inline-signing no in the zone definition that seems to expose rough edge cases. Is [zone-file].signed really being maintained? When I took an unsigned zone and enabled inline-signing without generating any keys, the zone content became 'frozen in time' until keys were generated (at least with versions '9.9.3-rpz2+rl.13214.22-P2-Ubuntu-1:9.9.3.dfsg.P2-4ubuntu3' '9.9.5-2-Ubuntu'). In short, these messages are logged: info: zone test1.local/IN (unsigned): loaded serial 2014030615 info: zone test1.local/IN (signed): serial 2014030615 (unsigned 2014030615) error: zone test1.local/IN (signed): could not get zone keys for secure dynamic update error: zone test1.local/IN (signed): receive_secure_serial: not found But despite showing unsigned and signed zone both with serial 2014030615, the 'signed' one actually still has 2014030610 - the serial at the point of enabling inline-signing. I still have to investigate the problem that Graham Clinch reported, and see whether that might be a show-stopper for the application of inline signing that I have in mind. More generally: it's a pity that there isn't any real documentation of inline signing in the ARM, just the examples in ISC's KB articles. Some clearer explanation of which options inline-signing yes is (in)compatible with would be helpful. For example, it obviously turns on some sort of moral equivalent of ixfr-from-differences yes on the unsigned version of the zone, but would turning inline signing on (or off) work better if this were specified explicitly? And the examples have auto-dnssec maintain, but would auto-dnssec allow work? An 'rndc sync -clear test1.local' clears both zonefile.jnl and zonefile.signed.jnl. It doesn't seem to modify the zonefile (because it's only recording past differences as a side effect of inline-signing enabling ixfr-from-differences??), but it does mean that the signed zone doesn't have IXFR data anymore, which probably leads me back to just blowing away zonefile.jnl (or hoping that named doesn't stop/isn't stopped - although I'm obviously hoping that anyway...). Graham ___ 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: Converting an inline-signed zone to unsigned
On Mar 6 2014, Graham Clinch wrote: Thanks - I have now tried that (set the deletion date to now with dnssec-settime), and it does work. You end up with a [zone-file].signed which is not actually signed being served, but being maintained from [zone-file] in an incremental way. I suppose this is indeed the way to go with the flow of inline signing. You don't even have to have any keys for the zone in the key directory initially. It's the transition between having inline-signing yes and inline-signing no in the zone definition that seems to expose rough edge cases. Is [zone-file].signed really being maintained? When I took an unsigned zone and enabled inline-signing without generating any keys, the zone content became 'frozen in time' until keys were generated (at least with versions '9.9.3-rpz2+rl.13214.22-P2-Ubuntu-1:9.9.3.dfsg.P2-4ubuntu3' '9.9.5-2-Ubuntu'). In short, these messages are logged: info: zone test1.local/IN (unsigned): loaded serial 2014030615 info: zone test1.local/IN (signed): serial 2014030615 (unsigned 2014030615) error: zone test1.local/IN (signed): could not get zone keys for secure dynamic update error: zone test1.local/IN (signed): receive_secure_serial: not found Oh, . You are right. Using 9.9.5, I get messages exactly like that when updating the unsigned zone file while there are no keys. I am not sure how I previously managed to convince myself otherwise. I think I am going to have to retreat hurt from this attempt to use inline signing, and find some other way of achieving what I want. -- Chris Thompson Email: c...@cam.ac.uk ___ 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: Converting an inline-signed zone to unsigned
Hi Chris co, Using 9.9.5, I get messages exactly like that when updating the unsigned zone file while there are no keys. Thanks for the confirmation - I've logged bind9 bug #35502 inline-signed zone, with no keys, does not synchronise changes made in master file. Back on topic - I didn't investigate very thoroughly, but simply removing 'inline-signing yes' seemed to do ok for me (without marking the keys as deleted, or setting 'dnssec-secure-to-insecure'). Graham ___ 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: Sporadic but noticable SERVFAILs in specific nodes of an anycast resolving farm running BIND
Hello We are facing a similar problem by getting an intermittent SERVER FAILS on several domains and specifically during the high traffic. Please note that the IPV6 dual stack is not configured in the Operating system and we are not using any IPV6 option in the BIND configuration file. 1- We compiled several BIND versions on different CentOS platforms CentOS release 5.10 with BIND 9.9.5 and BIND 9.7.2-P2 : Problem Persists CentOS release 5.6 with BIND 9.9.5 and BIND 9.7.2-P2 : Proble Persits 2- We bypassed all network devices (Firewall, Shaper, IPS, LOADBALANCER): Problem persists 3- TCPDUMP performed on the name servers showed the SERVERFAIL in the capture 4- Dig debugging output shows intermittent SERVER FAIL: dig www.mcafee.com HEADER- opcode: QUERY, status: SERVFAIL, id: 49448 ot fo other domains 5- We noticed during our debugging a failure when using dig +trace ;; Received 493 bytes from 192.5.5.241#53(f.root-servers.net) in 64 ms dig: couldn't get address for 'k.gtld-servers.net': failure Regards Daniel Dawalibi Senior Systems Engineer e-mail:daniel.dawal...@idm.net.lb Jisr Al Bacha P.O. Box 11-316 Beirut Lebanon tel +961 1 512513 ext. 366| fax +961 1 510474 tech support 1282 | http://www.idm.net.lb PLEASE CONSIDER THE ENVIRONMENT BEFORE YOU PRINT THIS E-MAIL Confidentiality Notice: The information in this document and attachments is confidential and may also be legally privileged. It is intended only for the use of the named recipient. Internet communications are not secure and therefore IDM does not accept legal responsibility for the contents of this message. If you are not the intended recipient, please notify us immediately and then delete this document. Do not disclose the contents of this document to any other person, nor take any copies. Violation of this notice may be unlawful. -Original Message- From: bind-users-bounces+daniel.dawalibi=idm.net...@lists.isc.org [mailto:bind-users-bounces+daniel.dawalibi=idm.net...@lists.isc.org] On Behalf Of Kostas Zorbadelos Sent: Wednesday, March 05, 2014 3:16 PM To: Bind Users Mailing List Subject: Sporadic but noticable SERVFAILs in specific nodes of an anycast resolving farm running BIND Greetings to all, we operate an anycast caching resolving farm for our customer base, based on CentOS (6.4 or 6.5), BIND (9.9.2, 9.9.5 or the stock CentOS package BIND 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1) and quagga (the stock CentOS package). The problem is that we have noticed sporadic but noticable SERVFAILs in 3 out of 10 total machines. Cacti measurements obtained via the BIND XML interface show traffic from 1.5K queries/sec (lowest loaded machines) to 15K queries/sec (highest). The problem is that in 3 specific machines in a geolocation with a BIND restart we notice after a period of time that can range between half an hour and several hours SERVFAILs in resolutions. The 3 machines do not have the highest load in the farm (6-8K q/sec). The resolution problems are noticable in the customers ending up in these machines but do not show up as high numbers in the BIND XML Resolver statistics (ServFail number). We reproduce the problem, by querying for a specific domain name using a loop of the form while [ 1 ]; do clear; rndc flushname www.linux-tutorial.info; sleep 1; dig www.linux-tutorial.info @localhost; sleep 2; done | grep SERVFAIL The www.linux-tutorial.info is not the only domain experiencing resolution problems of course. The above loop can run for hours even without issues on low-traffic hours (night, after a clean BIND restart) but during the day it shows quite a few SERVFAILs, which affect other domains as well. During the problem we notice with tcpdump, that when SERVFAIL is produced, no query packet exits the server for resolution. We have noticed nothing in BIND logs (we even tried to raise debugging levels and log all relevant categories). An example capture running the above loop: # tcpdump -nnn -i any -p dst port 53 or src port 53 | grep 'linux-tutorial' tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes 14:33:03.590908 IP6 ::1.53059 ::1.53: 15773+ A? www.linux-tutorial.info. (41) 14:33:03.591292 IP 83.235.72.238.45157 213.133.105.6.53: 19156% [1au] A? www.linux-tutorial.info. (52) Success 14:33:06.664411 IP6 ::1.45090 ::1.53: 48526+ A? www.linux-tutorial.info. (41) 14:33:06.664719 IP6 2a02:587:50da:b::1.23404 2a00:1158:4::add:a3.53: 30244% [1au] A? www.linux-tutorial.info. (52) Success 14:33:31.434209 IP6 ::1.43397 ::1.53: 26607+ A? www.linux-tutorial.info. (41) SERVFAIL 14:33:43.672405 IP6 ::1.58282 ::1.53: 27125+ A? www.linux-tutorial.info. (41) SERVFAIL 14:33:49.706645 IP6 ::1.54936 ::1.53: 40435+ A? www.linux-tutorial.info. (41) 14:33:49.706976 IP6 2a02:587:50da:b::1.48961 2a00:1158:4::add:a3.53: 4287% [1au] A?
