1

I would like a comprehensive explanation of the security and privacy risks that come with DNS prefetching. There are already other posts about this topic, but I want current information and feedback on my concerns. Thanks in advance.

The Helmet.js documentation says X-DNS-Prefetch-Control is turned off to improve user privacy, but doesn't explain why DNS prefetching is a privacy concern. Is turning DNS prefetching off generally a good default?

helmet.dnsPrefetchControl sets the X-DNS-Prefetch-Control header to help control DNS prefetching, which can improve user privacy at the expense of performance. See documentation on MDN for more.

I've read that DNS prefetching is done in plaintext, which can reveal information if there's a MITM attack, but is that information current? If so, why are the requests plaintext?

This article shows how you can bypass the CSP with DNS prefetching. Have things changed since the article was written in 2016?

I feel that this OWASP Cheatsheet excerpt should be included so you know what I know.

The default behavior of browsers is to perform DNS caching which is good for most websites. If you do not control links on your website, you might want to set off as a value to disable DNS prefetch to avoid leaking information to those domains.

1 Answer 1

-2

Is turning DNS prefetching off generally a good default?

It depends, if you control the links on your page (no links are generated outside your control), then pre-fetching can speed up page responsiveness. Turning it off is a security measure.

I've read that DNS prefetching is done in plaintext, which can reveal information if there's a MITM attack, but is that information current?

Yes, it's still potentially current. Public DNS requests are not encrypted traffic. DNS requests can be MITM attacked being you get manipulated DNS response and redirected to an attacker site. As in the article you linked, the plaintext of a DNS request can also expose data on your machine if the page is compromised and the prefetch is enabled.

There is also encrypted DNS servers that is now more available (cloudflare 1.1.1.1 server), but I believe most DNS servers are not encrypted.

The NIST SP 800-53 recommends using authenticated DNS servers (SC-20 and SC-21) that can sign and validate DNS responses. This doesn't change the leaking of data through DNS queries, but assuming all other security controls in your environment are in place, the risk is low.

https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r5.pdf

If so, why are the requests plaintext?

DNS is an old protocol, old systems and software may not be updated to support encrypted DNS. So plaintext is still available and standard.

Have things changed since the article was written in 2016?

Not entirely, we have encrypted DNS now, but it's not standard or required. Those threats are still viable, but you must have an attacker on the network the client is on, and the page the client is visiting must be compromised. This could be an insider threat attack on an intranet site, this could leak data that would otherwise be caught by the CSP.

An example; Your ISP can see sites you access (ie. mynaughtysite.com) from the DNS query plaintext. But a compromised webpage could expose private data by making the DNS query of johnsmith.5553540994.mynaughtysite.com exposing the name and phone number of the user, or any data the user may put in, including password or other data the page can collect. Using ARP poisoning MITM attacks or seeing it on an unencrypted wifi exposes this data to the attacker.

you might want to set off as a value to disable DNS prefetch to avoid leaking information to those domains.

As far as this statement in the OWASP Cheatsheet, it sounds a bit misleading. Making a DNS query doesn't leak data to the domain being queried. It may leak data to the network, or to the networks in the DNS route.

If the discussion below is correct, then yes DNS queries could also be forwarded from the public DNS server to another authoratative DNS for that domain. Being, johnsmith.5553540994.mynaughtysite.com gets passed from the public DNS server, making a query to mynaughtysite.com's "DNS server". Thus exposing the data added into the query to the attackers systems.

However, If the browser pre-fetches the webpage (not just the DNS query) that's a differnt discussion and could connect to bad sites just from a user posted comment adding the link to mybadwebsite.com, now letting the domain owner see the connection potentially identifying the IP of a victim.

If your page is compromised it can then generate links that can leak information through that domain name (or URL) itself, the user's browser attempting to pre-chache the page, connecting to the bad site (not just the DNS request) generating a link johnsmith.myp4s$w0rdlol.mybadsite.com exposing the username and password he just put in, to the attackers domain.

(I think special characters might have to be obfuscated, but the point is still there.)

6
  • "Making a DNS query doesn't leak data to the domain being queried" You just gave an example where it does.
    – Ben Voigt
    Commented Mar 1, 2023 at 15:45
  • @ben voigt, You're wrong. A DNS query itself does not contact the domain name I've queried. With one exception, the DNS itself is the domain controller in question. Me querying a public DNS 4.4.2.2 for www.google.com does not inform google.com that I've requested www subdomain. Everyone in the DNS path can see the DNS request, but not google.com. What I suggest is a browser prefetching a page will contact the domain server, not just a DNS query. Commented Mar 1, 2023 at 16:20
  • @AustereGrim: The authoritative name server for the domain is in the DNS path. Because these unique sidechannel names will never be cache hits.
    – Ben Voigt
    Commented Mar 1, 2023 at 16:53
  • 1
    And note that DNS encryption will not prevent the request from being passed to the domain's own DNS server. It only protects against on-path disclosure.
    – Ben Voigt
    Commented Mar 1, 2023 at 17:18
  • 1
    Quite definitely -- That's how DNS uses an NS record.
    – Ben Voigt
    Commented Mar 3, 2023 at 15:27

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .