Re: DNSSEC not populating parent zone files with DS records
On Fri, Sep 30, 2011 at 6:16 PM, Hauke Lampe la...@hauke-lampe.de wrote: Aside from the missing DS, I don't see why BIND complains about the NXDOMAIN response at first and then returns that cached record set in response to later queries for the same name. dig +sigchase validates it, if provided with the nau.edu DNSKEY: The issue can be seen by querying the authoritative source, rather than what the resolver returns. As someone posted earlier, the cause of the issue is the lack of NS RRs for extended.nau.edu in the nau.edu zone. Prior to DNSSEC deployment this wasn't really an issue (even though it was certainly a misconfiguration) if all the authoritative servers for the parent zone were also authoritative for the child zone. In this case the parent authoritative servers knew and could properly respond with the NS RRs. However, the DS RR is a new beast, and even though it carries the name of the child zone (e.g., extended.nau.edu), the parent zone (e.g., nau.edu) answers authoritatively for that record type. So when querying for DS vs. other record types the responses are different: $ dig @ns1.nau.edu extended.nau.edu ds | grep status ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 39613 $ dig @ns1.nau.edu extended.nau.edu ns | grep status ;; -HEADER- opcode: QUERY, status: NOERROR, id: 28073 DS queries in this case result in NXDOMAIN for the name because the parent zone has no records of that name (because of the lack of NS RRs for the child). NS records, however, return NOERROR because the response comes from the child zone which has records of that name. The resolver returns inconsistent responses based on its configuration (validation, which causes querying for DS RRs) and the state of its cache. The lack of NS RRs in the parent is also shown in the DNSViz output for extended.nau.edu: http://dnsviz.net/d/extended.nau.edu/dnssec/ Regards, Casey ___ 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
ZSK pre-publish
I have a few static zones that I sign via script keydir = directory for both KSK and ZSK $zone = zone file /usr/local/sbin/dnssec-signzone -S -g -a -H 10 -3 $SALT -K keydir $zone Fetching KSK 4054/RSASHA256 from key repository. Fetching ZSK 36948/RSASHA256 from key repository. Fetching ZSK 65304/RSASHA256 from key repository. Verifying the zone using the following algorithms: RSASHA256. Zone signing complete: Algorithm: RSASHA256: KSKs: 1 active, 0 stand-by, 0 revoked ZSKs: 2 active, 0 stand-by, 0 revoked My question is that both zsk's are published, how do I make 1 standby Thx CT ___ 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: ZSK pre-publish
I have a few static zones that I sign via script keydir = directory for both KSK and ZSK $zone = zone file /usr/local/sbin/dnssec-signzone -S -g -a -H 10 -3 $SALT -K keydir $zone Fetching KSK 4054/RSASHA256 from key repository. Fetching ZSK 36948/RSASHA256 from key repository. Fetching ZSK 65304/RSASHA256 from key repository. Verifying the zone using the following algorithms: RSASHA256. Zone signing complete: Algorithm: RSASHA256: KSKs: 1 active, 0 stand-by, 0 revoked ZSKs: 2 active, 0 stand-by, 0 revoked My question is that both zsk's are published, how do I make 1 standby Thx CT To be more specific , can I do this with the dnssec-signzone tool versus a $include/stand-by-key in the zone file Thx CT ___ 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: ZSK pre-publish
On 01/10/2011 09:25, CT wrote: I have a few static zones that I sign via script keydir = directory for both KSK and ZSK $zone = zone file /usr/local/sbin/dnssec-signzone -S -g -a -H 10 -3 $SALT -K keydir $zone Fetching KSK 4054/RSASHA256 from key repository. Fetching ZSK 36948/RSASHA256 from key repository. Fetching ZSK 65304/RSASHA256 from key repository. Verifying the zone using the following algorithms: RSASHA256. Zone signing complete: Algorithm: RSASHA256: KSKs: 1 active, 0 stand-by, 0 revoked ZSKs: 2 active, 0 stand-by, 0 revoked My question is that both zsk's are published, how do I make 1 standby To be more specific , can I do this with the dnssec-signzone tool versus a $include/stand-by-key in the zone file The trick is to use dnssec-settime modify the dates built into your key by dnssec-keygen. Or equivalently to use dnssec-keygen with appropriate flags to set the 'Activate' date (not to mention Inactive and Delete) some time in the future. So --- this key is active now: % dnssec-settime -p all Kinfracaninophile.co.uk.+005+04664.private Created: Sat Aug 13 07:40:28 2011 Publish: Sat Aug 13 07:40:28 2011 Activate: Sat Sep 10 07:40:28 2011 Revoke: UNSET Inactive: Sat Oct 8 07:40:28 2011 Delete: Sat Oct 8 07:40:28 2011 but this key is only published and will activate in a week: % dnssec-settime -p all Kinfracaninophile.co.uk.+005+44132.private Created: Sat Sep 10 09:01:24 2011 Publish: Thu Jan 1 01:00:00 1970 Activate: Sat Oct 8 09:01:24 2011 Revoke: UNSET Inactive: Sat Nov 5 08:01:24 2011 Delete: Sat Nov 5 08:01:24 2011 dnssec-signzone will grok all the built-in dates and do the right thing when you sign the zone. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW 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 not populating parent zone files with DS records
On Fri, Sep 30, 2011 at 10:26:34PM +, Raymond Drew Walker wrote: In our initial implementation of DNSSEC, we chose to try out the auto functionalities in version 9.8.0 P4 ie. using auto-dnssec maintain in all master zones. When going live, we found that though all zones that we are acting as master for would populate their own DS records, but there would be no population of a child zone's DS record in the corresponding parent master zone file. The ARM for 9.8.1 has this to say about dnssec-signzone: Any keyset files corresponding to secure subzones should be present. The zone signer will generate NSEC, NSEC3 and RRSIG records for the zone, as well as DS for the child zones if '-g' is specified. If '-g' is not specified, then DS RRsets for the secure child zones need to be added manually. I take that to mean that if I have a pair of zones served by the same master, dnssec-signzone will figure out the relationship and install DS records in the parent zone. However, that assumes two things - that both zones are on the same master (as seems to be the case for you), and that there are NS records in the parent to provide a delegation point (which doesn't seem to be true for nau.edu and extended.nau.edu, at least). I couldn't tell whether this also applies to auto-dnssec; either the ARM doesn't say or I missed it ;) We have since backed out DNSSEC until we can get a resolution of the issue. Incidentally, you haven't - you're still serving a signed zone for nau.edu and extended.nau.edu, which causes the problems noted in the other responses to your original note. I think you could fix it very quickly though, by adding the NS records to the nau.edu zone. Bill. ___ 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: ZSK pre-publish
On 10/01/2011 04:40 AM, Matthew Seaman wrote: On 01/10/2011 09:25, CT wrote: I have a few static zones that I sign via script keydir = directory for both KSK and ZSK $zone = zone file /usr/local/sbin/dnssec-signzone -S -g -a -H 10 -3 $SALT -K keydir $zone Fetching KSK 4054/RSASHA256 from key repository. Fetching ZSK 36948/RSASHA256 from key repository. Fetching ZSK 65304/RSASHA256 from key repository. Verifying the zone using the following algorithms: RSASHA256. Zone signing complete: Algorithm: RSASHA256: KSKs: 1 active, 0 stand-by, 0 revoked ZSKs: 2 active, 0 stand-by, 0 revoked My question is that both zsk's are published, how do I make 1 standby To be more specific , can I do this with the dnssec-signzone tool versus a $include/stand-by-key in the zone file The trick is to use dnssec-settime modify the dates built into your key by dnssec-keygen. Or equivalently to use dnssec-keygen with appropriate flags to set the 'Activate' date (not to mention Inactive and Delete) some time in the future. So --- this key is active now: % dnssec-settime -p all Kinfracaninophile.co.uk.+005+04664.private Created: Sat Aug 13 07:40:28 2011 Publish: Sat Aug 13 07:40:28 2011 Activate: Sat Sep 10 07:40:28 2011 Revoke: UNSET Inactive: Sat Oct 8 07:40:28 2011 Delete: Sat Oct 8 07:40:28 2011 but this key is only published and will activate in a week: % dnssec-settime -p all Kinfracaninophile.co.uk.+005+44132.private Created: Sat Sep 10 09:01:24 2011 Publish: Thu Jan 1 01:00:00 1970 Activate: Sat Oct 8 09:01:24 2011 Revoke: UNSET Inactive: Sat Nov 5 08:01:24 2011 Delete: Sat Nov 5 08:01:24 2011 dnssec-signzone will grok all the built-in dates and do the right thing when you sign the zone. Cheers, Matthew ___ 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 Matthew.. I have never usedthe dnssec-settime before.. Thank you .. CT ___ 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
On 10/01/11 04:54, Bill Owens wrote: On Fri, Sep 30, 2011 at 10:26:34PM +, Raymond Drew Walker wrote: In our initial implementation of DNSSEC, we chose to try out the auto functionalities in version 9.8.0 P4 ie. using auto-dnssec maintain in all master zones. When going live, we found that though all zones that we are acting as master for would populate their own DS records, but there would be no population of a child zone's DS record in the corresponding parent master zone file. The ARM for 9.8.1 has this to say about dnssec-signzone: Any keyset files corresponding to secure subzones should be present. The zone signer will generate NSEC, NSEC3 and RRSIG records for the zone, as well as DS for the child zones if '-g' is specified. If '-g' is not specified, then DS RRsets for the secure child zones need to be added manually. I take that to mean that if I have a pair of zones served by the same master, dnssec-signzone will figure out the relationship and install DS records in the parent zone. However, that assumes two things - that both zones are on the same master (as seems to be the case for you), and that there are NS records in the parent to provide a delegation point (which doesn't seem to be true for nau.edu and extended.nau.edu, at least). I couldn't tell whether this also applies to auto-dnssec; either the ARM doesn't say or I missed it ;) I am pretty sure that it doesn't, at least not in 9.8.1. There's no place to specify the location of the dsset or keyset files in named.conf, and that's what the signer process needs to insert the DS records. When I put dsset files in the parent zone's directory with the key files and did 'rndc sign', the DS records still didn't get automagically put in. There are ways of getting the DS records into the zone(s). Here are some steps that I took on some test zones: 0. First, I made sure there were proper delegation NS records in the parent zone(s)! 1. Ensure that there are no pending dynamic updates and run 'rndc freeze'. 2. Create a central directory to hold the keyset and dsset files. I used /var/named/etc/namedb/master/signed-zonefiles/keysets on a FreeBSD system with named running in a chroot environment. 3. Assuming keys have already been generated, run the following command in the *child* zones first, substituting sub1.gost.radiofreebeer.net for your child zone and substituting 'zone.db.signed' for the signed version of the zone that named is configured to read on startup: /usr/sbin/dnssec-signzone -C -g -p -d /var/named/etc/namedb/master/signed-zonefiles/keysets -o sub1.gost.radiofreebeer.net. -e +518400 -N unixtime zone.db.signed K*.private This will produce zone.db.signed.signed. NOTE that this assumes that each zone has its own directory with its keys in that directory (and no other zone's keys). 4. Then run the same command on any parent of any signed zone, *after* you have run the command on the signed child zone. 5. For every *parent* zone, you will need to 'mv zone.db.signed.signed zone.db.signed' so that the version with the DS records will go into production. This is only necessary with parent zones, but it can also be done on the child zones just to keep things clean. 6. 'rndc thaw' You can also use a signing tool like zkt, which will basically generate all of the keys and do the DSification of parent zones automatically. There are other features of tools like zkt and opendnssec that auto-dnssec can't (yet) do, such as key rollovers. auto-dnssec will do rollovers, once the keys with proper activation and inactivation dates have been created. But something else needs to generate the keys, set the metadata according to a policy defined by the administrator, and remove stale keys so that auto-dnssec can do its work. As far as I can tell, there isn't yet an auto-dnssec-savvy tool that can handle these tasks so it needs to be custom-scripted. We have since backed out DNSSEC until we can get a resolution of the issue. Incidentally, you haven't - you're still serving a signed zone for nau.edu and extended.nau.edu, which causes the problems noted in the other responses to your original note. I think you could fix it very quickly though, by adding the NS records to the nau.edu zone. Bill's right--this needs to be fixed right away. michael ___ 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
