DNS-over-HTTPS

> Currently, web-based applications must use browser extensions to take advantage of advanced DNS features such as DANE, DNS-SD service discovery, or even to look up anything other than IP addresses. Extensions for features that depend on DNSSEC must validate it themselves, as the browser and the OS may not (be able to) validate DNSSEC.

If only there were some way for Google to let people take advantage of advanced DNS features without requiring browser extensions ... alas, they'd probably need to add that code to a web browser. But then, where would they find a web browser they could add such code to? Ah well. Google should ask those web browser vendors why they won't implement DNSSEC, at least. Maybe start with asking the browser with the highest market share, whichever that one is.

I find it somewhat amusing that in order to use DNS-over-HTTPS you must first resolve a domain using "normal" DNS (dns.google.com). You'd think they'd go ahead and publicly advertise a static IP for that so you can use it without relying on normal DNS.

DNSCurve solved this years ago: http://dnscurve.org , with implementation notes here: https://dnscurve.io

> (including DNS-based Internet filtering)

What guarantees that they wouldn't start filtering URLs on their own (upon request by DMCA, or FBI)?

I do get that they say what they log ( https://developers.google.com/speed/public-dns/privacy ), yet if in case this ever does become a _commonplace_ thing, they'd be easily able to obtain IP addresses of users trying to access blacklisted websites, and hand them over to officials (upon request, maybe?).

We did the same thing w/ JSON responses: https://www.openresolve.com/

This is a bad idea outside of experimentation. Not to be used for production.

If you want to secure DNS look at QUIC, TLS, or my favorite, DNSCrypt (which I funded).

I've actually just written a blogpost about it. http://www.dmitry-ishkov.com/2016/09/dns-over-https.html You can run a local DNS server which is gonna use Google's DNS-over-HTTPS. But as eridius noticed you still have to resolve dns.google.com

Why can't you just send DNS messages over an SSL/TLS socket? What's the value add for http and REST?

Pretty cool, DNS as an API:

- JSON: https://dns.google.com/resolve?name=doma.io

- Web interface: https://dns.google.com/query?name=doma.io&type=A&dnssec=true

nice toy, but there are some things to be considered:

1) "secure DNS" is a solved problem 2) DNS is simple 3) responses normally easily fit inside one packet 4) DNS is fast

HTTPS is a slow, wordy and inefficient protocol. Forcing everything into JSON just compounds the problem.

HTTP-over-DNS would also be neat :) I think I would be able to get internet access in some airports if I had HTTP-over-DNS

Why doesn't Google include the entire DNSSEC signature chain in the response? Their current approach to DNSSEC validation seems quite weak. Sure, I can query them and get an answer with AD set, but then I need to trust that they didn't tamper with the response.

The "web" is becoming hack upon hack upon hack.

DNS doesn't seem very well secured against determined attackers. But at the same time I almost never hear about attacks done via DNS spoofing. So I guess it harder to attack than I think.

Sometimes I think we should all take the Apple approach to this kind of things and deprecate old stuff and/or make new stuff mandatory.

We could just force DNS extensions to be implemented in most/all client/server implementations.

DNS over HTTPS might be okay and work well, but imho is a (smart?) workaround, not a fix.

Why can't we all set a time window (7.5 years? 10 years? 15 years?) to plan massive RFC/protocols updates with possibly-breaking changes?

Edit:fix grammar (not native speaker of English)

What's the purpose of explicitly specifying the "random_padding" parameter? Couldn't the client send any arbitrary unused query argument as padding?

Why not DNS over TLS? https://tools.ietf.org/html/rfc7858

Shameless plug (again): https://github.com/pforemski/dingo

You know, I've had thoughts along similar lines in the email space (SMTP). HTTP is such a fantastic protocol and an amazing amount of engineering effort has gone into it compared to SMTP. I've wondered whether there would be any interest in defining a translation from SMTP into HTTP, with an eye toward eventually deprecating SMTP in the fullness of time.

For example, to send an email, perhaps you just send an HTTP POST request to a canonical endpoint (email.example.com), instead of all the rigamarole that SMTP servers require with a unique text protocol requiring multiple round trips. Have you seen the number of SMTP commands involved in sending a single email? Here's an abbreviated transcript of what it's like to send an email using `telnet`:

  # Wait for banner from server (RT #1)
  220 email-inbound-relay-1234.example.com ESMTP Sendmail 1.0.0; Thu, 29 Sep 2016 19:22:12 GMT
  
  # Send EHLO and wait for reply (RT #2)
  EHLO example.com
  250-email-inbound-relay-1234.example.com Hello ws-1.example.com [1.2.3.4], pleased to meet you
  250-ENHANCEDSTATUSCODES
  250-PIPELINING
  250-EXPN
  ...
  250 HELP

  # At this phase you should really send STARTTLS and negotiate a TLS connection,
  # but we'll just ignore that for now and proceed plaintext.
  
  # Specify sender (RT #3)
  MAIL FROM: jcrites@example.com
  250 2.1.0 jcrites@example.com... Sender ok
  
  # Specify recipient (RT #4)
  RCPT TO: jcrites@example.net
  250 2.1.5 jcrites@example.net... Recipient ok
  
  # Specify message headers and content (RT #5)
  DATA
  354 Enter mail, end with "." on a line by itself
  Subject: Hello, world!
  
  Fun stuff
  .

  # Wait for reply (RT #6) 
  250 2.0.0 u8U1LC1l022963 Message accepted for delivery

