DNS over HTTPS

https://github.com/curl/curl/wiki/DNS-over-HTTPS

by sohkamyung • 9 years ago

284 181 9 years ago

for privacy, performance and security.

I understand the privacy and security aspects. But I am wondering - how can DNS over HTTPS be more performant in the case of curl commands? A browser could probably persist the connection to the resolver and issue several requests together, but with a single curl command surely there's the overhead of initiating the first DNS resolve, the HTTPS connection, the second DNS resolve. There must be some delay compared to regular DNS.

Side note - I just learned that performant is not a recognized word (https://english.stackexchange.com/questions/38945/what-is-wr...)

CogitoCogito• 9 years ago

Side note - I just learned that performant is not a recognized word (https://english.stackexchange.com/questions/38945/what-is-wr...)

I don't personally use the word since there are many alternatives, but its use is now definitely widespread and consistently understood. There's really no argument against the fact that it has entered the English lexicon.

metafunctor2• 9 years ago

Can anyone give examples of cases where “performant” would be better than “efficient”?

To my mind, the difference is that “performant” delivers results quickly, whereas “efficient” uses little energy. A performant solution might be efficient, but not necessarily, and vice versa. Does anyone else share this understanding or am I living in a linguistic bubble?

Not sure about Swedish (Daniel is Swedish), but in Finnish, we have the word “suorituskykyinen”, meaning “efficient” or “able to perform”. I can see how Finnish writers might want to use “performant” to replace this commonly used word. Perhaps there's a similar history for Swedish speakers? I sure have seen “performant” a lot in academic texts written by Finnish and Swedish speakers in the last 20 years.

userbinator• 9 years ago

I don't use it either, and I agree with the poster on that stackexchange link about it sounding like manager/marketing-speak, but when I see it, it makes me pause for a second to think about what really means (perhaps that's the point) --- I had this exchange with a coworker not long ago:

CW: ...and this way it'll be more performant too.

Me: Performant? As in faster?

CW: Yes.

Me (to self): Then why didn't you just say it'll be faster?

IMHO it obfuscates meaning and should be avoided; the surrounding discussion/vagueness about what it means (I don't think it means efficient, but only faster --- as in, a high-performance car) shows that too.

karmakaze• 9 years ago

Great discussion. I've used the word without thinking twice. Now I'll choose between efficient, faster, or performant depending on context.

coinerone• 9 years ago

"Performant" is a word in German. It translates to exact what "perfomant" would mean in english if it were an english word. The funny thing is, google translate, translates the german word "performant" to the english word "performant". https://translate.google.com/?hl=de#de/en/per%C2%ADfor%C2%AD...

nijaru• 9 years ago

It is not actually translating anything since performant is not considered a real word in English, although I commonly see it used in the tech world.

Nux• 9 years ago

We have this word "performant" in Romanian, too, it means something that performs well; it's not limited to IT parlance.

I just checked and the French have it too, I can see how it has slowly made its way into English, through immigration and especially the Internet.

A live language is always changing, resistance is futile. :)

yeukhon2• 9 years ago

cURL supports it. See https://ec.haxx.se/usingcurl-persist.html

If your question is how to reuse the connection pool for, say, 1000 DNS queries from one machine, curl already uses a connection pool. Next, to use fewer TCP connections and get faster response, my first proposal is HTTP/2 which supports TCP multiplexing such that multiple requests can be issued over a single TCP connection. Every response is return asynchronously, we can achieve nonblocking.

cURL also supports HTTP/2.

Speaking of word: it seems author of curl project prefers “curl” over “cURL”? Worth asking.

sapphire_tomb• 9 years ago

From what I understand the "cURL" format of the word is popular mostly with users of the PHP bindings. "curl" is what the project uses, but I'm not sure they really care what other people refer to it as :)

pilif• 9 years ago

Every response is return asynchronously, we can achieve nonblocking.

same goes for UDP which DNS runs over normally.

Like the original commenter, I fail to see how stacking DNS over HTTP over TLS over TCP over IP is going to be faster than running DNS over UDP over IP.

Also, you still need to resolve the address of your DNS-over-HTTP server, which you'd probably still do over traditional DNS-over-UDP.

This feels like doing nothing but adding complexity for zero gain.

tscs37• 9 years ago

Ideally the browser and curl only use a local resolver, on your machine or router, which in turn can use a steadily alive or even multiple alive connections to the resolver.

geofft• 9 years ago

If your ISP is intercepting DNS requests and sending them to a slow or broken server, DNS over HTTPS ensures this won't happen. (Yes, they could block the traffic entirely, or slow it down for fun, but they can no longer intercept and redirect it.)

nly4• 9 years ago

It has zero performance advantages

If you had to go the TLS route and wanted better perf, then it'd make more sense to build a new, dead simple, framing protocol that actually specified working pipelining and eliminated HOL blocking by allowing out-of-order responses.

They're just using HTTP because HTTP(S) defaults to port 443 and it'll go through more firewalls, and I guess their thinking here is to (just add more complexity) and move to HTTP/2

Franciscouzo• 9 years ago

It is a recognized word, at least by the Cambridge [0], Oxford [1], and Wiktionary [2] dictionaries.

[0] https://dictionary.cambridge.org/dictionary/english/performa...

[1] https://en.oxforddictionaries.com/definition/performant

[2] https://en.wiktionary.org/wiki/performant

djrobstep• 9 years ago

If you recognize it, it's a recognized word.

Dictionaries are descriptive, not prescriptive.

tzahola2• 9 years ago

Isn’t this a chicken vs egg problem?

jayflux• 9 years ago

Yes and no, I think Google’s DNS over HTTPS service is run on 8.8.8.8 the same IP for their main dns service, so you should always know where it is.

Edit: Looks like it’s changed and it’s now a url, so you’re right it is a bit chicken and egg

dyu• 9 years ago

You can remember a small set of resolved hosts for this purpose, not unlike remembering DNS servers or CAs to trust. A quick search online also says it's possible to issue a cert to a public IP address, so you can also do HTTPS to a numbered IP instead of a host name.

tzahola2• 9 years ago

I haven't heard of any respectable CAs that would issue certs for IP addresses...

jlgaddis• 9 years ago

Apparently:

"The DOH server is given with a host name that itself needs to be resolved. This initial resolve needs to be done by the native resolver before DOH kicks in."

Asooka• 9 years ago

Just stick the address of the DNS resolver in /etc/hosts.

zde• 9 years ago

To understand DNS, you must first understand DNS.

chriszelazo• 9 years ago

DNS is one of those things I have to reference every time. Definitely feels like this.

therealmarv• 9 years ago

dingo - a Google DNS-over-HTTPS caching proxy in Go https://news.ycombinator.com/item?id=12514170

averagewall• 9 years ago

Where does the privacy advantage come from? Once you resolve a hostname privately, don't you still need to use its IP address publicly for your traffic to be routed there?

m_eiman• 9 years ago

One case where it might help is shared hosting: you don't know which of the domains hosted on that IP you're accessing. Narrows it down to just a few though, so IMHO not a big improvement.

mschuster91• 9 years ago

One case where it might help is shared hosting: you don't know which of the domains hosted on that IP you're accessing.

That depends on your level of access/monitoring: if it's just a firewall log that shows source/destination IP, then yes - but as soon as you have any kind of packet monitoring, then the domain can be easily sniffed from the SNI header.

pbhjpbhj7• 9 years ago

You'll need to mask page size if your trying to hide your access, even on a shared host with 100 domains I doubt you'll have pages where the byte-size isn't unique.

I think with https the results were something like 90% of page access could be guessed using meta-data (see eg https://web.archive.org/web/20090308103611/http://sysd.org/s...). That's going to drop when you don't know the site but you're going to need more counter-measures to hide your access effectively.

IshKebab2• 9 years ago

Yes, but reverse DNS is not totally trivial (think AWS). Also current DNS can easily be MitM'd allowing attackers to insert JavaScript into web pages etc.

kuschku7• 9 years ago

So what use does this have?

DNSSEC already gives us validation of the records, and thanks to SNI, this doesn't give us any privacy.

It is more complex, more centralized, and ends up slower than using actual DNS, and doesn't seem to provide any benefits.

Am I missing something?

kodablah5• 9 years ago

Easier to prevent censoring. DNSSEC doesn't hide the fact that you're making a DNS call, correct? With HTTPS, censors/MITMs can only see the domain you go to. The censor/MITM won't know whether I went to google.com to search or perform DNS query. Plenty of countries have blocked DNS providers they don't like, now that's harder w/out also blocking the site as a whole.

kuschku7• 9 years ago

Easier to prevent censoring from the ISP, but you're now just reliant on another company's systems.

If you just want a solution for having a remote server execute DNS queries for you, you can just use any of the existing VPN protocols purely for DNS resolution, or even make a better performing version.

All that overhead HTTP adds is wasted for this.

askvictor2• 9 years ago

I suspect it wouldn't be too hard for a nation state or similar to determine the signature of DNS over HTTPS requests to see if someone is making a DNS request, unless you add a bunch of noise to the transaction.

jopsen2• 9 years ago

don't you think SNI leaks will get fixed eventually?

kuschku7• 9 years ago

No. All actors currently involved with the web are ideologically opposed to backwards incompatible changes, and, as a result, they'd never make a change that prevents a browser from accessing a legacy site.

As result, SNI is here to stay.

LogicX8• 9 years ago

Yes. https://www.ietf.org/proceedings/94/slides/slides-94-tls-8.p...

tptacek• 9 years ago

There is no good reason DNSSEC shouldn't protect query privacy. It doesn't because the most important Internet users --- developers and operations engineers --- are letting them standardize it that way. If it annoys you that we have to resort to elaborate hacks to keep ISPs from monitoring our queries while at the same time undertaking huge projects to migrate to a new DNS protocol, you're not crazy, and you should make some noise. DNSSEC sees barely any use in the real world, and it is not too late to change it.

aplorbust4• 9 years ago

"... thanks to SNI, this doesn't give us any privacy."

Assumption: All sites use SNI or will use SNI.

True?

Experiment: List all domains posted to HN (pages 1-20) that require https on any given day. Try accessing each one without SNI.

Result: Most do not require SNI.

kuschku7• 9 years ago

Wrong.

SNI has to be sent without any previous negotiation. Therefore the client does not know if a site will require SNI or not.

Assumption 1: browser vendors do not want to break sites relying on SNI

(Confirmed by WHATWG)

Assumption 2: at least one major site will continue to use SNI

Conclusion: browsers will continue to send SNI.

_0w8t2• 9 years ago

I can see how DNS over HTTPS addresses security, but I do not see how it helps with privacy. After resolving the IP address over secure connection HTTPS still sends the host name unencrypted, so one can just eavesdrop on that. And if encrypted DNS becomes widespread, I suspect that various state-imposed firewalls like one Russia will just look for HTTPS connection header to block a particular site.

tylerhou• 9 years ago

After resolving the IP address over secure connection HTTPS still sends the host name unencrypted

Correct me if I'm wrong, but I'm pretty sure the host name is generally only sent in an HTTP header, which should be encrypted over HTTPS.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Ho...

pjc50• 9 years ago

No, in order to multi-host SSL sites the host name has to be sent first in order for the correct certificate to be presented.

https://en.wikipedia.org/wiki/Server_Name_Indication

deathanatos3• 9 years ago

In TLS, the server will send its certificate — and thus the domain name — in the clear.

rqs• 9 years ago

Well, unencrypted data by nature are vulnerable to tamper. Say change the DNS answer to point the client to another IP address in this case.

Of course DNS over HTTPS is not a sliver bullet that will ensure your privacy, instead, it's one step towards better security and thus (hopefully) privacy.

jopsen2• 9 years ago

Are you talking about leaking names through TLS?

As I understand it, this would fix leaking during DNS resolution, fixing any leaks from TLS is a separate issue. And yes, when that's fixed, you'll still be leaking destination IP.

But if not one step at time, how is it going to get better? :)

zeckalpha• 9 years ago

One step, but in what direction?

finchisko• 9 years ago

HTTPS still sends the host name unencrypted.

needed for webservers because of multiple domains (SNI) on single IP address. Didn't read the spec, but couldn't be hostname encrypted in case of DNS resolving? (eg. hostname can be sent in http body).

kodablah5• 9 years ago

I suspect that various state-imposed firewalls like one Russia will just look for HTTPS connection header to block a particular site.

What if that site does a lot more things? Even they can only upset their population so much by blocking entire domains. With regards to Russia, Google's DNS over HTTPS is a perfect example. "Domain fronting" is a thing for a reason.

_0w8t2• 9 years ago

In Russia the government does ban domains unless the domains are popular. At some point they even tried to ban based on IP addresses from DNS records, but people quickly learned how to use that to "ban" government-based media by changing IP addresses of banned domains to point to those sites.

LogicX8• 9 years ago

The industry stance seems to be: SNI not yet being fixed should not be an excuse to preclude work on securing the privacy of DNS requests. SNI Encryption is being discussed: https://www.ietf.org/proceedings/94/slides/slides-94-tls-8.p...

We at DNSFilter are working on client to resolver agents which use DNS over TLS as well as DNSCrypt. We're also looking to create a standard for recursive resolvers like us to communicate securely with authoritative providers (no RFC yet).

Aissen2• 9 years ago

Anyone has good pointers on DNS over DTLS (draft RFC 8094) vs DNS over TLS (RFC 7858) vs DNS over HTTPS (this draft) ? And if you could throw in DNSSEC in the mix, that would be helpful.

LogicX8• 9 years ago

With pleasure - (CTO of DNSFilter, this is my world)

DNS over DTLS (RFC 8094) speaks only to UDP This could be compared with DNSCrypt's implementation

DNS over TLS (RFC 7858) is TCP focused

DNS over HTTPs is focused on... you guessed it, HTTPs

So all the same thing, all trying to add security and privacy, just over different transport mechanisms.

While we're at it -- you did not mention DNS over QUIC: https://tools.ietf.org/id/draft-huitema-quic-dnsoquic-00.htm...

Some factors which start to come in to play with the various options are: Compatibility with firewalls and proxies (DNS over HTTPs wins, others over port 853 have a disadvantage, even if you put them on port 443, they may get stopped by deep packet inspection)

TLS Improvement knobs: 0-RTT, TCP Fast Open, etc. (You can find a summary of these here: https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Implement... )

And closely related, performance. It's tough to beat a lossy protocol with minimal overhead (UDP), but there have been a lot of improvements with Keep alive, eDNS0, pipelining, etc.

We're currently doing a lot of testing around this, as we are working to offer useragents and LAN proxies implementing DNS over TLS, compared with DNSCrypt.

Finally: DNSSEC. It lives in a different part of the 'security' spectrum here... The purpose of DNSSEC is to be able to authenticate the validity of an answer when traveling through untrusted parties (say you're using a third-party resolver, or do you trust your ISP's DNS to not mangle with responses). It does not encrypt request/responses. It does not provide privacy. It answers the question: "Can I trust this response I received for example.org to be the one that example.org intended me to receive?"

Aissen2• 9 years ago

Thanks, that's great!

I didn't even know about dns-over-QUIC, but considering QUIC is still a draft itself… (I've been excited about it for quite a while though).

