Re: How to measure the impact of enabling DNSSEC?
Lawrence K. Chen, P.Eng. lkc...@ksu.edu 2013-01-25 17:57: - Original Message - On Wed, Jan 23, 2013 at 11:38 AM, Augie Schwer augie.sch...@gmail.com wrote: On Tue, Jan 22, 2013 at 2:32 PM, Mark Andrews ma...@isc.org wrote: In message ca+fq9b-ym5w+ndxzzndzwnnqk-v29s19enb_myjbk-jrgbj...@mail.gmail.com, Augie Schwer wri tes: Would measuring the number of SERVFAIL entries in the query-errors category be a good indicator of what impact enabling DNSSEC has? DNSSEC is like wearing a seatbelt. 99.99% of the time it has no impact. And like a seatbelt it can save you (reject spoofed answers) or hinder you (lookups fail due to the zone not being re-signed) on rare occasions. That makes sense to me; I was looking for a way to quantify the affect enabling DNSSEC validation in a Bind server. Measuring SERVFAILs seems to be a good proxy to measure DNSSEC's impact. Thanks for the reply. SERVFAILS are not rare and come from many things. Looking at the delta after enabling validation might be interesting, but in my experience you are unlikely to see any difference beyond the jitter that will always be there. Except for a couple of major goofs early on by a few large orgs (e.g. NASA), the impact of validation is about zip. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com I heard a presentation from NIST on the .gov DNSSEC deployment last month...which was quite interesting on the kind of DNSSEC errors they been having. For me, users will frequently show up complaining at certain times of the year that they can't get to a .gov site from campus, but the site works fine on their home computer. Usually, when I dig through the logs, I will see its either they've stopped signing their zone or they got the rollover wrong. Of course, the users blame me for having DNSSEC validation on for our DNS servers and not that the .gov site made an error. Especially since they've waited to the last minute to submit a grant proposal to some .gov and waiting for the .gov site to fix the problem would probably take to long. I've had a very similar experience where I'm at. At least from the NIST presentation, I got information on how to contact somebody about these problems since its usually hard to send email to the listed RNAME. Can you share? It's true that usually it's some sort of email at that same domain, but if the resolving the domain isn't working, how are you going to get email there? OTOH, our domain went dark on August first of this yearbecause a non-DNS administrator takes care of all the registry accounts (because we don't have the authority to pay for registrations.) And, even though the DS line I sent her had the number for RSASHA256...she picked the wrong number on the registry's site. Not entirely sure...but got the impression that the website form said 8 - RSASHA256 so it should've been obvious. But, I've never seen that page. This was the first year that we have published our DS with our registry. Though things didn't break completelybecause I maintain our record on ISC's DLV. And, resolvers set to use DLV could validate our domain. Things from my home were kind of weird, because I found out that one of my broadband connections uses DLV while the other doesn't. What was fun was that I had done a 2 month window for the KSK rolloverBut, the person that updates our registry record waited to the end of July to finally update it. I did the DLV update on July 1st. Mainly because the year before I had used a shorter window, and I forgot to update DLV which I seem to recall required a bit of extra work to get it to validate my domain with them again. Plus I was doing a transition from RSASHA1 to RSASHA256. Not sure how I'm going to do rollover next yearI debating going to a longer lifetime KSK. Our parent zone isn't signed yet, though we do have a few domains in DLV which works pretty well from what I can tell. There are a few brain dead resolvers out there (w3.org was one if I recall correctly), that respect the signatures of the non-DLV zones even though they have an incomplete chain of trust, so that's caused us a few problems, mostly in pointing out a few of our mistakes (eg: lazy zone delegation [1]). Still, better to wade in than to jump in. On the whole DNSSEC has been largely uneventful. Key rollover is a non-trivial task though, one that I'm still working through automating and monitoring. Cheers, Brian [1] https://www.isc.org/wordpress/dnssec-and-lazy-delegation/ signature.asc Description: 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 DS vs DNSKEY record publication order question (wrt key algorithm rollover)
Tony Finch d...@dotat.at 2013-01-17 12:02: Brian Kroth bpkr...@gmail.com wrote: RFC 4035 sec 2.2 says There MUST be an RRSIG for each RRset using at least one DNSKEY of each algorithm in the zone apex DNSKEY RRset. The apex DNSKEY RRset itself MUST be signed by each algorithm appearing in the DS RRset located at the delegating parent (if any). This says to me that you can have extra DNSKEY records (that don't yet have a corresponding DS pair upstream), but not extra DS records (that don't yet have a corresponding DNSKEY downstream), since every DS records must have a key and sig associated with it. Be careful: this paragraph is about zones that are signed with more than one algorithm. It says that you can't have a DS record for an algorithm that isn't used to sign a zone. It's fine to have DS records without matching DNSKEY records, provided there is another DS with the same algorithm that does have a matching DNSKEY record. This says to me that the RFC also acknowledges that things might/will get out of sync due to caching in DNS, but doesn't describe to me what resolvers do in that context. Do they complain that the DS they happened to choose to look for a valid chain of trust didn't work and throw the whole thing out, or do they just move along to the next one in the hopes that it might succeed? The latter. Given the latest RFC evidence I posted, I think my summary view is as follows, please correct me if it seems wrong: 1) DS records are just used to validate the chain of trust upstream for DNSKEY records found downstream, so there MUST exist a DS record for each DNSKEY/RRSIG chain you intend to have used for validating RRSIGs (though not for just standby keys that are listed in DNSKEY records but not signing), but there need not exist a DNSKEY/RRSIG chain for each DS record (which is what contradicts 4035 2.2). So, we could prepublish DS records without an issue, but DNSKEYs that are published must be validated by an existing chain of trust (DNSKEY/DS pair) before they can be used to validate other RRSIGs. That doesn't sound quite right to me. It's probably easiest to work upwards: Each RRset in a zone must be signed by a private key corresponding to one of the zone's DNSKEY RRs. Different RRsets can be signed by different keys. In particular, it is common for the DNSKEY RRset to be signed by a different key (a key-signing key) from the rest of the zone (which uses a zone-signing key); there may be more differences during a key rollover. The KSKs are special in that they authenticate the zone's keys. For a zone to be secure there must be a DS record in the parent corresponding to a KSK. If a particular DNSKEY is not self-signed then it fails to prove the zone admin has both private and public halves of the key. DS records corresponding to ZSKs are useless. There can be extra DS records and extra DNSKEY records. They are ignored if they aren't usable as part of a validation chain. So the usual chain of authentication is parent RRSIG(DS)child DS- DNSKEY(ksk) - RRSIG(DNSKEY) DNSKEY(ksk) DNSKEY(zsk) - RRSIG(A,NS,MX etc) A,NS,MX etc If you are signing with multiple algorithms then it must be possible to validate the zone using each algorithm by itself. That is, each algorithm must have a ZSK and a KSK and an RRSIG on every record. The zone is considered bogus if it is bogus according to any of the algorithms. A validator knows whether to expect multiple algorithms for a zone by examining its DS RRset in the parent. So for an algorithm rollover you need to get all the DNSKEYs and RRSIGs for the new algorithm in place before adding it to the DS RRset, and you must remove the old algorithm from the DS RRset before removing its DNSKEYs and RRSIGs. You have much less flexibility than there is for normal key rollovers. Pay attention to the following sentence in RFC 6781 section 4.1.4! Note that the Double-DS KSK rollover method cannot be used, since that would introduce a parental DS of which the apex DNSKEY RRset has not been signed with the introduced algorithm. It is also worth looking at http://tools.ietf.org/html/draft-ietf-dnsop-dnssec-key-timing You do not need to follow the timing restrictions in RFC 5011 unless you support users that have configured a trust anchor for your zone. If you only support the normal validation chain from the root then RFC 5011 is not relevant. Tony. Thanks, this is pretty clear. I think it just means that if I want to script key algorithm rollover (the answer here might just be don't [1]), then I at least have to maintain the dsset- files myself since the ones obtained from dnssec-signzone just include everything that was used to sign things with and during an algorithm rollover, I may need/wish to either not publish a DS record yet, or remove a DS record from publication prior to removing the signatures (so that things timeout in the right order). I guess my last confusion is, how does the REVOKE bit on the old
Re: DNSSEC DS vs DNSKEY record publication order question (wrt key algorithm rollover)
Brian Paul Kroth bpkr...@gmail.com 2013-01-15 23:19: Hello All, First, I'm not currently on the list, so please CC if me if you could. Let's try this again now that I'm on the list. Next, I've been working on some scripts to get KSK rotation semi-automated or at least alerting in our environment and I've got some questions about the DS record requirements and their relation to the files generated and included by dnssec-signzone's smart signing feature. RFC 4035 sec 2.2 says There MUST be an RRSIG for each RRset using at least one DNSKEY of each algorithm in the zone apex DNSKEY RRset. The apex DNSKEY RRset itself MUST be signed by each algorithm appearing in the DS RRset located at the delegating parent (if any). This says to me that you can have extra DNSKEY records (that don't yet have a corresponding DS pair upstream), but not extra DS records (that don't yet have a corresponding DNSKEY downstream), since every DS records must have a key and sig associated with it. RFC 4035 sec 2.4 says A DS RR SHOULD point to a DNSKEY RR that is present in the child's apex DNSKEY RRset, and the child's apex DNSKEY RRset SHOULD be signed by the corresponding private key. DS RRs that fail to meet these conditions are not useful for validation, but because the DS RR and its corresponding DNSKEY RR are in different zones, and because the DNS is only loosely consistent, temporary mismatches can occur. This says to me that the RFC also acknowledges that things might/will get out of sync due to caching in DNS, but doesn't describe to me what resolvers do in that context. Do they complain that the DS they happened to choose to look for a valid chain of trust didn't work and throw the whole thing out, or do they just move along to the next one in the hopes that it might succeed? RFC 5011 sec 6.6 says 1. Generate a new DNSKEY and DS record and provide the DS record to the parent along with DS records for the old keys. 2. Once the parent has published the DSs, add the new DNSKEY to the RRSet and revoke ALL of the old keys at the same time, while signing the DNSKEY RRSet with all of the old and new keys. 3. After 30 days, stop publishing the old, revoked keys and remove any corresponding DS records in the parent. This says to me that DS records SHOULD be published before the DNSKEY is, which seems to contradict the first quote. To add some more confusion, RFC 4641 (now 6781) sec 4.2.4 also mentions standby keys and pushing DS records without DNSKEY records for KSK keys. The way to deal with stand-by keys differs for ZSKs and KSKs. To make a stand-by ZSK, you need to publish its DNSKEY RR. To make a stand-by KSK, you need to get its DS RR published at the parent. Why to the bind-users list you ask? Well, I'm trying to figure out if the dsset-* files generated by the smart signing feature of dnssec-signzone -S are smart enough to be usable for key rotation inclusion and warning scripts, or if I need to come up with that logic on my own and generate and include DS records separately from the -g option. I think it gets particularly tricky when you start considering things like key algorithm rollover where one needs to (I think) first yank the DS records, wait, then revoke the old algorithm keys, wait, then yank the keys (mostly due to the first quote I posted). If the parent and child are on the same server and being resigned during that waiting period, then dnssec-signzone will continue to overwrite and include the olds keys in the dsset-* files, and the -g option would normally just include them in the parent. Unless I've misinterpreted something above, the only way around that that I see is to maintain your own DS records in the parent zones (whether they're local or remote), including them manually (ie: via perl/db :), and specifically *not* using the -g option (which makes me sad). Anyways, thoughts, opinions, advice? Given the latest RFC evidence I posted, I think my summary view is as follows, please correct me if it seems wrong: 1) DS records are just used to validate the chain of trust upstream for DNSKEY records found downstream, so there MUST exist a DS record for each DNSKEY/RRSIG chain you intend to have used for validating RRSIGs (though not for just standby keys that are listed in DNSKEY records but not signing), but there need not exist a DNSKEY/RRSIG chain for each DS record (which is what contradicts 4035 2.2). So, we could prepublish DS records without an issue, but DNSKEYs that are published must be validated by an existing chain of trust (DNSKEY/DS pair) before they can be used to validate other RRSIGs. 2) dnssec-signzone probably generates the right dsset-* files (Does the Right Thing TM) and can be included without much thought. 3) With the above, in an algorithm rollover, I should be able to do something like this: - Generate keys with a new algorithm and publish them, but don't activate them yet. #