Furthermore, if you skip these steps or front-run them, some servers will consider that suspicious or spammy behavior. (RFC 2920 properly allows this as an extension called pipelining, advertised in the EHLO reply above.)

With full use of SMTP extensions, things are a bit better than I imply but still frustratingly suboptimal. For example, I've run across ISPs who purely for their own load management reasons want to close an SMTP session at the TCP level after an arbitrary number of emails have been sent (N < 100)! Why would they desire that? If we're going to exchange more messages, then it's certainly less efficient for us both to negotiate a new TCP session and TLS session, rather than reuse the one we already have, but such is the practice of email. So message sending often can be as inefficient as this. When sending to some ISPs worldwide it's not uncommon for a single message to take seconds to deliver under normal network conditions.

How about we replace all of that with an HTTP POST to email.example.com, specifying the email headers and content with the POST body, and the sender and recipient as headers or querystring parameters? I think it'd be nice to get there eventually rather than drag SMTP on forever. All of the effort that goes into HTTP clients, servers, and security could benefit the email community as well.

Proper TLS security is still nascent in SMTP -- only because of Google's actions with Gmail and their Safer Email [1] initiative has TLS really come into widespread adoption at all. Today, although a lot of email is nominally taking place over TLS, most clients are not involving any sort of path validation and the connections are susceptible to MITM; and email clients don't specify client TLS certificates nor do servers examine them. If we were to employ it, TLS client certificate authentication could be an effective way to prevent email forgery, e.g., require email from example.com to be sent from a client with a TLS certificate for that domain. This kind of thing would be much easier to achieve in the HTTP world than in the SMTP world. We could also take advantage of HTTP/2 pipelining to efficiently deliver a lot of traffic across just one TCP connection.

We'd still need most of the effort invested into email, such as all of the effort fighting abuse, and mail servers would still need to buffer outbound messages and authenticate inbound ones, etc. (and we'd still need SPF, DKIM, DMARC) but at least it would simplify the foundational and protocol-level work, like what's involved in bootstrapping a new email client or server from scratch. You could write basic code to send an email in a few minutes using an HTTP library in any language. SMTP is pretty well entrenched, however, and the incremental benefit is probably not large enough, so I don't have my hopes up.

[1] https://www.google.com/transparencyreport/saferemail/

DNS-over-QUIC would be a much more compelling technical proposal from Google as a standard

This won't be overly useful (to me) unless/until the system resolver supports this and I can implement this on my own DNS server(s). Seems like a good idea, though.

So to resolve a domain to an IP address without using regular DNS they have opted to use HTTPS which really requires a certificate to be signed against a domain via DNS.

I think this could be more useful if there was a local client that installs and proxies. E.g., A traditional query to localhost:53 gets translated to DNS-over-HTTPS.

I wonder what the performance hit of something like this would be. It seems like the ssl connection would be a bottle neck for the page load.

This is great, but google doesn't need to eavesdrop on us when they compel us to use their avenues for our every action.

Is there a matrix of X-over-Y implementations? I would assume that we are converging to a fully filled matrix.

Why do I need dns over http?

That's fantastic. Wondering why this hasn't happened before?

I find it amusing that they chose apple.com for the example.

httpresolver.py implements DNS over HTTPS in a fork of Paul Chakravarti's dnslib. I have it running as a resolver for my Mac using the command:

sudo python3 httpresolver.py

Have a play with https://bitbucket.org/tony_allan/dnslib

Why is this news? Any protocol can (usually trivially) be tunneled over http(s).

Great idea! Even more leverage for a DDoS attack!

It is a quicksand this idea, it seems fine until you rely on it and are shaken by attacks that just make your service unavailable with very few computers and traffic. And then you are screwed because we still hardly know howto prevent DDoS except by having a huge bandwidth compared to the attackers. Unless you are a megacorp with huge datacenters everywhere it is a bad idea.

But well Google will never become a monopolistic company that behave assholishly, right? They would never push standards that favors them other the few remaining hosting companies on the internet. Wouldn't they?