Regarding middleboxes, I forgot about those, and it's very sad that they keep hindering progress this way.

vectorEQ3• 9 years ago

people invented other security things inside of dns protocol to avoid having the added bandwidth. i dont think it's reasonable to say that everyone can handle the increased load nowadays.

However, i've been thinking of this, for enterprise, you could build a dns server which servers over TLS connections, and then put a local dns proxy on clients which receives on 127.0.0.1 and sends out tls to the custom dns server. That way any local network connections would be encrypted to passive listeners on the network.

recursive queries would go onto the internet plaintext to 'normal' dns servers.

Skunkleton2• 9 years ago

You can already do this with existing tech. When a DHCP lease is acquired, you also get DNS server information. If you are concerned about the DNS packets being encrypted on your local network, then you can do that already as well by intercepting them with a local firewall and sending them across a tunnel.

IMO, the purpose of DOH is to address semi hostile environments like the free Wifi at the Airport. It is kind of like a VPN for just your DNS traffic.

alien_at_work3• 9 years ago

I really hope this doesn't catch on widely. It should be a tool for use where censorship issues can't be solved politically.

Otherwise, why even have protocols at all? Just say the only protocol is HTTP. IP, etc. are just an HTTP implementation detail.

banachtarski3• 9 years ago

I would love this to catch on wildly! DNS through TLS means it's all end-to-end encrypted, DNS reflection attacks are harder, etc. The "why even have protocols" doesn't make sense. Protocol can be layered just fine (HTTP itself is a good example). DNS as it exists now is another random special snowflake that vendors need corresponding snowflake implementations for.

