Total Pageviews

Tuesday, 6 March 2018

DNSCurve Software

Here's a list of DNSCurve servers, tools, and other software. DNSCurve is a fully backwards-compatable extension to DNS that adds link-level authenticated encryption. Most implementations use NaCl, libsodium, or slownacl for cryptographic operations.
Please also see DNSCurve.io for more DNSCurve information.
  • Authoritative DNS
    • CurveDNS — a DNSCurve Forwarding Name Server in C
    • pymdscurve — an authoritative DNSCurve server in Python
    • odns — Onion DNS Forward, in C++
    • fDns — fDns is a fast authority DNS Server and then there's fDns!

  • Recursive DNS
  • Libraries
    • nonce — a simple DNSCurve nonce management library
    • librdns — Asynchronous DNS resolver
    • ocaml-dnscurve — An implementation of the DNSCurve protocol
    • dnscurve-python — Implementation of DNSCurve in python

  • Services
    • OpenDNS provides 3rd party recursive DNS service, supporting DNSCrypt
    • cryptostorm.is is a privacy/security focused VPN provider with DNSCrypt-enabled resolvers.

  • Other
  • Miscellaneous
    • Dan Bernstein: "An attacker who spends a billion dollars on special-purpose chips to attack Curve25519, using the best attacks available today, has about 1 chance in 1000000000000000000000000000 of breaking Curve25519 after a year of computation."
    • Ian Grigg: "In the past, things like TLS, PGP, IPSec and others encouraged you to slice and dice the various algorithms as a sort of alphabet soup mix. Disaster. What we got for that favour was code bloat, insecurity at the edges, continual arguments as to what is good & bad, focus on numbers & acronyms, distraction from user security, entire projects that rate your skills in cryptoscrabble, committeeitus, upgrade nightmares, pontification ... Cryptoplumbing shouldn't be like eating spagetti soup with a toothpick. There should be One Cipher Suite and that should do for everyone, everytime. There should be no way for users to stuff things up by tweaking a dial they read about in some slashdot tweakabit article while on the train to work... Picking curve25519xsalsa20poly1305 is good enough for that One True CipherSuite motive alone... It's an innovation! Adopt it."

  • DNSCurve Timeline
  • DNSCurve support coming soon!
    • Cryptostorm plans to deploy DNSCurve authoritative nameservers
"Powered by DNSCurve"

from  https://ianix.com/dnscurve/dnscurve-software.html
------

Major DNSSEC Outages and Validation Failures

Updated: May 5, 2018
This page lists only DNSSEC failures that have the potential to cause downtime for a significant number of domains, users, or both. It does not list smaller outages such as dominos.com ($1.425 Billion in yearly revenue), the Government of California, or other such "small" organizations. They are too frequent to mention. Technical and media/content organizations are held to a higher standard.
Principal sources of information: DNSViz, Verisign's DNSSEC Debugger, Zonemaster, dnscheck.iis.se, dnscheck.labs.nic.cz, and Unbound logs. Discussions on technical mailing lists are also used as sources.
Note: DNSViz has lost a portion of its archives multiple times, turning many citations on this page into 404s. Currently, the dnssec-deployment.org mailing list archives have been down for over a year, and previously for around 5 months, producing more 404s. Constant DNSSEC outages desensitize people to downtime, making them think it's normal.

Root servers

TLD DNSSEC outages

Major sites

Long DNSSEC outages

The median duration of a DNSSEC outage is 8 days. The following may or may not concern large organizations, but when duration is taken into account, a major outage is implied. Bidding starts at 1 DNSSEC-year.
Terminology note: The coveted 1000-day DNSSEC outage is known as a kiloday.

Software

