[HN Gopher] Against DNSSEC (2015)
___________________________________________________________________
Against DNSSEC (2015)
Author : tosh
Score : 48 points
Date : 2022-10-21 14:40 UTC (8 hours ago)
(HTM) web link (sockpuppet.org)
(TXT) w3m dump (sockpuppet.org)
| jeroenhd wrote:
| We need a better alternative to DNSSEC. Its design is outdated
| and it's implementations can be very clunky. It's like HTML and
| Javascript in a way.
|
| However, it's the system we've got. Unless you do some kind of
| on-the-fly domain generation or an outdated DNS registrar, it's
| quite easy to enable and it helps prevent all kind of weird DNS
| malarkey for those that care about their internet security.
| tptacek wrote:
| 1. It's not the system we've got, because we don't got it. Less
| than 4% of .COM is signed. Virtually no important domains are
| signed, particularly at the companies with the largest security
| teams. The root DNSSEC keys could land on Pastebin tonight and
| nobody would need to be paged.
|
| 2. It's not quite easy to enable it. Evidence for that
| position: the litany of stories where companies have tried to
| enable it, like Slack did, and had multi-hour worldwide outages
| as a result.
| bbarnett wrote:
| The worst is, computer clocks drift, and ntp's domains are
| signed, so if your clock drifts enough, you cannot update
| your time, because dnssec invaliates time server records.
|
| Good times.
|
| Seen more than one org disable dnnsec, in bind, because of
| this.
| wahern wrote:
| You would have the same issue with TLS or any other scheme.
| When OpenNTPD added TLS-authenticated constraints, I
| immediately began having problems on one of my PCEngines
| APU with a broken RTC (same model as all my other ones, but
| clock would always reset when power removed, no matter how
| many times I changed the battery). I had to disable TLS
| constraints. Eventually they added a special "trusted"
| qualifier to NTP server directives for bypassing constraint
| checking.
|
| Authenticated time synchronization faces intrinsic dilemmas
| no matter the technology.
| nixcraft wrote:
| Just checked Faang and none of them have DNSSEC enabled:
| for d in Amazon.com Facebook.com Apple.com Google.com Netflix.com
| ; do delv "$d" @1.1.1.1; done
| alwillis wrote:
| There are nearly 20 million DNSSEC-enabled zones [1], which is
| a drop in the bucket compared to the internet as whole
| obviously. But 20 million is not nothin'.
|
| [1]: https://stats.dnssec-tools.org/
| tptacek wrote:
| The problem with that 20MM number is that it's in large part
| the result of registrars auto-signing names (especially in
| Europe). There's 2 issues with that:
|
| 1. The overwhelming majority of those names are meaningless,
| just as it doesn't change anything about Internet security if
| I do or don't sign the "paulgra-ham.com" domain I bought on
| Hover years ago when I was drunk.
|
| 2. Registrar signatures are more or less security theater,
| because those customers aren't even controlling their own
| keys.
|
| The total adoption of DNSSEC in commercial zones is between
| 1-4% right now, right?
| amluto wrote:
| DNSSEC has no shortage of problems, but this IMO isn't
| really one of them:
|
| > 2. Registrar signatures are more or less security
| theater, because those customers aren't even controlling
| their own keys.
|
| It would be nifty if DNSSEC (or some superior technology)
| provided a degree of protection against a compromised
| registrar, but I don't think that's the primary benefit. Of
| _course_ the registrar can change the DNS data.
|
| DNSSEC purports to secure the transfer of data from the
| combination of the registrar and the domain owner to the
| resolver. For example, the combination of DNSSEC and CAA
| can, in principle, prevent even an arbitrarily privileged
| attacker on the network from getting a bogus certificate
| issued. Without DNSSEC, services like Let's Encrypt rely on
| a degree or network voodoo to protect against MITM attack.
|
| (Of course, a much simpler and more robust mechanism could
| accomplish the same goal. For example, there could be a
| standardized out of band mechanism by which a CA could
| securely ask a registry for the certificate policy for a
| domain. Something like this wouldn't have the admin-
| screwed-up--and-the-whole-domain-is-down failure modes.)
|
| edit: It looks like RDAP is moderately close to being able
| to do that out-of-band verification. I wonder if anyone is
| working on CAA integration with RDAP.
| tptacek wrote:
| I don't know that I'd call the registrar auto-signing
| thing a "problem" so much as a "juked stat".
| pixl97 wrote:
| Previous discussion.
|
| https://news.ycombinator.com/item?id=8894902
| dane-pgp wrote:
| There's also another article from 2015 titled "For DNSSEC"
| which is sort of a response[0] to the one posted here. That
| article was discussed[1] on HN late last year.
|
| [0] https://easydns.com/blog/2015/08/06/for-dnssec/
|
| [1] https://news.ycombinator.com/item?id=29381778
| tptacek wrote:
| Weird to see this here, but OK! I keep debating writing a follow-
| up post called "Stick A Fork In It", declaring DNSSEC finally
| dead and buried, and (wisely) have decided not to call it quite
| yet. Factors motivating "Stick A Fork In It":
|
| * The increasing salience of multi-perspective verification at
| CAs (LetsEncrypt won't depend on a single DNS response to domain-
| validate a certificate request, but will distribute that request
| to resolvers around the world and make sure they agree with each
| other).
|
| * The potential inclusion of RDAP, the successor to Whois, as a
| mechanism for verifying domain ownership for certificates ---
| instead of doing a weird DNS dance, you can just ask the
| registrar directly.
|
| * The design and deployment of MTA-STS, the HSTS-style TLS
| continuity protocol for SMTP; SMTP is basically the final use
| case for DNSSEC, where DNSSEC can serve as a signaling mechanism
| to ensure that SMTP connections actually use TLS and aren't
| negotiated down to plaintext by a MITM. MTA-STS was designed
| specifically to replace DNSSEC for this use case, by the major
| email providers.
|
| * The ironic increase in domain takeover attacks --- ironic
| because they're overwhelmingly (probably universally?) done by
| compromising registrar accounts rather than playing games with
| the DNS protocol, such that even after a forklift upgrade to
| enable DNSSEC, we'd still mostly have the same DNS security
| problem.
|
| * The mass adoption of DNS-over-HTTPS, which is "bottom-up" DNS
| security that (unlike DNSSEC) protects the "last mile" between
| browsers and the DNS servers they talk to; in a world where most
| users talk to just a couple trusted DNS resolvers, all of which
| speak DoH, DoH might be all the DNS security we need?
|
| * The rise in BGP4 takeover attacks, which completely bypass name
| resolution altogether; as these attacks continue to mainstream,
| they too strike right at the heart of the problem DNSSEC was
| supposed to solve.
|
| * The incredibly bad track record DNSSEC has for reliability; for
| instance, Slack had a multi-hour total sitewide outage earlier
| this year that came from attempting to turn it on. This was
| predicted --- it's predicted in the "Against DNSSEC" post! ---
| and it's come to pass: DNSSEC is easy to screw up, easier than
| TLS, and when you screw DNSSEC up, your site falls of the entire
| Internet without warnings.
|
| * The success of Certificate Transparency and CA surveillance in
| the WebPKI, to the point where the largest and most commercially
| important CAs were actually ripped out of browsers after
| surveillance systems detected misissuance. Also, the most trusted
| CA on the Internet in 2022 is... free? The WebPKI of 2022 is just
| not the WebPKI of 2015.
|
| Against this backdrop, the important thing to know about DNSSEC
| is that it is simply not widely deployed; you can quickly measure
| this by taking any list of the top domains (the "Moz 500" is an
| easy-to-download version) and then feeding it through dig:
| for DOMAIN in $(cat list); do dig ds $DOMAIN +short
| done
|
| That DNSSEC isn't widely deployed doesn't, of course, mean it
| never will be. But it's important to get a sense of the costs
| we're talking about: it would be one thing if the work of rolling
| DNSSEC out had already been done, the costs had been sunk, and we
| were just trying to extract some value of it. But the opposite is
| true!
|
| I see a much different (and worse) opportunity cost to DNSSEC: if
| we stick a fork in it, we can get to work on something better. I
| think we've more or less established that a top-down government-
| controlled PKI is not the future of Internet security. Maybe DNS
| is worth protecting anyways! Ending the 26-year DNSSEC boondoggle
| would free us up to explore alternate models with clearer, more
| realistic trust models.
|
| At any rate: I feel like the ~8 years since I wrote this post
| have pretty much totally vindicated my argument. I felt a little
| like I was going out on a limb when I wrote it. Now I feel like
| the argument is pretty banal. :)
| kaulquappe wrote:
| I'm not buying into the whole "top-down government-controlled"
| argument against the DNS system. Yes, the US has control over
| ICANN and therefore the root name servers, but the power lies
| with the configuration of a device's DNS resolver. Any
| recursive resolver is free to configure other root servers
| (e.g. OpenNIC). It's currently the ISPs' choice and it more and
| more transfers over to central resolver like Cloudflare's
| 1.1.1.1 or Google's 8.8.8.8. Even operating system vendors have
| a lot of influence on the default settings for DNS resolver
| (take the ones advertised via DHCP or choose some other ones).
| Even browsers could choose to look up names directly at a
| resolver of their choosing instead of relying on the OS. What
| gets in the way of this are local corporate-wide domains and
| the like, but there are several ways to deal with this. The
| main argument I want to make is, that the power over DNS is not
| as much with the US Government as you might think.
| growse wrote:
| The owner of com. (which is effectively the US govt) can hand
| out whatever records it likes for anything under .com.
|
| All DNSSEC gives you is a false sense of security as you
| merrily validate signatures on spoofed records because
| they're generated by the same people who own the DS record
| responses.
|
| And what happens when you (and everyone else) finds out you
| can no longer trust DNSSEC signatures on .com.? Stop using
| all of .com?
|
| > but the power lies with the configuration of a device's DNS
| resolver. Any recursive resolver is free to configure other
| root servers (e.g. OpenNIC).
|
| How does OpenNIC know how to answer the question "where is
| ycombinator.com"?
| tialaramex wrote:
| > The mass adoption of DNS-over-HTTPS, which is "bottom-up" DNS
| security that (unlike DNSSEC) protects the "last mile" between
| browsers and the DNS servers they talk to; in a world where
| most users talk to just a couple trusted DNS resolvers, all of
| which speak DoH, DoH might be all the DNS security we need?
|
| Of course those "couple trusted DNS resolvers" (and all the
| ones operated by enthusiastic "Home labs" types) need to know
| whether the answers are trustworthy, otherwise we're just
| centralising the problem not fixing it.
|
| You're a smart person so I'm sure you guessed what the
| canonical solution is, it's DNSSEC.
|
| > The potential inclusion of RDAP, the successor to Whois, as a
| mechanism for verifying domain ownership for certificates
|
| This is technology, wishful thinking won't move the bar. ACME
| RDAP isn't a thing, doesn't appear to have even a draft, don't
| _think_ it was even discussed. So this "potential" seems
| rather nebulous. RDAP is a cute trick, it'd be nice if it
| someday displaces WHOIS properly but it doesn't really have
| great applicability to this problem.
|
| > explore alternate models with clearer, more realistic trust
| models.
|
| I have experience with the "Surely anything would be better
| than this" crowd, they voted for Brexit. You presumably don't
| need to ask how that's going since I believe in your country
| they voted for Trump.
| tptacek wrote:
| This is just begging the question. There's a top-down
| security model for DNS, where you deploy a global PKI, and
| there's a bottom-up security model where you protect all the
| links. If the top-down approach reaches all the leaves, so
| all lookups are signed and verified, it can succeed.
| Likewise, if the bottom-up model reaches the roots, it too
| succeeds: if every link DNS uses is protected, then the only
| avenues for compromise are outside the scope of the DNS
| anyways --- in the same way that registrar compromise today,
| the primary vector for DNS takeovers, is out of scope for
| DNSSEC.
|
| What you're saying here is, "if you do bottom-up DNS
| security, all you know is that the links were secure; you
| still don't know if the data was authentic". Sure, but that's
| not dispositive, because:
|
| (a) Bottom-up DNS security can continue to succeed to the
| point where it links resolvers and caches to authority
| servers
|
| (b) Regardless of whether it does, the costs attackers incur
| against DoH-protected hosts might be wildly higher than the
| benefits (the risk-of-failure-adjusted value of a misissuance
| via a DNS attack).
|
| So, I guess what I'm saying is that it's clear on it's face
| that there's no "canonical solution" to this problem; there's
| a solution space. DNSSEC advocates have been telling us for
| (checks notes) 27-28 years that DNSSEC is "the canonical
| solution" to DNS security. The information security field has
| ignored the DNSSEC advocates, and, I'd argue, largely
| vindicated themselves in that approach.
|
| Britain, for what it's worth, was already a member of the EU
| when they voted for Brexit. The circumstances of DNSSEC are
| not similar. It's a weird, inapposite emotional appeal either
| way, but the premise fails, too.
| wizeman wrote:
| > (a) Bottom-up DNS security can continue to succeed to the
| point where it links resolvers and caches to authority
| servers
|
| Even if that would happen, the client would have no way to
| know if all the links were indeed secured. And even it
| would know it, it would have no way to know if any of the
| resolvers in those links forged a DNS response.
|
| With DNSSEC the client can verify that the response is
| indeed authentic.
|
| > (b) Regardless of whether it does, the costs attackers
| incur against DoH-protected hosts might be wildly higher
| than the benefits (the risk-of-failure-adjusted value of a
| misissuance via a DNS attack).
|
| Actually, it can be profitable for the DoH-protected hosts
| themselves to forge DNS responses, no attacker is needed.
| There are many consumer ISPs that do that already to
| display advertisements, collect statistics or straight up
| hijack domain names (e.g. due to piracy laws). DoH does
| nothing to prevent that, while a client resolver with
| DNSSEC support does protect against that.
|
| In fact, DNSSEC can work just as well with DoH, which is
| what I do on my laptop. These two technologies are not
| mutually exclusive and I see no reason why we can't use
| both at the same time.
| tptacek wrote:
| What does it matter if the client knows or doesn't know
| the whole chain from the resolver to all its peers?
| There's nothing the client can do about it. DNS data is
| either hard to spoof (even now, that's the case) or it
| isn't. This idea that bottom-up DNS security is suspect
| because the client can't verify the whole chain would be
| easier to take if it wasn't for the fact that all of
| DNSSEC security collapses down to a single, resolver-
| controlled header bit on the link between your browser
| and your DNS server.
|
| This just isn't a real problem.
| wizeman wrote:
| > What does it matter if the client knows or doesn't know
| the whole chain from the resolver to all its peers?
| There's nothing the client can do about it.
|
| If the client expected all the links to be secured (which
| is what you propose with a bottom-up security model) and
| if it would know whether they are or not, then it could
| fail to resolve if any link is not currently secured, if
| the user so desired.
|
| In your bottom-up security model proposal, this would
| protect against any external man-in-the-middle attack in
| the entire chain (but not an attacker within the chain).
|
| If the client doesn't know if all links are secured, then
| it is vulnerable as long as any link in the chain can be
| attacked (except for its own link), not to mention of
| course, by attackers within the chain as well. Since it
| has no way to know whether it was attacked or not, it has
| no way to prevent forged responses.
|
| > DNS data is either hard to spoof (even now, that's the
| case)
|
| It's really not hard. Otherwise, this page wouldn't list
| ongoing cases that affect millions of users right now,
| every single day:
|
| https://en.wikipedia.org/wiki/DNS_hijacking
|
| > if it wasn't for the fact that all of DNSSEC security
| collapses down to a single, resolver-controlled header
| bit on the link between your browser and your DNS server.
|
| Maybe on your system, not mine.
|
| If you use a local caching resolver with DNSSEC support
| (and why wouldn't you, unless you're using a
| microcontroller with close to zero resources?) then no
| application on your local system will get a forged
| response from domains with DNSSEC support (unless it was
| attacked at the source, origin DNS server or at the TLD
| level, of course, no way to prevent that), regardless of
| what your DNS server does or pretends to be doing, or any
| other DNS server in the chain, or even an external
| attacker that tries to attack any link in the chain, for
| that matter.
|
| You could also implement a DNS resolver with DNSSEC
| support on your browser, if you really wanted. But a
| local caching resolver is an even more generic solution,
| as it protects all local applications, not just your
| browser.
| tptacek wrote:
| First: the page you're citing talks (1) about stub-to-
| cache DNS lookups that DNSSEC doesn't protect at all, but
| DoH does (again: DNSSEC collapses down to the
| "authenticated data" bit in the ISP-controlled last mile)
| and (2) about "hijacks" that are actually registrar ATOs.
|
| Second: whatever weird thingy your system does, I respect
| it, but it is simply not the case that millions of
| mainstream users are going to run fully recursive DNS
| caches on their phones and laptops any time soon. People
| love to point out that they can just run their own DNS
| server on their Linux box, which is obviously true,
| because that's how ISPs run DNS servers, too. I'm
| suitably impressed with your sysop ability, but I don't
| know what that has to do with Internet security.
| wizeman wrote:
| > the page you're citing talks (1) about stub-to-cache
| DNS lookups that DNSSEC doesn't protect at all, but DoH
| does
|
| Both DNSSEC and DoH can protect against DNS hijacking.
| DNSSEC can give you end-to-end protection if you use a
| DNSSEC-enabled resolver and the domain supports DNSSEC,
| while DoH can only protect one link in the chain, no
| matter what you do.
|
| > whatever weird thingy your system does, I respect it
|
| What is weird about running a local caching resolver?
| Most modern Linux systems do that, as far as I know. I
| simply use one that does DNSSEC verification by default.
|
| I don't see why Android/iOS phones or Windows systems
| wouldn't be able to do that by default in 2022, if their
| developers really wanted to implement that.
|
| > it is simply not the case that millions of mainstream
| users are going to run fully recursive DNS caches on
| their phones and laptops any time soon.
|
| Yeah, not with that attitude :)
| tptacek wrote:
| Not with any attitude: what you and the phone sysadmins
| propose is, effectively, to eliminate all shared DNS
| caching from the Internet. A beautiful dream! But that's
| all it is.
|
| That no mainstream operating system in the world does
| this is all the evidence I need to dispose of this part
| of the argument.
| scrollaway wrote:
| What's the status on RDAP? I keep hearing about it but even the
| official page (https://www.icann.org/rdap) doesn't talk about
| anything beyond 2019.
| rw547264 wrote:
| RDAP is operational for ICANN-accredited TLDs. You can use
| the web client at https://lookup.icann.org
|
| Just one place to go to for all those TLDs. ccTLD support is
| hit or miss.
|
| Also good info here: https://about.rdap.org
| xtnd53 wrote:
| > Slack had a multi-hour total sitewide outage earlier this
| year that came from attempting to turn it on.
|
| I don't particularly want to defend DNSSEC here but Slack
| picked Route 53, who both have had and continue to have well
| known compliance issues with DNS, and they expected them to get
| DNSSEC right. I'm a little surprised it's gone as well as it
| has and that they still have DNSSEC on.
|
| Apple's recent revisiting of DNSSEC is possibly the only
| glimmer of hope for more mainstream adoption of DNSSEC. Their
| software's got a large installed base and their API is opt-in
| for DNS consuming software. It'd be nice if more DNSSEC
| implementations made DNSSEC opt-in but the evangelical DNSSEC
| set wouldn't abide that.
|
| > I think we've more or less established that a top-down
| government-controlled PKI is not the future of Internet
| security. Ending the 26-year DNSSEC boondoggle would free us up
| to explore alternate models with clearer, more realistic trust
| models.
|
| I don't think that's clear at all. What is clear is that the
| DNS hasn't moved much in that period and that the only things
| that have been adopted are things that authorities and
| resolvers can silently implement. Putting a fork in DNSSEC
| won't change much. At this point whatever replaces DNS will be
| how this space gains some security.
| asimops wrote:
| In SMTP, isn't it especially valuable to have DNSSEC for using
| DANE and not having to rely on the centralized web PKI?
| pornel wrote:
| DANE adds even more dependence on the even more centralized
| TLD owners, all eggs in their basket.
| wizeman wrote:
| What do you mean, _more_ dependence? How does DANE make a
| domain more dependent on the TLD owners than they already
| are?
|
| Specifically, what kind of attack would a TLD owner be able
| to perform on a domain that uses DANE that they wouldn't be
| able to perform if the domain weren't using DANE?
| dane-pgp wrote:
| You're missing the key difference: with the web PKI model,
| you have to trust every CA not to maliciously issue an
| unwanted certificate for your domain, whereas with DNSSEC,
| the owners of .ru (for example) can't affect your domain if
| it's under the .us TLD.
| tptacek wrote:
| And you're missing the fact that CAs that misissue
| certificates can and will be distrusted by Chrome and
| Mozilla, but there's no way to revoke .COM.
| AndyMcConachie wrote:
| CT is a joke. Trusting CAs to post all their certs to CT
| is a non-starter for me. A CA can issue a cert to the NSA
| and no one would know it.
| tptacek wrote:
| That works until a browser notices the misissued
| certificate, and then Mozilla removes the CA from their
| root program.
| wizeman wrote:
| > And you're missing the fact that CAs that misissue
| certificates can and will be distrusted by Chrome and
| Mozilla
|
| That doesn't protect against attacks from occurring, it
| only protects against future attacks from the same people
| who already attacked (assuming the same people don't
| create a new CA?).
|
| And when Chrome and Mozilla distrusts a new CA, good luck
| on updating the certificate chains included in the
| operating systems of all the devices in the world,
| especially those that never update (old Android phones?
| IoT devices?).
|
| > there's no way to revoke .COM
|
| I think there is no need to revoke .COM because .COM can
| attack any domain within .COM anyway, even with/without
| DNSSEC and/or with/without CAs? Or what am I missing?
| growse wrote:
| > > there's no way to revoke .COM
|
| > I think there is no need to revoke .COM because .COM
| can attack any domain within .COM anyway, even
| with/without DNSSEC and/or with/without CAs? Or what am I
| missing?
|
| The point is you don't build a system that assumes DNS is
| trustworthy, because it isn't.
| ThePowerOfFuet wrote:
| > And you're missing the fact that CAs that misissue
| certificates can and will be distrusted by Chrome and
| Mozilla, but there's no way to revoke .COM.
|
| If they are caught -- and CT has made that very likely,
| but hijinks like in Kazakhstan sidestep CT.
| tptacek wrote:
| That's an argument that cuts against DNSSEC, not for it.
| There's no transparency in the DNS PKI at all.
| wizeman wrote:
| There's no reason why you couldn't use certificate
| transparency with DNS PKI?
|
| Why do you seem to always be talking like if DNSSEC is
| incompatible with other security technologies?
|
| DNSSEC isn't incompatible with DoH either, but you also
| seem to be implying that we need to only use one or the
| other?
| tptacek wrote:
| By all means, do show me the crt.sh equivalent for
| DNSSEC. Easy way to win this leg of the argument!
| wizeman wrote:
| I'm not saying it exists right now, I'm saying it could
| be created for a DNS PKI system if it was found to be
| necessary (like you seem to be implying)?
| tptacek wrote:
| Will it have blackjack, and hookers? :)
| AndyMcConachie wrote:
| There are a lot more mail domains signed with DNSSEC/DANE than
| with MTA-STS. So using your argument that DNSSEC is dead
| because no one is using it actually works in DANE's favor in
| this instance. MTA-STS is dead. DANE ate its lunch.
| tptacek wrote:
| Once again: there are literally millions of domains signed
| with DNSSEC because registrars, especially in Europe, auto-
| sign. That doesn't mean anything. I get that you're probably
| joking here, but the idea of the 28-year-old DNSSEC project,
| deployed on less than 4% of .COM and virtually nowhere in the
| actual industry, declaring victory over an RFC from 2018 is,
| of course, risible. I assume that was the intention, though.
| ThePowerOfFuet wrote:
| > * The incredibly bad track record DNSSEC has for reliability;
| for instance, Slack had a multi-hour total sitewide outage
| earlier this year that came from attempting to turn it on.
|
| It was actually from turning it _off_, relying on expert advice
| that turned out to be incorrect:
|
| >Our Traffic team was confident that reverting the DS record
| published in MarkMonitor was sufficient to eventually resolve
| DNS resolution problems. As things were not getting any better,
| and given the severity of the incident, we decided to rollback
| DNSSEC signing in our slack.com authoritative and delegated
| zones, wanting to recover our DNS configuration to the last
| previous healthy state, allowing us to completely rule out
| DNSSEC as a problem.
|
| >As soon as the rollback was pushed out things got much worse;
| our Traffic team was paged due to DNS resolution issues for
| slack.com from multiple resolvers across the world.
|
| >Based on expert advice, our understanding at the time was that
| DS records at the .com zone were never cached, so pulling it
| from the registrar would cause resolvers to immediately stop
| performing DNSSEC validation. This assumption turned out to be
| untrue. The '.com.' zone will ask resolvers to cache the
| slack.com DS record for 24h by default (non modifiable by zone
| owners). Luckily, some resolvers cap that TTL with a lower
| value (i.e. Google's 8.8.8.8 has a 6h TTL on DS records).
|
| https://slack.engineering/what-happened-during-slacks-dnssec...
| jabart wrote:
| DNSSEC doesn't yet support multi-provider DNS solutions and
| Route53 only recently (little over a year ago) started to support
| it.
|
| Other note is I've had exactly two people who it prevented from
| using a site. One was at a coffee shop and another in a hospital
| where I assume they both were rewriting DNS for some reason.
| [deleted]
| wizeman wrote:
| Sorry, thread limit achieved. For tptacek:
|
| > Not with any attitude: what you and the phone sysadmins propose
| is, effectively, to eliminate all shared DNS caching from the
| Internet. A beautiful dream! But that's all it is.
|
| No, a local caching resolver (with or without DNSSEC verification
| enabled by default) would talk to the upstream DNS server by
| default, like a stub resolver, so it benefits from the upstream
| DNS server cache.
| xfer wrote:
| Can you not mitm the CA's dns lookups for http, tls-alpn
| challenges and make them sign the certificates for you? How does
| letsencrypt prevent this? Do they check with multiple resolvers
| around the world?
| tptacek wrote:
| Yes, they check with multiple resolvers around the world.
| ehPReth wrote:
| well, two do at least. hopefully more
| IvyMike wrote:
| Last time this was posted, I asked for an example of any real-
| world incident which would have been prevented by DNSSEC. I have
| never seen one, but it would be interesting.
|
| P.S. Lots of hypothetical examples were given, but I'd like to
| see an actual case.
|
| P.P.S. tptacek try to hold your tongue for at least a little bit
| before piping in with your usual response. :)
| [deleted]
| AndyMcConachie wrote:
| Read section 2.2 on MyEtherwallet.
|
| https://www.icann.org/en/system/files/files/sac-121-en.pdf
|
| The attackers took over the authoritative DNS servers and
| answered queries with lies.
___________________________________________________________________
(page generated 2022-10-21 23:01 UTC)