alien_at_work3• 9 years ago

DNS through TLS means it's all end-to-end encrypted

I didn't say I'm against DNS being encrypted, even with TLS. I just hate that instead of doing the right thing (e.g. political battle with the government, opening a port on a firewall) people choose the laziest way: just tunnel it over HTTP.

Protocol can be layered just fine (HTTP itself is a good example)

They can, but why do it? Just figure out a way to make your server be yet-another-"REST"-service and pat yourself on the back for cleverness.

DNS as it exists now is another random special snowflake that vendors need corresponding snowflake implementations for.

As is: SMTP, POP, IMAP, SSH, AMQP, FIX, SWIFT, LDAP, ODBC and a host of other protocols. Why do you use negative language like "random special snowflake that vendors need corresponding snowflake implementations for"? These are seperate protocols, which serve seperate specific needs. This is how IP was designed to work.

qznc• 9 years ago

Why do we have ports at all? Except 80 and 443 many ports are blocked anyways.

I'd say there is an arms race between admins and users. Step by step features get forbidden and blocked usually in the name of security. For example, NAT took away your globally visible IP address.

The next step is probably blocking domains. In a dystopian vision, Google and Facebook become the proxies for all traffic as all other domains get blocked for most users.

stock_toaster2• 9 years ago

Maybe someone people will "rediscover" dnscurve.