Miscellaneous

  • DNSSEC defeated by the Great Firewall of China
    "If a site was blocked by authorities, I couldn't resolve it at all, but that was also the case even if I wasn't doing validation on my laptop resolver, but instead using the resolver provided by DHCP."
  • A Longitudinal, End-to-End View of the DNSSEC Ecosystem:
    "Our investigation reveals pervasive mismanagement of the DNSSEC infrastructure. For example, we found that 31% of domains that support DNSSEC fail to publish all relevant records required for validation; 39% of the domains use insufficiently strong key-signing keys; and although 82% of resolvers in our study request DNSSEC records, only 12% of them actually attempt to validate them."
  • Thomas H. Ptacek:
    "Reminder: you could publish the DNSSEC root RSA secret keys on Pastebin and nothing on the Internet that matters would break."
  • Dan Bernstein: Amplification via servers
    "...triggers a 3995-byte UDP packet. If the original 36-byte UDP packet has a forged sender address of 198.41.0.4 then the ISC server will send its 3995-byte UDP packet to 198.41.0.4."
  • CloudFlare: Deep Inside a DNS Amplification DDoS Attack
    "Note, ironically, how the effectiveness of the attack based on the size of the response is made worse by the inclusion of the huge DNSSEC keys -- a protocol designed to make the DNS system more secure."
  • Adam Langley: Very Large RSA Public Exponents
    "On my 2.66GHz, Core 2 laptop, 15 requests per second causes unbound to take 95% of a core. A couple hundred queries per second would probably put most DNSSEC resolvers in serious trouble."
  • [dns-operations] Surprisingly large cluster of domains sharing the same pair of 512-bit ZSKs and some more RSA key oddities
    "Looking closely at the data gathered by the DANE survey I've run into more than 54 thousand (!!!) domains that have the same pair of 512-bit RSA keys for their ZSKs."
  • Scott Arciszewski:
    "I don't see any value in DNSSEC"
  • Jacob Hoffman-Andrews: Issues with DNSSEC, use-caps-for-id, and empty responses
    "At Let's Encrypt, we recently started refusing to issue if there is a failure during CAA lookup, in particular a SERVFAIL. We've received a handful of reports from users who are hitting these SERVFAILs. The authoritative resolver software and the root causes seem to be somewhat different (PowerDNS is one; DNSimple's in-house resolver is another), but it seems like these only happen for people with DNSSEC enabled."
  • APNIC: Why DNSSEC deployment remains so low
    "Unfortunately, our recent study showed that DNSSEC deployment is still very low (only ~1% of .com, .net and .org domains deploy DNSSEC), and that over 30% of these domains are, in fact, misconfigured due to missing DS records."
  • Bert Hubert: Difficulty of implementing DNSSEC
    "As an implementor, after two years, we keep finding DNSSEC corner cases that make the authors of the very RFCs swoon. The effort of implementing everything correctly is just staggering, our number of regression tests is exploding just to try to keep everything in check. It might have been easier all round to just start from scratch and not pretend that this is 'an enhancement of DNS'. The length of the DNSSEC RFCs exceeds the length of the standardizing RFCs of DNS. By the way, I know some people will immediately chime in DNSSEC isn't that hard, but you won't hear an implementor among them..."
  • Paul Vixie: Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards
    "so we'll keep pushing the crap system we have, uphill all the way, noone loving it, and almost everyone in fact hating it. we've now spent more calendar- and person-years on DNSSEC than was spent on the entire IPv4 protocol suite (including DNS itself) as of 1996 when the DNSSEC effort began. ugly, ugly, ugly."
  • Simon Kelley: RFC5011?
    "My experience is the _nothing_ to do with DNSSEC is 'not too difficult' and, to be honest, any system deploying the releases of dnsmasq with DNSSEC to-date which can't be updated is in a bad way anyway."
  • Peter Bowen:
    "Only today did I get a full understanding about how bad DNSSEC is. Major implementations can't even agree on what is bogus vs insecure."
  • Simon Kelley: "DNSSEC on lookups of *.paypal.com no longer work"
    "The problem, is that there are many paths that cause DNSSEC validation to fail, and for most of the them, it's not obvious which query to retry and if that would help. In this case retrying the query would be possible, but in most cases, not. If a DNSSEC validation fails, there are many pieces of data that go into that validation, it's not possible to retry all of them and difficult to determine which answers are good and which bad."
  • Paul Vixie: [dns-operations] Is DNSSEC causing more problems than it solves.
    "if the ultimate benefit of dnssec is JUST and ONLY to allow caching recursives to detect and reject end to end tampering, then that good is not as large as the risk and cost of deploying dnssec."
  • brians on HN:
    "An important thing about layers, about defense in depth, is that you can't even begin to attack one mechanism until you've defeated its predecessors. DANE + TLS doesn't give you layers. If I can subvert your DNSSEC, I can endorse a fresh TLS key, and win. If I can subvert your TLS, I win. This is defense in breadth, a strategy known mostly for its close association with defeat."
  • Moxie Marlinspike: SSL And The Future Of Authenticity
    "So unfortunately the DNSSEC trust relationships depend on sketchy organizations and governments, just like the current CA system. Worse, far from providing increased trust agility, DNSSEC-based systems actually provide reduced trust agility."
  • Moxie Marlinspike: BlackHat USA 2011: SSL And The Future Of Authenticity
    "We had this map of the EFF's SSL Observatory data on what countries are currently capable of intercepting secure communication under the CA system. Under [DNSSEC/DANE], it would look like this."
  • Sonic.net implements DNSSEC, performs MITM against customers...
    "Sonic implemented and deployed DNSSEC - and put it on their shiny new servers along with an [RPZ service] that censors supposed malware and phishing sites. And while they told their customers about DNSSEC, they didn't mention the [RPZ service]... And they diverted traffic to a page that does not mention who is doing the diversion, how, or why, or how to opt out."
  • Miek Gieben:
    "Not having to deal with DNSSEC would sure simplify a lot of things :/"
  • Measuring the Practical Impact of DNSSEC Deployment
    "DNSSEC-signed domains — even validly signed domains— have a higher failure rate than non-DNSSEC-signed domains: just DNSSEC-signing a domain increases the failure rate from around 0.7846% to 1.006%..."
  • Frederic Jacobs: Providing better confidentiality and authentication on the Internet using Namecoin and MinimaLT
    "The fact that even today, DNSSEC is having issues being deployed at a larger scale has a lot to do with its complicated design. Getting DNSSEC right is hard..."
  • Simon Kelley: Re: DNSSEC on lookups of *.paypal.com no longer work
    "I run dnsmasq with DNSSEC enabled in production and keep logs. Every so often I check the logs and look at the domains which failed DNSSEC. 95% of the time, by the time I get to do the check, the queries complete successfully. Transient errors seem to be a fact of life with DNSSEC."
  • Casey Deccio: Maintenance, mishaps and mending in deployments of the domain name system security extensions (DNSSEC)
    "Our survey indicated that more than one-half of the zones analyzed were affected by misconfigurations. Also, the survey revealed a significant number of repeat occurrences and average correction times of up to two weeks."
  • CloudFlare:
    "DNSSEC is complicated and it's easy to get wrong. Unfortunately, getting your DNSSEC configuration wrong creates a real potential harm to the rest of the Internet by making your domain's zone file into a potential weapon to be abused by attackers."
  • Akamai: DNSSEC Targeted in DNS Reflection, Amplification DDoS Attacks
    "During the past few quarters, Akamai has observed and successfully mitigated a large number of DNS reflection and amplification DDoS attacks abusing Domain Name System Security Extension (DNSSEC) configured domains...."
  • Alex Cowperthwaite and Anil Somayaji: The Futility of DNSSEC
    "More significant, however, is that DNSSEC solves the wrong problem: it secures hostname to IP address mappings when what is really needed is better end-to-end security guarantees. Thus we believe that the deployment of DNSSEC is a futile gesture, one that will lead to minimal long-term security benefits while resulting in significant security and economic costs."
  • Thomas H. Ptacek: We are in fact better off without DNSSEC
    "DNSSEC leaks internal hostnames to the Internet because the designers of the protocols prioritized authenticated denials (availability) over confidentiality. NSEC3 is a great illustration of how slapdash the protocol design is: in an attempt to plug that leak, the IETF standardized what is in effect a password hash (and a bad one) to help obscure internal hostnames. When challenged on why the Internet should adopt a 1990s password hash as an Internet core protocol security mechanism, DNSSEC proponents say, ``well, well-managed domains make domain cuts carefully to solve this problem'', as if any commercial network in the world actually does that."
  • Dan York: DNS hijack - AVG, Avira and WhatsApp sites affected - seems to be a registrar compromise
    "If this is the case for all of these, there's nothing that DNSSEC or anything else could have done here as the attackers are gaining full access to the domain registrants DNS records and can modify them as they wish."
  • Dan York: No, DNSSEC Would NOT Help Prevent Microsoft's Seizure Of Domains
    "Believe me, as a DNSSEC advocate I have jumped every time I see ``domain hijacking'' in media / social media to see if the new incident might show a solid example of where DNSSEC can help. Almost always... it is not."
  • Thomas Ptacek: Against DNSSEC
    "The Internet loses nothing if it declares a TKO on DNSSEC and starts fresh. There are better DNS security proposals circulating already. They tend to start at the browser and work their way back to the roots. Support those proposals, and keep DNSSEC code off your servers."
  • dsl on HN
    "I hate to add ``me too'' replies, but it is important to get the message out there that lots of really smart folks consider DNSSEC an absolute failure of such epic proportions that you shouldn't even joke about building something real on top of it. The only thing DNSSEC has given us is widespread DDoS amplification."
  • Nicholas Weaver
    "Overall, unless you are validating on the end host rather than the recursive resolver, DNSSEC does a lot of harm from misconfiguration-DOS, but almost no good."
  • Nicholas Weaver
    "If I was Comcast, after the HBO DNSSEC mess-up, on top of previous mess-ups where Comcast inevitably gets the blame, I'd be really really tempted to turn OFF DNSSEC validation. It has failed."
  • Chris Palmer at TrustyCon 2014
    "DNSSEC doesn't seem to be coming. I'm not a believer in it. I don't think that that's where security belongs."
  • Alex Stamos: AppSec California 2015 (Opening Keynote)
    "DNSSEC is dead. It's over. I'm just telling you now it's over. Don't put any of your future stock on DANE or any security solutions that are based on DNSSEC. It's done."
  • Thomas H. Ptacek: One of the downsides of deploying DNSSEC
    "[DNSSEC] sucks up all the oxygen from the effort to actually mitigate flaws in the DNS. The most important DNS security flaw is the last-mile problem between browsers and nameservers, and DNSSEC has practically nothing to say about that. DNSCurve, as a counterexample, does solve this problem, and it solves it regardless of whether 1 person deploys it or 300 million do. But all the oxygen has been stolen by DNSSEC."

