Re: DNSSEC adoption
Not really. Using ECDSA (or EdDSA) CSK is pretty lightweight even during rollover. Ondrej -- Ondřej Surý — ISC (He/Him) My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. > On 3. 8. 2022, at 19:10, Peter wrote: > > So people may be induced to try and squeeze replies into whatever > 512 or 1280 or 1500 bytes. Which means, they probably cannot use > more than one key, and so take possible redundancy out of the game. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC adoption
I generally agree with you - comments in line On 8/3/22 5:56 PM, Peter wrote: I see a two-fold issue with DNSSEC: 1. The wide-spread tutorials seem to explain a key rollover as an exceptional activity, a *change* that is infrequently done. And changes, specifically the infrequent ones, bring along the possibility of failure, mostly due to human error. Domains with Cloudflare seem to get Signed once -(KSK/DS - etc) and that's it! I don't see reason why this is so. DNSSEC can be fully automated (mine is), and then it can be done frequently, and the human factor is out of the loop. It is then no longer a change, but a regular operation that happens every without anybody even need noticing it. (Let'sEncrypt did the same for certificates, and that also works well.) Both my DNSSEC and Let's Encrypt are totally automated as well. I usually run two KSK's overlapping by 6 months - so plenty of "rollover" time. Other domains, there is only a second KSK for a week or so. 2. TCP seems still to be considered a second-class-citizen in the DNS world. (If I got the details right, TCP is only "optional", Agh! No. NOT OPTIONAL. One might see it as a fall-back for when UDP fails (Truncated) but it is completely necessary! and must only be tried as a second choice after receiving TC.) So people may be induced to try and squeeze replies into whatever 512 or 1280 or 1500 bytes. Which means, they probably cannot use more than one key, and so take possible redundancy out of the game. I do not currently know about how or where this issue could be tackled appropriately; I for my part have decided to happily ignore it, and am using *four* KSK, thereby supporting RFC 5011 and RFC 7344, all with one simple script - and anyway now I have the longest; here you can see it in action: https://dnsviz.net/d/daemon.contact/dnssec/ Let's see where this leads into problems; for now it appears not to. -- PMc Fair enough. And Elliptical Curve (Algo 13 ???) - so much shorter. ps - Algorithm rollovers can be fun!!! -- Mark James ELKINS - Posix Systems - (South) Africa m...@posix.co.za Tel: +27.826010496 OpenPGP_0xB6FA15470B82C101.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC adoption
I see a two-fold issue with DNSSEC: 1. The wide-spread tutorials seem to explain a key rollover as an exceptional activity, a *change* that is infrequently done. And changes, specifically the infrequent ones, bring along the possibility of failure, mostly due to human error. I don't see reason why this is so. DNSSEC can be fully automated (mine is), and then it can be done frequently, and the human factor is out of the loop. It is then no longer a change, but a regular operation that happens every without anybody even need noticing it. (Let'sEncrypt did the same for certificates, and that also works well.) 2. TCP seems still to be considered a second-class-citizen in the DNS world. (If I got the details right, TCP is only "optional", and must only be tried as a second choice after receiving TC.) So people may be induced to try and squeeze replies into whatever 512 or 1280 or 1500 bytes. Which means, they probably cannot use more than one key, and so take possible redundancy out of the game. I do not currently know about how or where this issue could be tackled appropriately; I for my part have decided to happily ignore it, and am using *four* KSK, thereby supporting RFC 5011 and RFC 7344, all with one simple script - and anyway now I have the longest; here you can see it in action: https://dnsviz.net/d/daemon.contact/dnssec/ Let's see where this leads into problems; for now it appears not to. -- PMc -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: DNSSEC adoption
> One more thing should *in theory* not matter much. Personally, I'm not too > happy about short TTLs. This trend is likely significantly undermining the > stability and redundancy of the internet as a whole already. In the days of limited, expensive hardware and slow links, long TTLs made sense. Our one vCPU name servers are almost wasting power serving up several hundred domains. To me it seems that a short TTL is going to let you route to a different server in case of outage in the absence of multicasting, etc. which may be overkill in some cases but a redundant server is adequate. How does this undermine stability and redundancy of the internet? Confidentiality Notice: This electronic message and any attachments may contain confidential or privileged information, and is intended only for the individual or entity identified above as the addressee. If you are not the addressee (or the employee or agent responsible to deliver it to the addressee), or if this message has been addressed to you in error, you are hereby notified that you may not copy, forward, disclose or use any part of this message or any attachments. Please notify the sender immediately by return e-mail or telephone and delete this message from your system. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC adoption
Am 2022-08-03 15:27, schrieb Bob Harold: I think the best way to soften the effect, and make DNSSEC much less brittle, without losing any of the security, is to reduce the TTL of the DS record in the parent zone (usually TLD's) drastically - from 2 days to like 30 minutes. That allows quick recovery from a failure. I realize that will cause an increase in DNS traffic, and I don't know how much of an increase, but the 24-48 hour TTL of the DS record is the real down-side of DNSSEC, and why it is taking me so long to try to develop a bullet-proof process before signing my zones. These days, companies of all sizes are using ultra-short TTLs of 60s (and I've seen less) for all sorts of "fail-over" mechanisms and load-balancing schemes. One more thing should *in theory* not matter much. Personally, I'm not too happy about short TTLs. This trend is likely significantly undermining the stability and redundancy of the internet as a whole already. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC adoption
On 03-Aug-22 09:27, Bob Harold wrote: I think the best way to soften the effect, and make DNSSEC much less brittle, without losing any of the security, is to reduce the TTL of the DS record in the parent zone (usually TLD's) drastically - from 2 days to like 30 minutes. That allows quick recovery from a failure. I realize that will cause an increase in DNS traffic, and I don't know how much of an increase, but the 24-48 hour TTL of the DS record is the real down-side of DNSSEC, and why it is taking me so long to try to develop a bullet-proof process before signing my zones. -- Bob Harold University of Michigan Yes, in planning for DNSSEC changes it's a good idea to include reducing TTLs, verifying the change, then increasing the TTLs. That means keeping track of important (I'd say non-automated) events, and reducing TTL a few days in advance. If you do that, you get the benefit of long TTLs most of the time. KSK rollover - probably the most common cause of errors - is not a frequent event. Then again, with proper planning, you don't make nearly as many mistakes. Also, while I haven't gotten around to migrating, for a new setup I'd look at the dnssec-policy in 9.16+, which appears to do most of the automation for you. All of it if you have a registrar who supports CDS/CDNSKEY, in which the parent zone pulls the new DS into itself. https://kb.isc.org/docs/dnssec-key-and-signing-policy Some issues have been reported on this mailing list, but from a distance it seems to be a great improvement and doing well. At this point, creating a new process doesn't seem like a great use of time...at least unless you've identified issues with the tools that you can't get fixed... The ISC folks working on dnssec-policy seem to have been responsive. FWIW Timothe Litt ACM Distinguished Engineer -- This communication may not represent the ACM or my employer's views, if any, on the matters discussed. OpenPGP_signature Description: OpenPGP digital signature -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: RE: DNSSEC adoption
I think the best way to soften the effect, and make DNSSEC much less brittle, without losing any of the security, is to reduce the TTL of the DS record in the parent zone (usually TLD's) drastically - from 2 days to like 30 minutes. That allows quick recovery from a failure. I realize that will cause an increase in DNS traffic, and I don't know how much of an increase, but the 24-48 hour TTL of the DS record is the real down-side of DNSSEC, and why it is taking me so long to try to develop a bullet-proof process before signing my zones. -- Bob Harold University of Michigan On Tue, Aug 2, 2022 at 2:21 PM Timothe Litt wrote: > > On 02-Aug-22 13:51, Brown, William wrote: > > my guess is that they see dnssec as fragile, have not seen _costly_ > dns subversion, and measure a dns outages in thousands of dollars a > minute. > > No one wants to be this > guy:http://www.dnssec.comcast.net/DNSSEC_Validation_Failure_NASAGOV_201201 > 18_FINAL.pdf > > so, to me, a crucial question is whether dnssec ccould be made to fail more > softly and/or with a smaller blast radius? > > randy > > I'm more of a mail guy than DNS, so yes, like hard v. soft fail in SPF. Or > perhaps some way of the client side deciding how to handle hard v./ soft > failure. > > As Mark has pointed out, validation is a client issue. Setting up DNSSEC > properly and keeping it running is for the server admin - which bind is > incrementally automating. > > For bind, the work-around for bad servers (which is mentioned in the > article) is to setup negative trust anchors in the client for zones that > fail. And notify the zone administrator to fix the problem. I usually > point them to a DNSVIZ report on their zone. > > The nasa.gov failure was avoidable. nasawatch, which is an excellent > resource for space news, jumped to an incorrect conclusion about the outage > - and never got the story straight. In fact, all validating resolvers > (including mine) correctly rejected the signatures. It wasn't comcast's > fault - they were a victim. > > It is an unfortunate reality that admins will make mistakes. And that > there is no way to get all resolvers to fix them - you can't even find all > the resolvers. (Consider systemd-resolved, or simply finding all the > recursive bind, powerdns, etc instances...) > > There is no global "soft" option - aside from unsigning the zone and > waiting for the TTLs to expire. And besides being a really bad idea, it's > easier to fix the immediate problem and learn not to repeat it. > > Long term, automation of the (re-)signing and key roll-overs will reduce > the likelihood of these outages. It is truly unfortunate that it's so late > in coming. > > It may take a flag day to get major resolver operators, dns servers, and > client resolvers all on the same page. I'm not holding my breath. > > Timothe Litt > ACM Distinguished Engineer > -- > This communication may not represent the ACM or my employer's views, > if any, on the matters discussed. > > > -- > Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > ISC funds the development of this software with paid support > subscriptions. Contact us at https://www.isc.org/contact/ for more > information. > > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users > -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: RE: DNSSEC adoption
On 02-Aug-22 13:51, Brown, William wrote: my guess is that they see dnssec as fragile, have not seen _costly_ dns subversion, and measure a dns outages in thousands of dollars a minute. No one wants to be this guy: http://www.dnssec.comcast.net/DNSSEC_Validation_Failure_NASAGOV_201201 18_FINAL.pdf so, to me, a crucial question is whether dnssec ccould be made to fail more softly and/or with a smaller blast radius? randy I'm more of a mail guy than DNS, so yes, like hard v. soft fail in SPF. Or perhaps some way of the client side deciding how to handle hard v./ soft failure. As Mark has pointed out, validation is a client issue. Setting up DNSSEC properly and keeping it running is for the server admin - which bind is incrementally automating. For bind, the work-around for bad servers (which is mentioned in the article) is to setup negative trust anchors in the client for zones that fail. And notify the zone administrator to fix the problem. I usually point them to a DNSVIZ report on their zone. The nasa.gov failure was avoidable. nasawatch, which is an excellent resource for space news, jumped to an incorrect conclusion about the outage - and never got the story straight. In fact, all validating resolvers (including mine) correctly rejected the signatures. It wasn't comcast's fault - they were a victim. It is an unfortunate reality that admins will make mistakes. And that there is no way to get all resolvers to fix them - you can't even find all the resolvers. (Consider systemd-resolved, or simply finding all the recursive bind, powerdns, etc instances...) There is no global "soft" option - aside from unsigning the zone and waiting for the TTLs to expire. And besides being a really bad idea, it's easier to fix the immediate problem and learn not to repeat it. Long term, automation of the (re-)signing and key roll-overs will reduce the likelihood of these outages. It is truly unfortunate that it's so late in coming. It may take a flag day to get major resolver operators, dns servers, and client resolvers all on the same page. I'm not holding my breath. Timothe Litt ACM Distinguished Engineer -- This communication may not represent the ACM or my employer's views, if any, on the matters discussed. OpenPGP_signature Description: OpenPGP digital signature -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC adoption
On 8/2/22 11:51 AM, Brown, William wrote: Or perhaps some way of the client side deciding how to handle hard v./ soft failure. Wouldn't this require the client side being aware of DNSSEC and making decision based on it? Maybe it's just me, but I think client application side DNSSEC validation is woefully lacking. Maybe there could be an option to ask a recursive DNS server to do DNSSEC validation and return record data even if the validation fails. Then the client could decide to use the data or not based on it's preferences. I feel like similar behavior can be achieved by messing with the CD / DO flags across multiple queries. But even this requires the client side being aware of DNSSEC. (See prior statement.) I also feel like what we're discussing is dangerously close to defeating DNSSEC and antithetical to it's purpose. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: DNSSEC adoption
>>> my guess is that they see dnssec as fragile, have not seen _costly_ >>> dns subversion, and measure a dns outages in thousands of dollars a >>> minute. >> No one wants to be this guy: >> http://www.dnssec.comcast.net/DNSSEC_Validation_Failure_NASAGOV_201201 >> 18_FINAL.pdf >so, to me, a crucial question is whether dnssec ccould be made to fail more >softly and/or with a smaller blast radius? >randy I'm more of a mail guy than DNS, so yes, like hard v. soft fail in SPF. Or perhaps some way of the client side deciding how to handle hard v./ soft failure. Confidentiality Notice: This electronic message and any attachments may contain confidential or privileged information, and is intended only for the individual or entity identified above as the addressee. If you are not the addressee (or the employee or agent responsible to deliver it to the addressee), or if this message has been addressed to you in error, you are hereby notified that you may not copy, forward, disclose or use any part of this message or any attachments. Please notify the sender immediately by return e-mail or telephone and delete this message from your system. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC adoption
>> my guess is that they see dnssec as fragile, have not seen _costly_ >> dns subversion, and measure a dns outages in thousands of dollars a >> minute. > No one wants to be this guy: > http://www.dnssec.comcast.net/DNSSEC_Validation_Failure_NASAGOV_20120118_FINAL.pdf so, to me, a crucial question is whether dnssec ccould be made to fail more softly and/or with a smaller blast radius? randy -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: DNSSEC adoption
> my guess is that they see dnssec as fragile, have not seen _costly_ dns > subversion, and measure a dns outages in thousands of dollars a minute. >randy No one wants to be this guy: http://www.dnssec.comcast.net/DNSSEC_Validation_Failure_NASAGOV_20120118_FINAL.pdf Confidentiality Notice: This electronic message and any attachments may contain confidential or privileged information, and is intended only for the individual or entity identified above as the addressee. If you are not the addressee (or the employee or agent responsible to deliver it to the addressee), or if this message has been addressed to you in error, you are hereby notified that you may not copy, forward, disclose or use any part of this message or any attachments. Please notify the sender immediately by return e-mail or telephone and delete this message from your system. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC adoption
> TLD Signed? Comments > ----- > google.comno > gmail.com no > youtube.com no > apple.com no > microsoft.com no > amazon.comno > walmart.com no > outlook.com no > 1e100.net no > facebook.com no > twitter.com no > instagram.com no > ibm.com no > mozilla.org no > wikipedia.org no > redhat.comno > w3c.org no > bankofamerica.com no > > Does anybody have an explanation for why such big domains don't bother > using DNSSEC? my guess is that they see dnssec as fragile, have not seen _costly_ dns subversion, and measure a dns outages in thousands of dollars a minute. randy --- ra...@psg.com `gpg --locate-external-keys --auto-key-locate wkd ra...@psg.com` signatures are back, thanks to dmarc header butchery -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
