ICANN Urges Adopting DNSSEC Now:
Continuing attacks on directory name services have prompted ICANN to prompt enterprise DNS uses to push their suppliers for DNSSEC services to block some of these attacks that can compromise corporate data.
Powerful malicious actors continue to be a substantial risk to key parts of the Internet and its Domain Name System security infrastructure, so much so that The Internet Corporation for Assigned Names and Numbers is calling for an intensified community effort to install stronger DNS security technology.
Specifically ICANN is calling for full deployment of the Domain Name System Security Extensions (DNSSEC) across all unsecured domain names. DNS, often called the internet’s phonebook, is part of the global internet infrastructure that translates between common language domain names and IP addresses that computers need to access websites or send emails. DNSSEC adds a layer of security on top of DNS.
[...]Full deployment of DNSSEC ensures end users are connecting to the actual web site or other service corresponding to a particular domain name, ICANN says “Although this will not solve all the security problems of the Internet, it does protect a critical piece of it – the directory lookup – complementing other technologies such as SSL (https:) that protect the "conversation", and provide a platform for yet-to-be-developed security improvements,” ICANN says.
In a release calling for the increased use of DNSSEC technologies, ICANN noted that recent public reports show a pattern of multifaceted attacks utilizing different methodologies.
“Some of the attacks target the DNS, in which unauthorized changes to the delegation structure of domain names are made, replacing the addresses of intended servers with addresses of machines controlled by the attackers. This particular type of attack, which targets the DNS, only works when DNSSEC is not in use,” ICANN stated.
[...]ICANN offered a checklist of recommended security precautions that members of the domain-name industry, registries, registrars, resellers and related others shoudl[sic] take to protect their systems, their customers’ systems and information reachable via the DNS.
Make sure you know where you are going.
(Score: 1, Interesting) by Anonymous Coward on Monday April 22 2019, @07:43AM (4 children)
Yeah, right. So this means I will be able to access the SoylentNews IRC channel, even if I am not originating from the monolingual North American Region? (You know who you are, Gringos!) And will I be able to log in to SoylentNews from HongKong, or is that not white enough for this site? Point is, shit is already happening.
(Score: 1, Interesting) by Anonymous Coward on Monday April 22 2019, @08:15AM (3 children)
Mod me troll, hijos de madres que nunca tuvieron sexo!
(Score: 1, Informative) by Anonymous Coward on Monday April 22 2019, @08:16AM
وزارة الدفاع لي القزم ، يا أبناء الأمهات الذين لم يمارسوا الجنس
(Score: 3, Interesting) by aristarchus on Monday April 22 2019, @08:17AM
mod me troll, εσείς οι γιοι των μητέρων που δεν είχαν ποτέ σεξ!
(Score: 0) by Anonymous Coward on Monday April 22 2019, @08:19AM
モッド私トロール、あなたはセックスをしたことがない母親の息子たち！
Seems better, in the original Nihongo.
(Score: 0) by Anonymous Coward on Monday April 22 2019, @08:09AM (4 children)
That's government, and your boss that pays the bills, especially your boss who is in bed with the government, and no you can't do anything about it.
I foresee the internet broken up into country specific networks, with only the "Official" class and higher allowed access to networks across borders, even then, it will be tightly controlled and monitored.
(Score: 2) by MostCynical on Monday April 22 2019, @08:22AM (1 child)
Considering China's apparent sucess and the proposals for other "great firewalls" (UK, USA, Australia), I will not bet against your prognostications.
http://www.itpro.co.uk/security/27236/national-cyber-security-centre-to-fight-hackers-with-dns-filtering [itpro.co.uk]
"I guess once you start doubting, there's no end to it." -Batou, Ghost in the Shell: Stand Alone Complex
(Score: 3, Informative) by c0lo on Monday April 22 2019, @10:07PM
https://freedomhouse.org/report/freedom-net/freedom-net-2018/rise-digital-authoritarianism [freedomhouse.org]
https://freedomhouse.org/report/countries-net-freedom-2018 [freedomhouse.org] (smaller scores are better)
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 0) by Anonymous Coward on Monday April 22 2019, @01:17PM
yet another testing for censorship is already ongoing on sri lanka
(Score: 0) by Anonymous Coward on Monday April 22 2019, @02:44PM
Maybe not in the west. It will just be expensive and low bandwidth, like the days of FidoNet.
(Score: 3, Interesting) by darkfeline on Monday April 22 2019, @08:17AM (8 children)
Wider adoption of DNSSEC would be welcome, but it shouldn't really increase security, unless you were already doing it wrong.
Most traffic now goes over SSL (TLS for you pedants). Even if you MITM the DNS, the cert check will fail. SSH checks the host key. I can't think of any other protocols that don't already do any host validation that would be vulnerable.
The other side is that even if DNSSEC were more widely provided, most users can't/won't take advantage of it. You have to be using a recursive resolver that validates DNSSEC, which I suspect most don't (I believe Google and Cloudflare resolvers do validate it). You also need a secure connection to your resolver, which means using DNS over HTTPS or DNS over SSL (TLS for you pedants). Most applications don't even support DNS over HTTPS/SSL, so you have to run a stub resolver on localhost.
Probably the easiest way to do it is to either run a stub resolver that connects to Google/Cloudflare DNS, or run your own local recursive resolver that does validate DNSSEC. Either way you have to change your DNS to 127.0.0.1.
Join the SDF Public Access UNIX System today!
(Score: 2) by Pino P on Monday April 22 2019, @03:11PM (2 children)
Consider a case in which the attacker MITMs resources accessed by a certificate authority during certificate issuance or renewal, convinces the CA to issue a certificate to the attacker, and uses this misissued certificate to install malware on victims' devices before the site owner notices the misissuance in Certificate Transparency logs. How would a cert check fail in this case?
(Score: 2) by darkfeline on Tuesday April 23 2019, @03:56AM (1 child)
Uh, why is the CA depending on the result of a unsecured DNS query to issue a cert to an attacker?
If you're in a situation where DNSSEC is the only thing stopping someone from compromising a CA, then something has gone horribly wrong, and DNSSEC is the least of your problems.
Quick review, DNSSEC guarantees that the IP you get back from a hostname lookup is correct.
If you're not using application level host verification, you have no guarantee that you are actually communicating with that IP. IP has no security, anyone on any intervening networks can MITM at the IP level.
That's kind of why the host verification part of HTTPS exists, because an HTTP request to 1.2.3.4 is not actually guaranteed to served by 1.2.3.4.
Join the SDF Public Access UNIX System today!
(Score: 2) by Pino P on Tuesday April 23 2019, @01:15PM
Because that's how the dns-01 challenge of the ACME protocol [certifytheweb.com] works: the CA returns a string, the domain owner adds the string to a TXT record, and the CA retrieves it and issues the certificate.
Ideally, DANE would allow a domain owner to publish a domain-validated certificate for a host in DNSSEC. But because of historical oversights in DNSSEC implementation, such as the initial use of a 1024-bit signing key and GoDaddy's decision to charge extra for DNSSEC, browsers have not implemented DANE.
(Score: 0) by Anonymous Coward on Monday April 22 2019, @08:50PM
DNSSEC drastically increases security, if you know what the actual threat models are beyond simple HTTP security. First, DNS hijacking is wonderful for sending spam from otherwise legitimate and high-reputation domains. Second, subdomain hijacking is on the rise, as it is harder to evade detection even with automated monitoring. Third, it can be used as a DoS attack, by NXDOMAIN or black-holing name servers. It can be used for DDoSing, by aiming the NS records somewhere nefarious. And those are just the ones I know off hand.
(Score: 0) by Anonymous Coward on Tuesday April 23 2019, @12:19AM (3 children)
I believe issues are being mixed up.
Encrypted traffic to an unverified recipient is unsafe. If someone registered bunkofamerica.com and has valid certs for that domain, browsers won't complain if the bad guy directed traffic to that site by corrupting DNS records.
DNSSEC proves identity.
DNS over TLS is more about privacy, shielding what domains are being requested. In that case, one should never use Google DNS servers, no matter what features they support.
(Score: 2) by darkfeline on Tuesday April 23 2019, @03:51AM (2 children)
>If someone registered bunkofamerica.com and has valid certs for that domain, browsers won't complain if the bad guy directed traffic to that site by corrupting DNS records.
Uh, yes it will. The browser requested the URL on bankofamerica.com, and when it gets back a cert for bunkofamerica.com, it will raise a huge red flag. That's kind of how HTTPS works.
>DNSSEC proves identity.
No it doesn't. It proves that the IP you get back for a hostname is indeed the IP that the owner of the domain said that hostname should go to.
If you then send a packet to that IP, you have no proof the packet you get back is from that IP. IP has no security. That's why you always need application level host verification.
>DNS over TLS is more about privacy
No it isn't. Whatever you're using as your recursive resolver will always have access to your DNS queries. DNS over TLS is about trust, including the trust that your recursive resolver doesn't violate your privacy, if you care about that.
Join the SDF Public Access UNIX System today!
(Score: 2) by Pino P on Tuesday April 23 2019, @01:20PM
That doesn't help the typosquatting case where the attacker tricks the user into navigating to bunkofamerica.com or bankofarnerica.com (that's RN) instead of bankofamerica.com. Many criticisms of the Let's Encrypt CA actually turn out to be criticisms of domain-validated certificates in general, such as their propensity for this sort of typosquatting.
(Score: 0) by Anonymous Coward on Tuesday April 23 2019, @11:05PM
You need to think about what you're writing. Why do you think a bad guy would want to misdirect or alter DNS records? Certainly not to lead the user to the site or service the user intended. If the user doesn't check either the location field or better, the certificate details, the user is screwed. That's the intention the bad guy has.
DNS over TLS/HTTPS doesn't fix the authentication problem. Unauthenticated encryption is always a mistake for every serious situation. If a DNS server is poorly configured and accepts unauthorized zone transfers, the encrypted traffic will securely transfer wrong/altered records.
The only way to modify DNSSEC signatures is if the DNS server admin left unprotected private keys laying around and also left domain registration authorization laying around. If the bad guy somehow is able to alter the signing keys, their fingerprints won't match those recorded with the upper domain branch.
And, DNS over TLS is about privacy. If the browser asks for records that include "+dnssec", validity is confirmed or denied whether traffic to DNS servers was encrypted or not. A MITM can't create valid signatures. So, what other reason to add on TLS, if not privacy?
(Score: 0) by Anonymous Coward on Monday April 22 2019, @09:11AM (4 children)
What exactly problem does it solve?
It gives DNS control into other malicious actors. We had this over and over since 1994, when people told that Internet without academic curation will turn into a TV. It turned.
Mozilla did similar thing once, with Cloudflare - a company known of fighting anonymity in the Internet and massively collecting metadata.
The solution is:
1. Encrypted, distributed DNS, maybe blockchain-based. There was something similar with own TLDs, unfortunately lost popularity as had less media paid advertising than "social media".
2. If ISP modifies the traffic - this is violation of agreement, so punish with fine exceeding income. As "potential losses (tm)" exceed real losses, and we all believe in this "potential losses (tm)" BS when it comes to "intellecshual property (tm)", so why use it only against "goyim"?
(Score: 2) by Pino P on Monday April 22 2019, @03:15PM (1 child)
Are you thinking of Namecoin [wikipedia.org], which uses the .bit pseudo-TLD? Or OpenNIC?
Unless the only ISP in town or all ISPs in town have a provision in their agreement allowing the ISP to modify traffic, ostensibly to protect the customer premises equipment from cyber-intruders or to enforce court orders.
(Score: 2) by c0lo on Monday April 22 2019, @10:21PM
Namecoin is shit. From Wikipedia:
Add to this the insane amount of effort to do the proof of work in advanced stages and you'll get something that will gradually fall into the hands of organizations that can support the cost.
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 0) by Anonymous Coward on Monday April 22 2019, @09:16PM
Gee, they seemed to have a decent point but lost it at the end with their anti-semitism. Oh well, maybe next year we can have nice things.
(Score: 1) by mmlj4 on Friday May 03 2019, @02:18PM
There is no need for encrypted DNS, and in fact if DNS data were encrypted none of it would work at all.
What we do have is signed responses, and any tampering is immediately evident. But not all operating systems and DNS clients (nslookup, for example) support DNSsec.
Need a Linux consultant [joeykelly.net] in New Orleans?
(Score: 2) by Gaaark on Monday April 22 2019, @11:20AM (1 child)
I heard that the Wizards of the Internet were going to let Jenn take care of the Internet for a while: SHE'S employee of the MONTH!
--- Please remind me if I haven't been civil to you: I'm channeling MDC. ---Gaaark 2.0 ---
(Score: 0) by Anonymous Coward on Monday April 22 2019, @01:35PM
+1 for the "The IT Crowd" reference! :D
(Score: 0) by Anonymous Coward on Monday April 22 2019, @11:56PM
DNSSEC allows verification of DNS records. Records are digitally signed. That's it.
Validation comes from: 1) Register companies deny registration of a domain by more than one entity. 2) Authoritative servers provide public key fingerprints of their keys to the register. This process continues back to the root domain. This essentially creates a chain of trust.
Signed 256 bit hashes of DNS records are difficult to fake and if resolving servers check signatures, then records can be confirmed with good certainty.