DNSSEC Failure Modes

  • [1455504478] unbound[10562:0] info: validation failure <geekpac.com. A IN> no keys have a DS with algorithm DSA from 216.218.132.2 for key geekpac.com. while building chain of trust
  • [1461807469] unbound[9788:0] info: validation failure <slim-shirt.com. A IN>: no keys have a DS with algorithm DSA-NSEC3-SHA1 from 149.210.161.148 for key slim-shirt.com. while building chain of trust
  • [1416399790] unbound[6665:0] info: validation failure <www.root-dnssec.org. A IN>: no keys have a DS with algorithm RSASHA1 from 199.43.133.53 for key root-dnssec.org. while building chain of trust
  • [1453759864] unbound[11879:0] info: validation failure <www.dnscrypt.is. A IN>: no keys have a DS with algorithm RSASHA1-NSEC3-SHA1 from 93.95.226.52 for key dnscrypt.is. while building chain of trust
  • [1453856818] unbound[24687:0] info: validation failure <doosan. A IN>: no signatures with algorithm RSASHA1-NSEC3-SHA1 for <doosan. SOA IN> from 43.230.51.10
  • [1449706352] unbound[14699:0] info: validation failure <mil. NS IN>: no keys have a DS with algorithm RSASHA256 from 199.252.180.234 for key mil. while building chain of trust
  • [1438497104] unbound[13570:0] info: validation failure <psa.gov. A IN>: no signatures with algorithm RSASHA512 from 152.180.7.14
  • [1455505802] unbound[10562:0] info: validation failure <istilllovecalligraphy.com. A IN>: no keys have a DS with algorithm ECDSAP256SHA256 from 173.245.59.126 for key istilllovecalligraphy.com. while building chain of trust
  • [1455501075] unbound[10562:0] info: validation failure <cavatech.com. A IN>: no keys have a DS with algorithm ECDSAP384SHA384 from 178.62.34.37 for key cavatech.com. while building chain of trust
  • [1384202561] unbound[15653:0] info: validation failure <treasuryscams.gov. SOA IN>: signature crypto failed from 164.95.95.155
  • [1453749094] unbound[11879:0] info: validation failure <dnscrypt.is. A IN>: signature crypto failed from 93.95.226.52 for key dnscrypt.is. while building chain of trust
  • [1386464793] unbound[28462:0] info: validation failure <truman.edu. CNAME IN>: signature crypto failed for <truman.edu. SOA IN> from 150.243.160.14
  • [1454604276] unbound[27993:0] info: validation failure <dnscrypt.org. A IN>: use of signature for ECDSA crypto failed from 78.194.219.1
  • [1437688590] unbound[2186:0] info: validation failure <empowhr.gov. A IN>: no signatures from 199.141.107.68
  • [1472397145] unbound[4888:0] info: validation failure <cyj3z6ipngdgyfmk.devblades.com. A IN>: no signatures from 176.31.164.60 for DS cyj3z6ipngdgyfmk.devblades.com. while building chain of trust
  • [1444137310] unbound[7562:0] info: validation failure <hr. NS IN>: no signatures from 204.61.216.90 for key hr. while building chain of trust
  • [1384202514] unbound[15653:0] info: validation failure <hsin.gov. SOA IN>: No DNSKEY record from 205.251.198.5 for key hsin.gov. while building chain of trust
  • [1397619663] unbound[17827:0] info: validation failure <northencolarodouniversity.edu. NS IN>: No DNSKEY record for key edu. while building chain of trust
  • [1397619667] unbound[17827:0] info: validation failure <columbia.edu. NS IN>: key for validation edu. is marked as invalid because of a previous validation failure <northencolarodouniversity.edu. NS IN>: No DNSKEY record for key edu. while building chain of trust
  • [1472427969] unbound[26969:0] info: validation failure <wruluroamgvl66uk.dns007.net. SOA IN>: no NSEC3 records from 208.43.71.243 for DS wruluroamgvl66uk.dns007.net. while building chain of trust
  • [1384529866] unbound[8790:0] info: validation failure <249.10.196.in-addr.arpa. SOA IN>: no DNSSEC records from 196.216.168.10 for DS 249.10.196.in-addr.arpa. while building chain of trust
  • [1385234162] unbound[16342:0] info: validation failure <nonprofit.gov. SOA IN>: signature missing from 159.142.90.245 for key nonprofit.gov. while building chain of trust
  • [1385360828] unbound[1786:0] info: validation failure <qsdmflkjazermlzkaerj.ready.gov. A IN>: no signatures over NSEC3s from 95.100.173.64 for DS qsdmflkjazermlzkaerj.ready.gov. while building chain of trust
  • [1450185083] unbound[8849:0] info: validation failure <com.vu. NS IN>: no NSEC3 closest encloser from 202.80.32.5 for DS com.vu. while building chain of trust
  • [1455528699] unbound[8090:0] info: validation failure <dnssec.ancientartofwar.com. A IN>: wildcard proof failed from 77.95.248.106
  • [1386463727] unbound[28462:0] info: validation failure <nwrczlsyjcdjuohb.nwltc.edu. A IN>: nameerror proof failed from 76.165.120.16
  • [1387237001] unbound[10213:0] info: validation failure <12.56.100.62.in-addr.arpa. PTR IN>: cnamenoanswer proof failed from 83.219.82.2 and 212.67.179.100
  • [1400736520] unbound[4009:0] info: validation failure <eia.gov. RRSIG IN>: nodata proof failed from 199.36.140.199
  • [1390966241] unbound[6793:0] info: validation failure <uofk.edu. NS IN>: DS hash mismatches key from 41.67.20.4 for key uofk.edu. while building chain of trust
  • [1511220820] unbound[52556:0] info: validation failure <www.nasa.gov. A IN>: DS got unsigned CNAME answer from 69.28.143.13 and 205.251.193.107 and 198.116.4.181 for DS www.nasa.gov. while building chain of trust
  • [1397841324] unbound[6604:0] info: validation failure <miwizbrgfcrw.xn--kprw13d. CNAME IN>: DS got DNAME answer from 163.28.1.10 and 202.12.31.141 for DS miwizbrgfcrw.xn--kprw13d. while building chain of trust
  • [1399701822] unbound[23307:0] info: validation failure <ucdavis.edu. TXT IN>: signature labelcount out of range from 128.120.252.10
  • [1405129714] unbound[32474:0] info: validation failure <viagrakopen.net. NS IN>: DNSKEY RRset did not match DS RRset by name from 93.180.70.53 and 46.18.33.23 for key viagrakopen.net. while building chain of trust
  • [1455448756] unbound[23444:0] info: validation failure <distns.com. A IN>: signer name off-tree from 67.228.254.4 for key distns.com. while building chain of trust
  • [1406058604] unbound[19938:0] info: validation failure <dnssec.tz. A IN>: no NSEC3 records from 204.61.216.15 for DS dnssec.tz. while building chain of trust
  • [1406134936] unbound[6020:0] info: validation failure <dnssec.sx. NS IN>: covering NSEC3 was not opt-out in an opt-out DS NOERROR/NODATA case from 192.95.19.109 for DS dnssec.sx. while building chain of trust
  • [1449691919] unbound[25266:0] info: validation failure <www.army.mil. A IN>: SERVFAIL no DS for DS army.mil. while building chain of trust
  • [1472228398] unbound[12736:0] info: validation failure <frictionmediastudio.com. A IN>: signature before inception date from 208.109.255.53
  • [1408991746] unbound[18905:0] info: validation failure <dnssec-or-not.com. A IN>: signature before inception date from 72.13.58.76 for key dnssec-or-not.com. while building chain of trust
  • [1452235796] unbound[24652:0] info: validation failure <rio. A IN>: signature before inception date for <rio. SOA IN> from 200.160.0.10
  • [1463491856] unbound[27503:0] info: validation failure <libsodium.org. A IN>: signature inception after expiration from 78.194.219.1 for key libsodium.org. while building chain of trust
  • [1453789909] unbound[8745:0] info: validation failure <mm. A IN>: signature expired for <mm. SOA IN> from 193.0.9.96
  • [1449381830] unbound[12731:0] info: validation failure <gov.zm. NS IN>: signature expired from 196.216.168.44 for DS gov.zm. while building chain of trust
  • [1451030757] unbound[13897:0] info: validation failure <bw. NS IN>: signature expired from 168.167.168.37 for key bw. while building chain of trust
  • [1409072486] unbound[11089:0] info: validation failure <dnssec-name-and-shame.com. A IN>: signature expired from 192.16.197.229
  • [1409095284] unbound[22110:0] info: validation failure <www.dnssec-name-and-shame.com. A IN>: signature expired for CNAME from 192.16.197.229 and 192.16.197.229
  • [1472367633] unbound[4888:0] info: validation failure <7gpdgz5nlfg7t62b.kruijeradvies.com. A IN>: CNAME in DS response was not secure. signatures from unknown keys from 94.247.75.5 and 94.247.75.5 for DS 7gpdgz5nlfg7t62b.kruijeradvies.com. while building chain of trust
  • [1449698941] unbound[25266:0] info: validation failure <marines.mil. A IN>: signatures from unknown keys from 199.252.155.234 for DS marines.mil. while building chain of trust
  • [1462284322] unbound[19535:0] info: validation failure <www.xfinity.com. A IN>: signatures from unknown keys for CNAME from 23.7.245.92 and 23.61.199.64 and 68.87.76.228
  • [1443535423] unbound[26688:0] info: validation failure <comcast.com. A IN>: signatures from unknown keys from 69.252.250.103
  • [1512057305] unbound[6823:0] info: failed to prime trust anchor -- could not fetch DNSKEY rrset . DNSKEY IN
  • [1512057305] unbound[6823:0] info: validation failure <wssp.nic.cl. A IN>: no DNSKEY rrset for trust anchor . while building chain of trust
  • [1512057309] unbound[6823:0] info: validation failure <64.in-addr.arpa. NS IN>: key for validation . is marked as invalid because of a previous validation failure <wssp.nic.cl. A IN>: no DNSKEY rrset for trust anchor . while building chain of trust

What a mess

DNSSEC is not encrypted, which is responsible for many of its failures. Rather than doing per-message/packet encryption like other secure protocols, DNSSEC was made compatable with censorship and surveillance. To enable censorship and surveillance, an extremely complex and thus fragile protocol was required, thereby resulting in outages, semi-outages, and sometimes just plain bizarre situations. Here are some examples:
from https://ianix.com/pub/dnssec-outages.html

No comments:

Post a Comment

Note: only a member of this blog may post a comment.