RE: DNSSEC Signing Key Questions
Hello, For 3) automate zone signing and zsk roll-over I know of no tools that are readily available - there are appliances (look in the IPAM world of products), that handle DNSSEC for you. However, I have in our DNSSEC workshop course environment a setup that looks at time stamps of Linux files : - zone data is stored in files - when the (unsigned) data has newer time stamp then signed data, script regenerates RRSIGs à to resign a zone, simply touch the file with unsigned data (eg once a week) - the script that generates RRSIGs does so with all available keys à to perform ZSK rollover, simply add new ZSK/delete old ZSK (at appropriate time) and touch the file with unsigned data (!!! Do respect key timing for deleting the old ZSK !!!) - same principle works for KSK rollover as well, but the challenge there is to inform the parent of new KSK (!!! + key timing matters !!!) Using time stamps of files kind of uses the Linux file system as database; Should work if the number of files is not too big one would have to consider using a real DB for larger number of zones. Success with your move towards DNSSEC. Kind regards, Marc Lampo Security Officer EURid From: McConville, Kevin [mailto:kmcconvi...@albany.edu] Sent: 04 October 2011 09:10 PM To: bind-users@lists.isc.org Subject: DNSSEC Signing Key Questions Im new to this list, so please bear with me if these are/seem like newbie questions. We are currently evaluating a DNSSEC implementation. We have several static zones that we would like to implement first. We are currently using ISC Bind 9.7.4 In the test environment (1) Authoritative dns server and (1) Resolver dns server, both running RHEL 5.7. We do have an on-hold Opendnssec server w/softhsm (we are trying to look at the built-in utilities of isc bind first). We are trying to make the DNSSEC piece as automatic as possible, so here are where we are having issues. 1) Is there any way to have the zsk be auto-generated based upon the inactive date listed in the zsk meta-data? I know we can pre-publish and then use dnssec-settime to change the meta-data, but still very hands-on. 2) With a static zone, are the update-policy local and auto-dnssec maintain options invalid/dont work? From the docs, they look like they are only for automation of dynamic zones? 3) Are there any ways to automate zone signing and zsk generation/roll-over with a totally static zone environment? 4) What key-management, zone-signing management utilities or programs have you found useful/helpful? Any suggestions, comments, or questions are greatly appreciated. Thank you in advance. Thanks, -Kevin Kevin McConville University at Albany ___ 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: dnssec config sanity check
On Tue, Oct 04, 2011 at 03:49:25PM -0700, Paul B. Henson hen...@acm.org wrote a message of 40 lines which said: Other than knowing a given domain had an issue, you have no idea what caused it, or what tool they may have been using, and it is only an assumption that the issue arose from a custom program... Not true. For every problem reported by the tool, I contacted the managers of the domain, both to report they have an issue and to ask them what system they were using. So, I'm pretty confident that OpenDNSSEC had no such issue. ___ 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
named resolution problem
Hi all, I have a problem with named (both bind9.3 and bind9.7) and resolution of www.myspace.fr; the problem is not present in dnscache (of djbdns suite) or asking resolution to google public dns (they run a Google implementation of dns protocol). If you ask a resolver/cache server running named the resolution of name www.myspace.fr it returns (SERVFAIL), if you ask the same to a dnscache server it correctly resolves to the ip address. The problem seems related to two CNAME resolution with tools of bind suite (the problem is present also with dig, I think it uses the same routine of named). the answer section from a working resolver is something like: www.myspace.fr. 86395 IN CNAME wwwi.myspace.com. wwwi.myspace.com. 3595IN CNAME www-lb.myspaceweb.akadns.net. www-lb.myspaceweb.akadns.net. 30 IN A 216.178.39.11 asking to a named resolver it seems it cannot resolve the last cname www.myspace.fr. 86395 IN CNAME wwwi.myspace.com. wwwi.myspace.com. 3595IN CNAME www-lb.myspaceweb.akadns.net. Simulating the recursion, going top down from root nameservers, and asking as the last step the resolution of www-lb.myspaceweb.akadns.net to ze.akadns.net or one of the other autoritarive akadns server it give the correct ip address. The path seems this: . - .fr. - .myspace.fr. autoritative for myspace.fr. are ns1.myspace.com and ns2.myspace.com asking A records for www.myspace.fr to ns1.myspace.com it gives you the two CNAME Named seems unable to resolve this CNAME. I tried to deep debug the problem without success. We have customers affected by this problem and we solved with the definition of a zone for myspace.fr that forwards to a djbdns dnscache server that correctly resolves; This is intended as workaround till we will fix the problem on named/bind. I also suspected it was something related do EDNS0 but i quite sure this is not the problem because google public dns resolver implement EDNS and they don't have the problem. Are your named servers affected by the same problem ? Can you try this name resolution on your servers ? Have you any idea on how to solve the problem ? Have you further tests to suggest us ? Thanx for you patience and forgive me for my bad english Hope someone can help Bye ___ 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 resolution problem
On 05.10.2011 12:58, Roberto Bosticardo wrote: If you ask a resolver/cache server running named the resolution of name www.myspace.fr it returns (SERVFAIL), if you ask the same to a dnscache server it correctly resolves to the ip address. BIND doesn't like NS records resolving to CNAMEs: The domain is delegated to two servers: myspace.fr. 60 IN NS ns1.myspace.com. myspace.fr. 60 IN NS ns2.myspace.com. Resolving the server names reveals CNAMEs: ns1.myspace.com.60 IN CNAME DNS11.COTDNS.net. ns2.myspace.com.60 IN CNAME DNS12.COTDNS.net. That is a configuation error at myspace.com and BIND returns SERVFAIL. Unbound and dnscache are more forgiving in this case. Hauke. signature.asc Description: OpenPGP digital 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
DNSSEC SERVFAIL when parent zone has no DS record
Hi, Dig returns SERVFAIL while trying to resolve a dnssec enabled zone without DS record in parent zone. For example, I have these two DNSSEC enabled zones: domain.com subdomain.domain.com domain.com zone has NO DS record for subdomain.domain.com zone, and subdomain.domain.com has an A record for the zone, and an A record for www . If I query subdomain.domain.com , I get SERVFAIL from dig and these log messages: 03-Oct-2011 11:03:07.893 validating @0x7f9ea305b2d0: domain.com SOA: no valid signature found 03-Oct-2011 11:03:07.894 createfetch: domain.com DS 03-Oct-2011 11:03:07.894 validating @0x7f9ea305df70: domain.com NSEC: no valid signature found 03-Oct-2011 11:03:07.895 createfetch: domain.com DS 03-Oct-2011 11:03:07.896 error (broken trust chain) resolving 'subdomain.domain.com/DNSKEY/IN': x.x.x.x#53 03-Oct-2011 11:03:07.896 error (broken trust chain) resolving 'subdomain.domain.com/A/IN': x.x.x.x#53 If I run the query again, I get NXDOMAIN (from cache). So I can't query subdomain.domain.com zone. Now, if I query www.subdomain.domain.com I get the same, but when I run the query again I get a valid answer (from cache). I know the DS is not configured properly and so DNSSEC shouldn't work, but bind shouldn't behave like this. If the zone is not configured properly, bind should query it anyway, the same way it does when the zone isn't signed. I didn't find any related bugs. Is this a known bug? Btw, I'm using bind 9.7.3 from debian 6.0.2. Thanks. -- Sergio Roberto Charpinel Jr. ___ 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: DNSSEC SERVFAIL when parent zone has no DS record
Hello, You do not provide sufficient data for diagnose ! But it seems to me that bind is not complaining about the DS of subdomain.domain.com. but rather about a missing RRSIG for a NSEC when fetching DS of domain.com. Admittingly, logmessages could be somewhat more userfriendly, but I'd check if domain.com. itself is properly signed. Kind regards, Marc Lampo -Original Message- From: Sergio Charpinel Jr. [mailto:sergiocharpi...@gmail.com] Sent: 05 October 2011 01:57 PM To: bind-users@lists.isc.org Subject: DNSSEC SERVFAIL when parent zone has no DS record Hi, Dig returns SERVFAIL while trying to resolve a dnssec enabled zone without DS record in parent zone. For example, I have these two DNSSEC enabled zones: domain.com subdomain.domain.com domain.com zone has NO DS record for subdomain.domain.com zone, and subdomain.domain.com has an A record for the zone, and an A record for www . If I query subdomain.domain.com , I get SERVFAIL from dig and these log messages: 03-Oct-2011 11:03:07.893 validating @0x7f9ea305b2d0: domain.com SOA: no valid signature found 03-Oct-2011 11:03:07.894 createfetch: domain.com DS 03-Oct-2011 11:03:07.894 validating @0x7f9ea305df70: domain.com NSEC: no valid signature found 03-Oct-2011 11:03:07.895 createfetch: domain.com DS 03-Oct-2011 11:03:07.896 error (broken trust chain) resolving 'subdomain.domain.com/DNSKEY/IN': x.x.x.x#53 03-Oct-2011 11:03:07.896 error (broken trust chain) resolving 'subdomain.domain.com/A/IN': x.x.x.x#53 If I run the query again, I get NXDOMAIN (from cache). So I can't query subdomain.domain.com zone. Now, if I query www.subdomain.domain.com I get the same, but when I run the query again I get a valid answer (from cache). I know the DS is not configured properly and so DNSSEC shouldn't work, but bind shouldn't behave like this. If the zone is not configured properly, bind should query it anyway, the same way it does when the zone isn't signed. I didn't find any related bugs. Is this a known bug? Btw, I'm using bind 9.7.3 from debian 6.0.2. Thanks. -- Sergio Roberto Charpinel Jr. ___ 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: DNSSEC SERVFAIL when parent zone has no DS record
Marc, After suplying DS and the respective NS record for subdomain in the parent zone (domain.com), it works. If I disable dnssec in my recursive server, it also works. So, if a zone is not signed properly (or doesnt have DS records) the query will fail? Isn't it better to query those misconfigured servers without DNSSEC, just like it does when the zone is not signed? And what about the second case, when I query www.subdomain.domain.com . If I run two queries, the first fail with the same error, but the second works (I think the second comes from cache). How can I provide more data for diagnose?? Thanks. 2011/10/5 Marc Lampo marc.la...@eurid.eu: Hello, You do not provide sufficient data for diagnose ! But it seems to me that bind is not complaining about the DS of subdomain.domain.com. but rather about a missing RRSIG for a NSEC when fetching DS of domain.com. Admittingly, logmessages could be somewhat more userfriendly, but I'd check if domain.com. itself is properly signed. Kind regards, Marc Lampo -Original Message- From: Sergio Charpinel Jr. [mailto:sergiocharpi...@gmail.com] Sent: 05 October 2011 01:57 PM To: bind-users@lists.isc.org Subject: DNSSEC SERVFAIL when parent zone has no DS record Hi, Dig returns SERVFAIL while trying to resolve a dnssec enabled zone without DS record in parent zone. For example, I have these two DNSSEC enabled zones: domain.com subdomain.domain.com domain.com zone has NO DS record for subdomain.domain.com zone, and subdomain.domain.com has an A record for the zone, and an A record for www . If I query subdomain.domain.com , I get SERVFAIL from dig and these log messages: 03-Oct-2011 11:03:07.893 validating @0x7f9ea305b2d0: domain.com SOA: no valid signature found 03-Oct-2011 11:03:07.894 createfetch: domain.com DS 03-Oct-2011 11:03:07.894 validating @0x7f9ea305df70: domain.com NSEC: no valid signature found 03-Oct-2011 11:03:07.895 createfetch: domain.com DS 03-Oct-2011 11:03:07.896 error (broken trust chain) resolving 'subdomain.domain.com/DNSKEY/IN': x.x.x.x#53 03-Oct-2011 11:03:07.896 error (broken trust chain) resolving 'subdomain.domain.com/A/IN': x.x.x.x#53 If I run the query again, I get NXDOMAIN (from cache). So I can't query subdomain.domain.com zone. Now, if I query www.subdomain.domain.com I get the same, but when I run the query again I get a valid answer (from cache). I know the DS is not configured properly and so DNSSEC shouldn't work, but bind shouldn't behave like this. If the zone is not configured properly, bind should query it anyway, the same way it does when the zone isn't signed. I didn't find any related bugs. Is this a known bug? Btw, I'm using bind 9.7.3 from debian 6.0.2. Thanks. -- Sergio Roberto Charpinel Jr. -- Sergio Roberto Charpinel Jr. ___ 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: DNSSEC SERVFAIL when parent zone has no DS record
After supplying NS's and DS in the parent zone, is that parent zone properly resigned ? (to generate NSEC(3) and RRSIG's) If you ask your validating caching name server for the DS of domain.com. do you get a proper reply with AD bit set ? If you ask your validating caching name server for the DS of subdomain.domain.com. do you get a proper reply with AD bit set ? (no idea yet about the www.subdomain.domain.com observations) Kind regards, Marc -Original Message- From: Sergio Charpinel Jr. [mailto:sergiocharpi...@gmail.com] Sent: 05 October 2011 02:22 PM To: Marc Lampo Cc: bind-users@lists.isc.org Subject: Re: DNSSEC SERVFAIL when parent zone has no DS record Marc, After suplying DS and the respective NS record for subdomain in the parent zone (domain.com), it works. If I disable dnssec in my recursive server, it also works. So, if a zone is not signed properly (or doesnt have DS records) the query will fail? Isn't it better to query those misconfigured servers without DNSSEC, just like it does when the zone is not signed? And what about the second case, when I query www.subdomain.domain.com . If I run two queries, the first fail with the same error, but the second works (I think the second comes from cache). How can I provide more data for diagnose?? Thanks. 2011/10/5 Marc Lampo marc.la...@eurid.eu: Hello, You do not provide sufficient data for diagnose ! But it seems to me that bind is not complaining about the DS of subdomain.domain.com. but rather about a missing RRSIG for a NSEC when fetching DS of domain.com. Admittingly, logmessages could be somewhat more userfriendly, but I'd check if domain.com. itself is properly signed. Kind regards, Marc Lampo -Original Message- From: Sergio Charpinel Jr. [mailto:sergiocharpi...@gmail.com] Sent: 05 October 2011 01:57 PM To: bind-users@lists.isc.org Subject: DNSSEC SERVFAIL when parent zone has no DS record Hi, Dig returns SERVFAIL while trying to resolve a dnssec enabled zone without DS record in parent zone. For example, I have these two DNSSEC enabled zones: domain.com subdomain.domain.com domain.com zone has NO DS record for subdomain.domain.com zone, and subdomain.domain.com has an A record for the zone, and an A record for www . If I query subdomain.domain.com , I get SERVFAIL from dig and these log messages: 03-Oct-2011 11:03:07.893 validating @0x7f9ea305b2d0: domain.com SOA: no valid signature found 03-Oct-2011 11:03:07.894 createfetch: domain.com DS 03-Oct-2011 11:03:07.894 validating @0x7f9ea305df70: domain.com NSEC: no valid signature found 03-Oct-2011 11:03:07.895 createfetch: domain.com DS 03-Oct-2011 11:03:07.896 error (broken trust chain) resolving 'subdomain.domain.com/DNSKEY/IN': x.x.x.x#53 03-Oct-2011 11:03:07.896 error (broken trust chain) resolving 'subdomain.domain.com/A/IN': x.x.x.x#53 If I run the query again, I get NXDOMAIN (from cache). So I can't query subdomain.domain.com zone. Now, if I query www.subdomain.domain.com I get the same, but when I run the query again I get a valid answer (from cache). I know the DS is not configured properly and so DNSSEC shouldn't work, but bind shouldn't behave like this. If the zone is not configured properly, bind should query it anyway, the same way it does when the zone isn't signed. I didn't find any related bugs. Is this a known bug? Btw, I'm using bind 9.7.3 from debian 6.0.2. Thanks. -- Sergio Roberto Charpinel Jr. -- Sergio Roberto Charpinel Jr. ___ 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: R: Bind DLZ and Postgres 8.4.8
On 04/10/11 21:38, Job wrote: Hello, everything is fine, i patched the source tree! Thank you, regards! Francesco Whose source tree? Is it the patch something that would be useful/appropriate to share here? Regards, Cathy ___ 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: DNSSEC SERVFAIL when parent zone has no DS record
Sergio Charpinel Jr. sergiocharpi...@gmail.com wrote: After suplying DS and the respective NS record for subdomain in the parent zone (domain.com), it works. That sounds like you had no delegation RRs in the parent zone. In that case the parent zone will contain a secure denial of existence of the child zone. If you have delegation NS RRs but no DS RRs, this is an insecure delegation in which the parent says the child zone exists but is not signed (at least not in a way that the parent can authenticate). How can I provide more data for diagnose?? Provide real zone names and name server IP addresses. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Rockall, Malin: West 6 to gale 8, increasing severe gale 9, perhaps storm 10 later. Very rough becoming high. Squally showers. Good, occasionally 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: DNSSEC SERVFAIL when parent zone has no DS record
On 10/5/2011 5:21 AM, Sergio Charpinel Jr. wrote: After suplying DS and the respective NS record for subdomain in the parent zone (domain.com), it works. If I disable dnssec in my recursive server, it also works. So, if a zone is not signed properly (or doesnt have DS records) the query will fail? Isn't it better to query those misconfigured servers without DNSSEC, just like it does when the zone is not signed? Without the necessary NS records in the parent, the zone was never correctly delegated. It worked, but only due to a fluke of being served on the same server as its parent zone. Implementing DNSSEC made you fix your zone. This is not a bad thing. There is no reason to try again without DNSSEC if you get a failure, because that failure means it didn't work. You may end up trying different authoritative servers if you get a failure (to work around poisoned or disrupted servers), but you don't ever fall back to non-DNSSEC lookups on zones that should be secure. AlanC -- a...@clegg.com 1.919.355.8851 signature.asc Description: OpenPGP digital 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: dnssec config sanity check
On 10/4/11 3:49 PM, Paul B. Henson hen...@acm.org wrote: dnssec is fairly complicated, and the issue of timing can be complex, but once the variables are determined than the actual procedures of implementation are pretty simple. Generate keys with appropriate publication, activation, inactivation, and deletion timings, and then use them ;). My hope from my initial posting was to get a little peer review of the appropriateness of the timings I've selected... Your initial hope is what I missed comments on... I found this: https://www.enisa.europa.eu/act/res/technologies/tech/gpgdnssec/at_download/ fullReport It is recommended that the transition of a KSK from the published state to the ready state (introduction time) lasts for 45 days (RFC 5011, Automated Updates of DNS Security (DNSSEC) Trust Anchors). If the parent of the zone is signed, the recommended introduction time (SPARTA) is one week. The recommended period during which a KSK is retired before it is removed from the zone (retirement time) is four weeks. For the ZSK, the recommended introduction time is four days and the retirement time is two weeks. What values are other folks using? -- By nature, men are nearly alike; by practice, they get to be wide apart. -- Confucius ___ 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: DNSSEC not populating parent zone files with DS records
-Original Message- From: Tony Finch d...@dotat.at Date: Tue, 4 Oct 2011 20:30:43 +0100 To: Raymond Walker ray.wal...@nau.edu Cc: bind-users@lists.isc.org bind-users@lists.isc.org Subject: Re: DNSSEC not populating parent zone files with DS records Raymond Drew Walker ray.wal...@nau.edu wrote: In testing, this pipe sets up the following for nsupdate which fails: Sorry, I forgot the TTL command. Adjust its value as you require... dig +noall +answer dnskey $child | dnssec-dsfromkey -f /dev/stdin $child | (echo zone $parent; echo ttl 3600; sed 's/^/update add /'; echo send) | nsupdate -l Thanks much, this makes much more sense. Am I also missing somewhere in the RFC where NS records of children zones need be populated in the parent? Is this something that has changed with the addition of DNSSEC? No, it has always been an error. See RFC 2181 section 6. DNSSEC just makes the breakage more obvious. After reading this, RFC1034, and conferring with the original implementor of DNS at our institution, I have a better wrangle on the NS issue. Child zone NS records were never populated in the parent because all zones were under the same name servers, and it just worked (circa the early 90's.) I mistakenly inherited on this understanding... until now. As for better automation of DNSSEC, my research lends little to no information on proper child/parent DS record population. I am curious about how to properly deploy in the future. My assumptions are the following: -Sign a zone, then insert it's corresponding DS data into it's parent by hand (nsupdate). -Keep track of update DS record data on a regular schedule. Potentially via nsupdate, by deleting all DS record data in the parent zone for said child, then inserting new DS records. Yikes, I was hoping auto-dnssec would handle these tasks. ;) Am I missing any elegant solutions? Much thanks to the list for their insightful comments... Raymond Walker Software Systems Engineer Sr. ITS Northern Arizona University ___ 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: dnssec config sanity check
On Wed, Oct 05, 2011 at 12:22:58AM -0700, Stephane Bortzmeyer wrote: Not true. For every problem reported by the tool, I contacted the managers of the domain, both to report they have an issue and to ask them what system they were using. So, I'm pretty confident that OpenDNSSEC had no such issue. Sorry then, that detail wasn't laid out in the paper... Prior to the implementation of key timing metadata and the ability for dnssec-signzone to automatically select what keys to use in bind 9.7, I could see how a third party tool to manage rollover for you could be useful. With it, the amount of wrapper to make it work in a simple scenario isn't that big. Assuming my selection of timings isn't broken, I'm reasonably confident our dnssec rollovers will procede smoothly without issues, and I'd rather use a little bit of custom local glue that fits perfectly into our existing deployment rather than try to bend a complicated tool to our will or change our deployment to match its idea of how things should work. -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768 ___ 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