jedisct13• 9 years ago

Which is completely unrelated

stock_toaster2• 9 years ago

It isn't completely unrelated.

DNSCurve secures the link between resolvers and authoritative servers. DNSCrypt (based on DNSCurve) secures the link between clients and resolvers.

kabes• 9 years ago

You can also do http(s) over DNS: http://code.kryo.se/iodine/ . Nice way to avoid paying captive portals, although probably not legal.

gsich10• 9 years ago

Why not?

pbhjpbhj7• 9 years ago

In USA and UK at least unauthorised access or use of a computer is criminalised. On some situations you can argue for assumed consent, the law doesn't operate on "if I can do it then it's authorised". Unless you can show you have permission then it's not authorised, ergo not legal.

AIUI; not legal advice.

ce42• 9 years ago

What does this shady technique (dns tunneling) have to do with dns-over-ssl?

gsich10• 9 years ago

why shady? (assuming that shady is meant in a negative way)

billpg• 9 years ago

Can I do HTTP over DNS over HTTP over DNS over HTTP over DNS over HTTP over DNS over HTTP over DNS?

banachtarski3• 9 years ago

You do realize DNS is not a fully featured protocol right...

jedisct13• 9 years ago

DoH's great.

I'm planning to write an Nginx module to support it soon.

bandrami2• 9 years ago

