SoylentNews is people
SoylentNews
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: 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?