Google has been validating on 8.8.8.8 for years now though they only properly enabled EDNS for Google.com on Jan 10, 2019. Prior to that you needed to include a EDNS ECS option to get a EDNS response. They also DNSSEC sign some of their zones. https://developers.google.com/speed/public-dns/faq
> On 25 Feb 2019, at 3:06 pm, Ca By <cb.li...@gmail.com> wrote: > > I just checked > > Bing.com > Google.com > Amazon.com > Facebook.com > Netflix.com > Twitter.com > Chase.com > Coinbase.com > > None of them have dnssec signed domains. > > They are smart. They make money on the web. And they have, likely > consciously, made a cost / benefit risk driven evaluation of dnssec that it > is not worth using. More specifically, their inaction implies dnssec is more > risk than benefit, which i agree with. > > Those FANG companies have the resources to lead the way, but if they are > balkiing .... it’s a tall order to ask the rest of us (we have to buy our own > lunch crowd) to jump in the pool. > > But, icann is rationally raising the “never waste a good outage” to advance > your tired agenda. > > CB > > > > On Sun, Feb 24, 2019 at 7:43 PM Montgomery, Douglas (Fed) <do...@nist.gov> > wrote: > Keith, > > You are right, if you can compromise a registrar that permits DNSSEC to be > disabled (without notification/confirmation to POCs etc), then you only have > a limited period (max of DS TTL) of protection for those resolvers that have > already cached the DS. > > If that makes DNSSEC irrelevant in this specific scenario is in the eye of > the beholder I guess. I agree in that specific scenario it is not > preventative. > > In the 3rd attack noted below, do we know if the CA that issued the DV CERTS > does DNSSEC validation on its DNS challenge queries? > > Hopefully folks who deploy DNSSEC signed zones test validation on their > domains on a regular basis, and I would hope that a CA issuing DV CERTS would > do DNSSEC validation on signed zones in their DNS challenges. > > Given that this is only one vector for attacks of a similar style, it seems > like locking down the underlying infrastructure is still a good idea. > > The paper below mentioned in a NANOG talk last week gives food for thought. > > Bamboozling Certificate Authorities with BGP > https://www.usenix.org/conference/usenixsecurity18/presentation/birge-lee > > dougm > -- > DougM at NIST > > > On 2/24/19, 8:52 PM, "Keith Medcalf" <kmedc...@dessus.com> wrote: > > > Obviously none of y'all read the report. Here is the relevant quote: > > """" > DNSSEC protects applications from using forged or manipulated DNS data, > by requiring that all DNS queries for a given domain or set of domains be > digitally signed. In DNSSEC, if a name server determines that the address > record for a given domain has not been modified in transit, it resolves the > domain and lets the user visit the site. If, however, that record has been > modified in some way or doesn’t match the domain requested, the name server > blocks the user from reaching the fraudulent address. > > While DNSSEC can be an effective tool for mitigating attacks such as > those launched by DNSpionage, only about 20 percent of the world’s major > networks and Web sites have enabled it, according to measurements gathered by > APNIC, the regional Internet address registry for the Asia-Pacific region. > > Jogbäck said Netnod’s infrastructure suffered three separate attacks from > the DNSpionage attackers. The first two occurred in a two-week window between > Dec. 14, 2018 and Jan. 2, 2019, and targeted company servers that were not > protected by DNSSEC. > > However, he said the third attack between Dec. 29 and Jan. 2 targeted > Netnod infrastructure that was protected by DNSSEC and serving its own > internal email network. Yet, because the attackers already had access to its > registrar’s systems, they were able to briefly disable that safeguard — or at > least long enough to obtain SSL certificates for two of Netnod’s email > servers. > > Jogbäck told KrebsOnSecurity that once the attackers had those > certificates, they re-enabled DNSSEC for the company’s targeted servers while > apparently preparing to launch the second stage of the attack — diverting > traffic flowing through its mail servers to machines the attackers > controlled. But Jogbäck said that for whatever reason, the attackers > neglected to use their unauthorized access to its registrar to disable DNSSEC > before later attempting to siphon Internet traffic. > > “Luckily for us, they forgot to remove that when they launched their > man-in-the-middle attack,” he said. “If they had been more skilled they would > have removed DNSSEC on the domain, which they could have done.” > """ > > If you manage to get access to the change the dns delegation at the > parent you can also turn DNSSEC off. Clearly the scripties managed to do > this once but "forgot" to do it the second time around ... That they also > "forgot" to disable DNSSEC on PCH is not particularly relevant. It only goes > to prove my point that DNSSEC is irrelevant and only gives a false sense of > security (for this particular attack vector). I suppose you could have > really long timeouts on your DS records, but that would merely "complicate" > matters for the scripties and would not be protective ... > > > --- > The fact that there's a Highway to Hell but only a Stairway to Heaven > says a lot about anticipated traffic volume. > > >-----Original Message----- > >From: Montgomery, Douglas (Fed) [mailto:do...@nist.gov] > >Sent: Sunday, 24 February, 2019 15:38 > >To: nanog@nanog.org > >Cc: kmedc...@dessus.com > >Subject: RE: A Deep Dive on the Recent Widespread DNS Hijacking > > > >You might have missed reading the very article you cite. > > > >"Woodcock said PCH’s reliance on DNSSEC almost completely blocked > >that attack, but that it managed to snare email credentials for two > >employees who were traveling at the time. > >.... > >Aside from that, DNSSEC saved us from being really, thoroughly > >owned.” > > > > > > > >Or maybe ACME .. > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-acme-acme-&data=02%7C01%7Cdougm%40nist.gov%7C83bd930ed9fd46f3bf9a08d69ac3d867%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636866563276432264&sdata=%2B6dEhg63cXX3MiBx8tWgFY6zoGmqqSxC1aE3RfOLVqc%3D&reserved=0 > >12#section-11.2 > > > >"It is therefore RECOMMENDED that ACME-based CAs make all DNS queries > >via DNSSEC-validating stub or recursive resolvers. This provides > >additional protection to domains which choose to make use of DNSSEC.” > > > >I am not sure how many of the domains listed as being hijacked are > >DNSSEC signed, but it seems if they were, and had a reasonable long > >TTL on a DS record at their parent, many if not most of these could > >have been prevented/detected. > > > >ICANN seems to think that is the case: ICANN Calls for Full DNSSEC > >Deployment > > >https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fnews%2Fannouncement-2019-02-22-en&data=02%7C01%7Cdougm%40nist.gov%7C83bd930ed9fd46f3bf9a08d69ac3d867%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636866563276432264&sdata=WoLoqR%2BPBRd1dKChGSK%2BZpvP15wAZvezmPatgElG8hY%3D&reserved=0 > > > >Of course, DNSSEC is often blamed for not protecting those who did > >not deploy/use it. Not sure what can be said about that line of > >reasoning. > > > >Dougm > >-- > >Doug Montgomery, Manager Internet & Scalable Systems Research @ NIST > > > > > > > >============ > > Date: Sat, 23 Feb 2019 12:13:41 -0700 > > From: "Keith Medcalf" <kmedc...@dessus.com> > > To: "nanog@nanog.org" <nanog@nanog.org> > > Subject: RE: A Deep Dive on the Recent Widespread DNS Hijacking > > Attacks > > Message-ID: <6e31d305aee69c4d85116e6a81d0c...@mail.dessus.com> > > Content-Type: text/plain; charset="us-ascii" > > > > On Saturday, 23 February, 2019 10:03, Stephane Bortzmeyer wrote: > > > > >Very good article, very detailed, with a lot of technical > >precisions, > > >about the recent domain name hijackings (not using the DNS, just > >good > > >old hijackings at registrar or hoster). > > > > > >https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkrebsonsecurity.com%2F2019%2F02%2Fa-deep-dive-on-the-recent-&data=02%7C01%7Cdougm%40nist.gov%7C83bd930ed9fd46f3bf9a08d69ac3d867%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636866563276432264&sdata=A0j0UwTN566qmIwxHeX5FROC6JaMDuccp3ykJSCl8%2Fk%3D&reserved=0 > >widespread-dns-hijacking-attacks/ > > > > So in other words this was just an old school script kiddie > >taking advantage of DNS registrars, the only difference being this > >was a whole whack of script kiddies acting in concert directed by a > >not-quite-so-stupid script kiddie, with some "modernz" thrown in for > >good measure. (Sounds like an NSA operation to me -- and the targets > >perfectly match those that the NSA would choose -- plus some good old > >misdirection just for the jollies of it) > > > > The second takeaway being that DNSSEC is useless in preventing > >such an occurrence because the script kiddies can merely turn it off > >at the same time as they redirect DNS. However, having DNSSEC can > >protect you from incompetent script-kiddies. It can also give you a > >false sense of security. > > > > Did I miss anything? > > > > --- > > The fact that there's a Highway to Hell but only a Stairway to > >Heaven says a lot about anticipated traffic volume. > > > > > > > > > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