Actual DNS servers and clients have supported TLS since the early years of this decade. What's gained by adding HTTP transport overhead?

est• 9 years ago

http is not overhead, http is the only transport that can go through middle boxes.

skuzye• 9 years ago

if the traffic is encrypted how can you tell whether it's http or plain dns?

throwaway2048• 9 years ago

What dns servers and clients support TLS?

bandrami2• 9 years ago

Unbound does it natively, and BIND and the rest use DNSCrypt's shim

mosselman• 9 years ago

“...for privacy...” and “Google runs one...”

Strikes me as funny. Interesting concept apart from this detail though. Are there any servers that aren’t owned by advertisers and the like?

Skunkleton2• 9 years ago

You could stand up your own server. It isn't that hard or expensive.

aplorbust4• 9 years ago

https://stat.ripe.net/data/dns-chain/data.json?resource=exam...

https://dns-lg.sidnlabs.nl/example.com/A

philip1209• 9 years ago

We prototyped this as an intern project at OpenDNS, too: https://github.com/opendns/OpenResolve

We mostly built it because it sounded cool, but one use case that I though was important was being able to boot these images in different data centers to collect telemetry on DNS differences geographically (eg for hijacking or anycast).

LogicX8• 9 years ago

Nice project!

We at DNSFilter are able to collect that same telemetry just by having resolvers at each of the anycast locations -- between the different locations, and passing along eDNS Client Subnet information, many responses will be (legitimately) different. A little hard to see a hijack in that noise.

wannabeinggeek• 9 years ago

I am just wondering why would you want DNS over https instead of something like dnscrypt which would be dns over ssl ( I think opendns does this already) ?

icebraining• 9 years ago

My guess is meddling corporate firewalls that spy on SSL/TLS traffic (using custom certs installed on the machines) and block unrecognized traffic.

Panino• 9 years ago

DNSCrypt doesn't use SSL or TLS. You may have assumed that because DNSCrypt defaults to 443/TCP but that is only for availability, as this port is usually not blocked. The packet format is very similar to DNSCurve, from which it descends.

nly4• 9 years ago

I've been pushing all my DNS traffic over a VPN, transparently, for the whole house, for years now (by setting the VPN remote IP as the upstream resolver on my router).

It seems the only advantage of DNS-over-HTTPS is that it does DNS over TLS on port 443, which is harder for militant netadmins to block.

It's definitely a solution to a niche problem, but if we really want to encrypt DNS at scale then we could do it easily enough by introducing DNScurve to the SOHO market.

quacker• 9 years ago

DNS through a VPN is only a partial solution though, right? Even if there's a recursive/caching resolver within the VPN (so _my_ direct DNS requests are private) any DNS requests outbound from the VPN go through global DNS.

But, I guess same problem for DNS-over-HTTPS currently.

LogicX8• 9 years ago

Correct -- there's not currently any standard for recursive resolvers to communicate securely to authoritative providers. We'd like to change that.

DavideNL• 9 years ago

When you run DNS requests over VPN, you are sharing your "browsing history" with (at least) 1 other third party: whoever runs the VPN server, and whoever runs the (public) DNS server.

Your ISP can see the IPs you connect to regardless of whether you use your ISPs DNS server or not (unless of course you tunnel ALL traffic of all clients through the vpn as well.)

nly4• 8 years ago

It's low hanging fruit. Logging DNS queries is a lot cheaper for an ISP than filtering out and logging SNI entries in TLS handshakes.

fouc• 9 years ago

I'm wondering if libcurl supporting custom DNS resolvers could make it easier to explore alternative DNS systems like namecoin.

hollander• 9 years ago

OpenDNS used to offer a secure DNS-tool. I can't find it anymore. Maybe Cisco removed it? Why can't we use something like that?

LogicX8• 9 years ago

You're thinking of DNSCrypt.

It unfortunately was recently abandoned by the original developer. Some folks have mirrored it here: https://github.com/DNSCrypt

okneil• 9 years ago

As a mac user, how can I set this up locally to run all my DNS over TLS?

kernelPan1c3• 9 years ago

Yes, greater for security but still depends upon reliability of certificate authorities and ISPs. ISPs have the ability to issue the client a bogus certificate while they hold the real one in order to decrypt traffic. Why won't browsers allow the certificate's public key to be readable by javascript so that the remote server can verify the client has the correct certificate? This wouldn't be foolproof but it would significantly beef up security.

Similar to how tor hidden services get resolved, distributed hash tables seem like the way to go. Take the ISPs and Cert Authorities out of the equation.

gcr• 9 years ago

I thought modern browsers ship with pinned certificates for Google and other large companies built in to the browser download.

kernelPan1c3• 9 years ago

Public key pinning helps but it operates on the assumption that the initial key is the correct one. I find it curious that these public keys are not readable by the client.

Someone1234• 9 years ago

Why won't browsers allow the certificate's public key to be readable by javascript

Because sites would randomly block reverse proxies, web proxies, enterprise users, people using certain WiFi APs, and it would give advertisers another thing to track users on.

Frankly after looking at what websites did with the User Agent, I'm scared to see what they'd do when a certificate mismatch occurs.

nly4• 9 years ago

Making the public key of the remote available to JS wouldnt help because if you can't trust the identity of the remote server or integrity of the connection then you can't trust the javascript.

Tor hidden services are secure because of the lack of human meaningful names.

See: https://en.wikipedia.org/wiki/Zooko%27s_triangle

kernelPan1c3• 9 years ago

Yes, since you can't trust the JS, doing this would be an attempt at security through obfuscation. I mostly just think it's strange that these keys aren't accessible. If there were ever a mismatch detected, the server could at least know with certainty that there's a bad actor on the connection.

Thanks for Zooko's Traingle wiki. Hadn't seen that one before.

aplorbust4• 9 years ago

"Do DNS resolves over HTTPS for privacy, performance and security. Also makes it easier to use a name server of your choice instead of the one configured for your system."

"A server that is acting both as a normal web server and a DNS API server is in a position to choose which DNS names it forces a client to resolve (through its web service) and also be the one to answer those queries (through its DNS API service)."

https://tools.ietf.org/html/draft-ietf-doh-dns-over-https-02

How might this affect users who block ads via DNS?

What about users who want the system DNS settings they have configured (e.g. /etc/resolv.conf) to be honoured?

I can clear browser DNS cache with a couple of keystrokes, but I am not using Chrome, Firefox, IE/Edge, Safari, Brave, Opera, etc.

How easy is it for a user to clear the DNS cache in the popular browsers?

The best "privacy, performance and security" for the user is achieved by using /etc/hosts. HOSTS (i.e., no DNS) will beat DNS on all three, every time. "Flexibility" was not mentioned as a criteria.

There is also the issue of "transparency" to consider. It is easy for the user to check their HOSTS file to see what are the current name to address mappings. How easy is it for the user to check what mappings are in the browsers DNS cache?

Fact: Many/most of the names looked up by a user repeatedly every day do not change by the hour, by the day, the week, month or even year.

As a user, I use HOSTS heavily, with appropriate ed scripts for fast automated modification. I use HOSTS for the transparency, control and speed. Any privacy or security benefit is a bonus.

Contrast: https://en.wikipedia.org/wiki/Fast_flux (need DNS or perhaps "DOH" for this to work)

pas• 9 years ago

How might this affect users who block ads via DNS?

They should make sure to use a trusted DNS over HTTPS resolver.

Zash• 9 years ago

Must everything be over HTTPS? Must all diversity really be killed like this? It saddens me.

breatheoften• 9 years ago

I hate the idea of ad networks using this ...

DNS over HTTPS

Related Stories