13 ms·

DNS-over-HTTPS

321 points by mikecarlton 10y ago

deleted 10y ago
[deleted]
tigarcia 10y ago
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.
- JoshTriplett 10y ago
  Probably not much, especially if you can maintain a persistent HTTP/2 connection to the DNS server.
- Panino 10y ago
  I use DNSCurve, which adds <1ms to latency. That's with X25519 and XSalsa20-Poly1305. Assuming a persistent connection, DNS-over-HTTPS might be similar with AES-NI or ChaCha20-Poly1305. The real speed issue is the number of round trips. DNSCurve is Zero-RTT, and assuming a persistent connection, DNS-over-HTTPS should probably be too at least once it's up and running. And then consider that lots of pages have megabytes of javascript fetched from multiple sources, big and often unoptimized images, expensive screen redraws, etc. Modern crypto doesn't affect performance at all. Hell, even PQCrypto-encrypted-DNS with 64KB public keys would be fast compared to the modern web. There's no reason to worry anymore about modern crypto affecting performance. It's just not an issue.
- toast0 10y ago
  If you had the TLS connection open to Google, there's a bit of overhead because the request is longer, and the response is longer than native DNS, plus http headers (hpack and content-encoding would help), but I wouldn't expect it to spill to a second packet for either request or response. Encrypt/Decrypt is probably not a big deal compared to network latency. Assuming Google runs dns.google.com in the same locations it runs its port 53 services, then it's still one round trip either way. If you don't have the connection open, you still have to do a port 53 DNS lookup to find out where to connect (1 round trip to configured dns server), plus open a tcp connection (1 round trip), setup tls (1 round trip, assuming TLS false start), DNS request (1 round trip); so 4 round trips vs 1.
eridius 10y ago
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.
- microcolonel 10y ago
  The certificate has to match, so I don't think there would be a problem.
  - bluejekyll 10y ago
    Assuming none of your CAs have been compromised.
    - microcolonel 10y ago
      Why would it accept any old CA for a property of Google?
      - alexbecker 10y ago
        Browsers do this by default, unfortunately.
        conradev 10y ago
        Not Chrome, since 2011: https://www.imperialviolet.org/2011/05/04/pinning.html https://www.imperialviolet.org/2011/05/04/pinning.html
        tinix 10y ago
        Why do people keep linking to posts from 2011? That is wholly irrelevant... not only is key pinning not done that way now, we have a standard for this. https://www.rfc-editor.org/rfc/rfc7469.txt https://www.rfc-editor.org/rfc/rfc7469.txt And it's implemented by most browser vendors... just not Microsoft, of course. https://developer.microsoft.com/en-us/microsoft-edge/platform/status/publickeypinningextensionforhttp/ https://developer.microsoft.com/en-us/microsoft-edge/platfor...
api 10y ago
Why is this news? Any protocol can (usually trivially) be tunneled over http(s).
- nickpsecurity 10y ago
  I believe the significance is that it's being done, how, and by an Internet giant. There's an impact difference between random person on Github doing DNS over HTTPS and Google deploying it.
jcrites 10y ago
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/ https://www.google.com/transparencyreport/saferemail/
babangida 10y ago
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
- skissane 10y ago
  IP-over-DNS has already been done. https://news.ycombinator.com/item?id=7619259 https://news.ycombinator.com/item?id=7619259
  - jsmthrowaway 10y ago
    As has IP over ICMP echo requests, which I have actually found useful: http://code.gerade.org/hans/ http://code.gerade.org/hans/
    - sparky_ 10y ago
      Just curious, what use did you find for this?
      - obitoo 10y ago
        Its useful for reading your email on those 'free' wifi networks that require you to give your name, address mothers maiden name, and credit card before getting http access.
      - chris_wot 10y ago
        Tunnelling into networks and bypassing proxies, ancient IDSes and ineffective monitoring systems.
- kijin 10y ago
  DNS-over-HTTPS-over-Tor-over-DNS-over-ICMP is where it's at. None of the three-letter agencies can eavesdrop on your DNS queries now! It might even be faster than RFC 1149. https://www.ietf.org/rfc/rfc1149.txt https://www.ietf.org/rfc/rfc1149.txt
acidtrucks 10y ago
This is great, but google doesn't need to eavesdrop on us when they compel us to use their avenues for our every action.
- kyrra 10y ago
  It is optional to use. Just like it's optional to use Googles Dns servers at 8.8.8.8 and 8.8.4.4. The advantage with this is the extra security you get with HTTPS. Google DNS tends to be one of the fastest DNS servers you can use (just benchmark them against other options). The IPs are anycast, so you will likely be served by the Google data center closest to you. As for what they log, check it yourself: https://developers.google.com/speed/public-dns/privacy https://developers.google.com/speed/public-dns/privacy
- deathanatos 10y ago
  So, what DNS server do you use? I trust Google's DNS (I use the normal DNS ones, 8.8.8.8 and 8.8.4.4) a lot more than I trust Comcast's DNS servers. I'm sure there are others out there, of course, but 8.8.8.8 is good, reliable, and easily memorized.
  - ams6110 10y ago
    I use OpenDNS
  - sneak 10y ago
    Comcast is the one sending you the (unsigned, unencrypted) response packets from 8.8.8.8. You might as well use the Comcast ones.
    - Dylan16807 10y ago
      Politically it's a lot easier to stop Comcast from altering through-traffic DNS than it is to stop them from lying in DNS responses and calling it pro-user.
      - sashametro 10y ago
seanmcelroy 10y ago
DNS-over-QUIC would be a much more compelling technical proposal from Google as a standard
- sashametro 10y ago
  Note that although it is not documented, when you query the Google DNS-over-HTTPS service from Chrome, it will usually use QUIC. You can check this at chrome://net-internals/#quic, and will probably see something like this (look DNS/HTTPS/QUIC/UDP/IPv6!): dns.google.com:443 true QUIC_VERSION_34 [2607:f8b0:400d:c03::8a]:443 10544469510527000173 0 None 2 9 0 9 true An independent implementation of QUIC (are there any outside of browsers?) would probably work much the same, modulo any changes during the ongoing standardization of QUIC.
deleted 10y ago
[deleted]
davidu 10y ago
We did the same thing w/ JSON responses: https://www.openresolve.com/ 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).
- prewett 10y ago
  Why is this a bad idea? You can't just say "it's bad" with no justification. As a user, I can sure think of some countries with broken Internet access where this would come in handy.
  - davidu 10y ago
    I'll rephrase, it's way better accomplished with UDP without sacrificing security in the ways I list. Running DNS over HTTPS over TCP isn't needed. It doesn't solve a problem. Doing JSON DNS for OOB DNS checks is useful since most applications speak HTTP. :-)
- stevekemp 10y ago
  Yup I threw together a toy too: https://dns-api.org/ https://dns-api.org/ For debugging and diagnostics it is useful, for querying via a local resolver not so good.
- sashametro 10y ago
  Note that although it is not documented, when you query the Google DNS-over-HTTPS service from Chrome, it will usually use QUIC. You can check this at chrome://net-internals/#quic, and will probably see something like this (look DNS/HTTPS/QUIC/UDP/IPv6!): dns.google.com:443 true QUIC_VERSION_34 [2607:f8b0:400d:c03::8a]:443 10544469510527000173 0 None 2 9 0 9 true An independent implementation of QUIC (are there any outside of browsers?) would probably work much the same, modulo any changes during the ongoing standardization of QUIC.
jetsnoc 10y ago
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.
joshAg 10y ago
Why can't you just send DNS messages over an SSL/TLS socket? What's the value add for http and REST?
- LukeShu 10y ago
  I would assume being able to reuse the connection for multiple requests. Setting up the TLS connection is quite a bit more expensive than raw TCP, and especially UDP (most DNS happens over UDP). For longer connections, the additional overhead is minor, but for the extremely short DNS messages, I would imagine that a TLS connection per DNS request would be some pretty substantial overhead. Edit: The page mentions that this allows web applications to make their own DNS requests, possibly looking up things other than A/AAAA records that the browser normally requests.
  - eggnet 10y ago
    http and rest are not the only ways to reuse a socket. You could just write the packet to the TLS stream, raw, and keep the socket open.
    - LukeShu 10y ago
      Definitely. But then you need to define an envelope to mark where an individual message begins and ends (with UDP DNS, it's a single datagram; with TCP DNS, it's the entirety of the transmission). There are infinite ways to do this, and countless many already specified in various standards (many of which are already implemented in browsers, which is surely the the primary application Google had in mind). HTTP provides one such envelope.
      - pprx 10y ago
        > with TCP DNS, it's the entirety of the transmission DNS Messages have a two-byte length prefix when transmitted over TCP. Multiple envelopes can and often are sent over a single circuit.
  - joshAg 10y ago
thewisenerd 10y ago
> (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 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?).
rascul 10y ago
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.
- hrez 10y ago
  https://github.com/wrouesnel/dns-over-https-proxy https://github.com/wrouesnel/dns-over-https-proxy
  - rascul 10y ago
    I will still prefer the system resolver to support DNS over HTTPS natively, but this option could work.
therusskiy 10y ago
I've actually just written a blogpost about it. http://www.dmitry-ishkov.com/2016/09/dns-over-https.html 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
- garganzol 10y ago
  How fast does it work? What perceived latency does it have during usual web surfing?
- tssva 10y ago
  I would not use that implementation. It is broken in multiple ways. The most impactful to normal browsing is that it only supports a couple of RR types which doesn't include CNAMES.
  - tssva 10y ago
    I didn't mention it in my original comment because I thought the code didn't exist anymore but I found an old Time Machine backup disk with the code on it for an updated version of the referenced implementation. I have put it up on Github at https://github.com/tssva/dnshttps-proxy https://github.com/tssva/dnshttps-proxy. I need to throw up a README and give attribution. Will get to that later today. This version will support all RR types supported by the miekg/dns library which is the vast majority of them and any you are likely to come across in the wild. It also allows you to specify regular DNS resolvers which can be used in two ways. As fallback if connectivity to the DNS over HTTPS service fails or to always use to resolve specific domains. It also allows you to restrict access to the proxy to certain networks. The rest of the code should be IPv6 friendly but for some reason I implemented the access list in a manner that only supports specifying IPv4 networks. Guess I have something to work on. If no DNS resolvers are specified it attempts to use the Google Public DNS servers to resolve dns.google.com. If DNS resolvers are specified they are used to resolve dns.google.com. A flag to always use the Google Public DNS servers would be useful, so now I have 2 things to work on. As far as performance impact I have generally seen from 20 - 80msec of additional delay. Using a caching resolver behind the proxy would help mitigate this. As is the additional delay is pretty much unnoticeable when web browsing.
mytry 10y ago
很好很强大
zdw 10y ago
DNSCurve solved this years ago: http://dnscurve.org http://dnscurve.org , with implementation notes here: https://dnscurve.io https://dnscurve.io
- sneak 10y ago
  see also: Internet Mail 2000
- AliceWonderMisc 10y ago
  No it didn't. DNSCurve only solves recursive to authoritative. The request from a typical PC to recursive is still without encryption. And provides no mechanism for the PC to even know whether the result it receives is valid or not or if DNSCurve was even used by the recursive.
amluto 10y ago
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.
drizzentic 10y ago
Why do I need dns over http?
dtjohnnymonkey 10y ago
What's the purpose of explicitly specifying the "random_padding" parameter? Couldn't the client send any arbitrary unused query argument as padding?
- pshc 10y ago
  I can think of two non-technical reasons: as an explicit reminder to devs about side-channel attacks, and also to guarantee the key "random_padding" will never be used for anything else.
KaiserPro 10y ago
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.
- strictfp 10y ago
  "nice toy". Very succinct diss.
- viraptor 10y ago
  > 1) "secure DNS" is a solved problem No, not in practice. You can easily MitM DNS and nobody is verifying DNSSEC by default. On the current internet, secure DNS just doesn't exist.
  - KaiserPro 10y ago
    the mechanism is there, people are not choosing to use it. That is because security is hard. This doesn't mitigate MitM attacks, as upstream DNS records can still be spoofed WE go from a fast, decentralised, resilient and low overhead system, to a centralised chatty and fragile behemoth. It still doesn't give end to end encryption, its just a slow encrypted proxy.
    - viraptor 10y ago
      First people need to know about it to use it. Then it needs to actually work and not fail. https://ianix.com/pub/dnssec-outages.html https://ianix.com/pub/dnssec-outages.html
  - sashametro 10y ago
    Google Public DNS (8.8.8.8) verifies DNSSEC by default. So does Verisign Public DNS (64.6.64.6). Some measurements of DNSSEC validation show that as much as 15% of Internet domain lookups validate DNSSEC: http://stats.labs.apnic.net/dnssec/XA http://stats.labs.apnic.net/dnssec/XA. Approximately half of that is due to Google Public DNS validation (many sites use both Google Public DNS and other resolvers that do not validate, so do not actually validate DNSSEC overall). It is very true that less than 1% of DNS zones are signed with DNSSEC, so it is true that "secure DNS" doesn't practically exist, but this a serving side issue, not a lack of client validation.
byuu 10y ago
> 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.
- hannob 10y ago
  agl has explained in detail why they don't do that: https://www.imperialviolet.org/2015/01/17/notdane.html https://www.imperialviolet.org/2015/01/17/notdane.html tl;dr they can't, because DANE is undeployable in the current Internet.
  - byuu 10y ago
    Thank you for the link. I was previously only working from these links: https://www.ietf.org/mail-archive/web/dane/current/msg06996.html https://www.ietf.org/mail-archive/web/dane/current/msg06996.... https://bugzilla.mozilla.org/show_bug.cgi?id=1077323 https://bugzilla.mozilla.org/show_bug.cgi?id=1077323 https://bugs.chromium.org/p/chromium/issues/detail?id=50874 https://bugs.chromium.org/p/chromium/issues/detail?id=50874 > Instead, for this we have HPKP, which is a memory-based pinning solution using HTTP headers. The problem with HPKP is that you still need a certificate from a CA. And if you want wildcards or a >90 day length (regardless of what you think of their security, many people do -- the biggest sites on the internet have both), that means paying money. And it also still leaves you vulnerable to MitM rogue CA attacks. HPKP requires the user to connect the first time to get the pinned key. If an MitM has a fake certificate for your domain, they can send that to you on your first connection and fool you. DANE does not have this problem. Well, to be fair, DANE has it for the DNSSEC provider used. But that is one thing to trust, and said certificate can be bundled with the OS or browser. One thing to trust beats the current 2000+ intermediate CAs we have to trust. Further, DANE allows a way to verify self-signed certificates, allowing security to be free for everyone. We could see a lot more innovation than just certbot if Let's Encrypt weren't the only way to generate free certificates. For just one example, web servers could generate certificates from fresh installs; zero configuration requied. Like Caddy, but in nginx and Apache. Lastly, HPKP is riskier. You have to include a backup pin. But, what would happen if your had your own pinned, and StartSSL as the secondary? And you set HPKP for a year? And two weeks from now, Mozilla revokes StartCom entirely? Well, good luck with that one. Deleting HPKP is a royal pain for a regular user (about:permissions in Firefox, chrome://net-internals#hsts in Chrome) > We also have pre-loaded pinning in Chrome for larger or more obvious targets. Nice for Google and Facebook, not so nice for byuu.org =( > It's also worth noting that CryptoCat has committed pinning-suicide in Chrome at at the moment due to their CA having switched intermediates between renewals. Another good negative of HPKP. > But support for that was removed because it was a bunch of parsing code outside of the sandbox, wasn't really being used and it conflicted with two long-term plans for the health of the HTTPS ecosystem: eliminating 1024-bit RSA and Certificate Transparency. The conflicts are probably the most important reasons for not wanting to renew the experiment. RSA-1024 is bad, yes. Perhaps we should start asking how we can get DNSSEC on RSA-2048+. Having a commitment to implement it in Chrome, Firefox, Edge, Safari if we do would go a long way toward making that happen, I'm sure. Further, we can reject any RSA-1024 signed DNSSEC after that point, just like we reject weak crypto in browsers today. If they can't change DNSSEC to stronger crypto, how about they make an alternative? If Google introduces one that has stronger crypto, supports it in Chrome, and offers a free "DNSSEC+" hosting service, I'll definitely take immediate advantage of that. But the latter is the whole point of DANE -- self-signing. Certificate Transparency is a crutch due to the CA system having 2000+ intermediate CAs that can sign any domain name they want. With DANE, you don't need that anymore. DANE is about providing an alternative to the CA signing business. And there's nothing stopping users from serving up trusted CA-signed endpoint certificate signatures over DANE/TLSA records. That would obviously remain the only sensible way to do EV certificates. The way I see it, a DANE certificate would act like HTTP does now: you get the globe (or even the question mark circle), but your page actually loads over HTTPS, instead of sending you to Defcon-1 advisories that are all but impossible for the casual user to work around (and indeed, we don't want to train them to work around these warnings anyway.) There's no way this would be worse than plain-text HTTP. > You literally can't avoid it because the root zone transits through a 1024-bit key. Does this really matter for the root? There are root CAs with RSA-1024 still. ... At any rate, Google apparently feels DNSSEC+DANE is good enough for this web service API. So, honest question, why offer that if it's really such an unworkable system?
jbb555 10y ago
The "web" is becoming hack upon hack upon hack.
- Beltiras 10y ago
  Becoming? When has it not been?
SFJulie 10y ago
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?
- Dylan16807 10y ago
  > Even more leverage for a DDoS attack! HTTPS already exists and is slightly less vulnerable than normal DNS traffic. This opens no new DDoS opportunities. The rest of your post is irrelevant.
deleted 10y ago
[deleted]
chris_wot 10y ago
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.
dorianm 10y ago
Pretty cool, DNS as an API: - JSON: https://dns.google.com/resolve?name=doma.io https://dns.google.com/resolve?name=doma.io - Web interface: https://dns.google.com/query?name=doma.io&type=A&dnssec=true https://dns.google.com/query?name=doma.io&type=A&dnssec=true
tony-allan 10y ago
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 https://bitbucket.org/tony_allan/dnslib
mtyaka 10y ago
I find it amusing that they chose apple.com for the example.
youdontknowtho 10y ago
That's fantastic. Wondering why this hasn't happened before?
- ingenter 10y ago
  - It has happened, see the comment below (openresolve). - It doesn't solve the problem, unlike other existing solutions for encrypting DNS. - It adds unnecessarily high overhead.
  - youdontknowtho 10y ago
    Awesome. There maybe more than one problem. That's relative to the aforementioned problem. Cheers.
majewsky 10y ago
Is there a matrix of X-over-Y implementations? I would assume that we are converging to a fully filled matrix.
- OJFord 10y ago
  If not filled, probably full-rank such that all X-over-Y is possible, via-S-via-T!
pjf 10y ago
Shameless plug (again): https://github.com/pforemski/dingo https://github.com/pforemski/dingo
- poorman 10y ago
  Why have you disabled "Issues" on your repo?
  - pjf 10y ago
    For now I prefer to communicate through email
    - lox 10y ago
      I find it very annoying when people do this, it makes it very hard to gauge what sort of issues the software has and how the author responds to them.
      - pjf 10y ago
        If you find an important issue and document it properly, I will be happy to re-enable issues and add your input there. Github just doesnt provide enough moderation tools there, IMHO.
textmode 10y ago
"... greatly enhances privacy and security between a client and a recursive resolver." And that recursive resolver should be bound to the loopback. (It should not be a remote resolver controlled by a third party, such as GoogleDNS.) This is assuming for argument's sake that "privacy and security" were the true goals.
garaetjjte 10y ago
Why not DNS over TLS? https://tools.ietf.org/html/rfc7858 https://tools.ietf.org/html/rfc7858
aomix 10y ago
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.
znpy 10y ago
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)

321 points by mikecarlton 10y ago

deleted 10y ago

[deleted]

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.

JoshTriplett 10y ago
Probably not much, especially if you can maintain a persistent HTTP/2 connection to the DNS server.
Panino 10y ago
I use DNSCurve, which adds <1ms to latency. That's with X25519 and XSalsa20-Poly1305. Assuming a persistent connection, DNS-over-HTTPS might be similar with AES-NI or ChaCha20-Poly1305. The real speed issue is the number of round trips. DNSCurve is Zero-RTT, and assuming a persistent connection, DNS-over-HTTPS should probably be too at least once it's up and running. And then consider that lots of pages have megabytes of javascript fetched from multiple sources, big and often unoptimized images, expensive screen redraws, etc. Modern crypto doesn't affect performance at all. Hell, even PQCrypto-encrypted-DNS with 64KB public keys would be fast compared to the modern web. There's no reason to worry anymore about modern crypto affecting performance. It's just not an issue.
toast0 10y ago
If you had the TLS connection open to Google, there's a bit of overhead because the request is longer, and the response is longer than native DNS, plus http headers (hpack and content-encoding would help), but I wouldn't expect it to spill to a second packet for either request or response. Encrypt/Decrypt is probably not a big deal compared to network latency. Assuming Google runs dns.google.com in the same locations it runs its port 53 services, then it's still one round trip either way. If you don't have the connection open, you still have to do a port 53 DNS lookup to find out where to connect (1 round trip to configured dns server), plus open a tcp connection (1 round trip), setup tls (1 round trip, assuming TLS false start), DNS request (1 round trip); so 4 round trips vs 1.

eridius 10y ago

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.

microcolonel 10y ago
The certificate has to match, so I don't think there would be a problem.
- bluejekyll 10y ago
  Assuming none of your CAs have been compromised.
  - microcolonel 10y ago
    Why would it accept any old CA for a property of Google?
    - alexbecker 10y ago
      Browsers do this by default, unfortunately.
      - conradev 10y ago
        Not Chrome, since 2011: https://www.imperialviolet.org/2011/05/04/pinning.html https://www.imperialviolet.org/2011/05/04/pinning.html
        tinix 10y ago
        Why do people keep linking to posts from 2011? That is wholly irrelevant... not only is key pinning not done that way now, we have a standard for this. https://www.rfc-editor.org/rfc/rfc7469.txt https://www.rfc-editor.org/rfc/rfc7469.txt And it's implemented by most browser vendors... just not Microsoft, of course. https://developer.microsoft.com/en-us/microsoft-edge/platform/status/publickeypinningextensionforhttp/ https://developer.microsoft.com/en-us/microsoft-edge/platfor...

api 10y ago

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

nickpsecurity 10y ago
I believe the significance is that it's being done, how, and by an Internet giant. There's an impact difference between random person on Github doing DNS over HTTPS and Google deploying it.

jcrites 10y ago

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/ https://www.google.com/transparencyreport/saferemail/

babangida 10y ago

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

skissane 10y ago
IP-over-DNS has already been done. https://news.ycombinator.com/item?id=7619259 https://news.ycombinator.com/item?id=7619259
- jsmthrowaway 10y ago
  As has IP over ICMP echo requests, which I have actually found useful: http://code.gerade.org/hans/ http://code.gerade.org/hans/
  - sparky_ 10y ago
    Just curious, what use did you find for this?
    - obitoo 10y ago
      Its useful for reading your email on those 'free' wifi networks that require you to give your name, address mothers maiden name, and credit card before getting http access.
    - chris_wot 10y ago
      Tunnelling into networks and bypassing proxies, ancient IDSes and ineffective monitoring systems.
kijin 10y ago
DNS-over-HTTPS-over-Tor-over-DNS-over-ICMP is where it's at. None of the three-letter agencies can eavesdrop on your DNS queries now! It might even be faster than RFC 1149. https://www.ietf.org/rfc/rfc1149.txt https://www.ietf.org/rfc/rfc1149.txt

acidtrucks 10y ago

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

kyrra 10y ago
It is optional to use. Just like it's optional to use Googles Dns servers at 8.8.8.8 and 8.8.4.4. The advantage with this is the extra security you get with HTTPS. Google DNS tends to be one of the fastest DNS servers you can use (just benchmark them against other options). The IPs are anycast, so you will likely be served by the Google data center closest to you. As for what they log, check it yourself: https://developers.google.com/speed/public-dns/privacy https://developers.google.com/speed/public-dns/privacy
deathanatos 10y ago
So, what DNS server do you use? I trust Google's DNS (I use the normal DNS ones, 8.8.8.8 and 8.8.4.4) a lot more than I trust Comcast's DNS servers. I'm sure there are others out there, of course, but 8.8.8.8 is good, reliable, and easily memorized.
- ams6110 10y ago
  I use OpenDNS
- sneak 10y ago
  Comcast is the one sending you the (unsigned, unencrypted) response packets from 8.8.8.8. You might as well use the Comcast ones.
  - Dylan16807 10y ago
    Politically it's a lot easier to stop Comcast from altering through-traffic DNS than it is to stop them from lying in DNS responses and calling it pro-user.
    - sashametro 10y ago

seanmcelroy 10y ago

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

sashametro 10y ago
Note that although it is not documented, when you query the Google DNS-over-HTTPS service from Chrome, it will usually use QUIC. You can check this at chrome://net-internals/#quic, and will probably see something like this (look DNS/HTTPS/QUIC/UDP/IPv6!): dns.google.com:443 true QUIC_VERSION_34 [2607:f8b0:400d:c03::8a]:443 10544469510527000173 0 None 2 9 0 9 true An independent implementation of QUIC (are there any outside of browsers?) would probably work much the same, modulo any changes during the ongoing standardization of QUIC.

deleted 10y ago

[deleted]

davidu 10y ago

We did the same thing w/ JSON responses: https://www.openresolve.com/ 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).

prewett 10y ago
Why is this a bad idea? You can't just say "it's bad" with no justification. As a user, I can sure think of some countries with broken Internet access where this would come in handy.
- davidu 10y ago
  I'll rephrase, it's way better accomplished with UDP without sacrificing security in the ways I list. Running DNS over HTTPS over TCP isn't needed. It doesn't solve a problem. Doing JSON DNS for OOB DNS checks is useful since most applications speak HTTP. :-)
stevekemp 10y ago
Yup I threw together a toy too: https://dns-api.org/ https://dns-api.org/ For debugging and diagnostics it is useful, for querying via a local resolver not so good.
sashametro 10y ago
Note that although it is not documented, when you query the Google DNS-over-HTTPS service from Chrome, it will usually use QUIC. You can check this at chrome://net-internals/#quic, and will probably see something like this (look DNS/HTTPS/QUIC/UDP/IPv6!): dns.google.com:443 true QUIC_VERSION_34 [2607:f8b0:400d:c03::8a]:443 10544469510527000173 0 None 2 9 0 9 true An independent implementation of QUIC (are there any outside of browsers?) would probably work much the same, modulo any changes during the ongoing standardization of QUIC.

jetsnoc 10y ago

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.

joshAg 10y ago

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

LukeShu 10y ago
I would assume being able to reuse the connection for multiple requests. Setting up the TLS connection is quite a bit more expensive than raw TCP, and especially UDP (most DNS happens over UDP). For longer connections, the additional overhead is minor, but for the extremely short DNS messages, I would imagine that a TLS connection per DNS request would be some pretty substantial overhead. Edit: The page mentions that this allows web applications to make their own DNS requests, possibly looking up things other than A/AAAA records that the browser normally requests.
- eggnet 10y ago
  http and rest are not the only ways to reuse a socket. You could just write the packet to the TLS stream, raw, and keep the socket open.
  - LukeShu 10y ago
    Definitely. But then you need to define an envelope to mark where an individual message begins and ends (with UDP DNS, it's a single datagram; with TCP DNS, it's the entirety of the transmission). There are infinite ways to do this, and countless many already specified in various standards (many of which are already implemented in browsers, which is surely the the primary application Google had in mind). HTTP provides one such envelope.
    - pprx 10y ago
      > with TCP DNS, it's the entirety of the transmission DNS Messages have a two-byte length prefix when transmitted over TCP. Multiple envelopes can and often are sent over a single circuit.
- joshAg 10y ago

thewisenerd 10y ago

> (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 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?).

rascul 10y ago

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.

hrez 10y ago
https://github.com/wrouesnel/dns-over-https-proxy https://github.com/wrouesnel/dns-over-https-proxy
- rascul 10y ago
  I will still prefer the system resolver to support DNS over HTTPS natively, but this option could work.

therusskiy 10y ago

I've actually just written a blogpost about it. http://www.dmitry-ishkov.com/2016/09/dns-over-https.html 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

garganzol 10y ago
How fast does it work? What perceived latency does it have during usual web surfing?
tssva 10y ago
I would not use that implementation. It is broken in multiple ways. The most impactful to normal browsing is that it only supports a couple of RR types which doesn't include CNAMES.
- tssva 10y ago
  I didn't mention it in my original comment because I thought the code didn't exist anymore but I found an old Time Machine backup disk with the code on it for an updated version of the referenced implementation. I have put it up on Github at https://github.com/tssva/dnshttps-proxy https://github.com/tssva/dnshttps-proxy. I need to throw up a README and give attribution. Will get to that later today. This version will support all RR types supported by the miekg/dns library which is the vast majority of them and any you are likely to come across in the wild. It also allows you to specify regular DNS resolvers which can be used in two ways. As fallback if connectivity to the DNS over HTTPS service fails or to always use to resolve specific domains. It also allows you to restrict access to the proxy to certain networks. The rest of the code should be IPv6 friendly but for some reason I implemented the access list in a manner that only supports specifying IPv4 networks. Guess I have something to work on. If no DNS resolvers are specified it attempts to use the Google Public DNS servers to resolve dns.google.com. If DNS resolvers are specified they are used to resolve dns.google.com. A flag to always use the Google Public DNS servers would be useful, so now I have 2 things to work on. As far as performance impact I have generally seen from 20 - 80msec of additional delay. Using a caching resolver behind the proxy would help mitigate this. As is the additional delay is pretty much unnoticeable when web browsing.

mytry 10y ago

很好很强大

zdw 10y ago

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

sneak 10y ago
see also: Internet Mail 2000
AliceWonderMisc 10y ago
No it didn't. DNSCurve only solves recursive to authoritative. The request from a typical PC to recursive is still without encryption. And provides no mechanism for the PC to even know whether the result it receives is valid or not or if DNSCurve was even used by the recursive.

amluto 10y ago

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.

drizzentic 10y ago

Why do I need dns over http?

dtjohnnymonkey 10y ago

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

pshc 10y ago
I can think of two non-technical reasons: as an explicit reminder to devs about side-channel attacks, and also to guarantee the key "random_padding" will never be used for anything else.

KaiserPro 10y ago

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.

strictfp 10y ago
"nice toy". Very succinct diss.
viraptor 10y ago
> 1) "secure DNS" is a solved problem No, not in practice. You can easily MitM DNS and nobody is verifying DNSSEC by default. On the current internet, secure DNS just doesn't exist.
- KaiserPro 10y ago
  the mechanism is there, people are not choosing to use it. That is because security is hard. This doesn't mitigate MitM attacks, as upstream DNS records can still be spoofed WE go from a fast, decentralised, resilient and low overhead system, to a centralised chatty and fragile behemoth. It still doesn't give end to end encryption, its just a slow encrypted proxy.
  - viraptor 10y ago
    First people need to know about it to use it. Then it needs to actually work and not fail. https://ianix.com/pub/dnssec-outages.html https://ianix.com/pub/dnssec-outages.html
- sashametro 10y ago
  Google Public DNS (8.8.8.8) verifies DNSSEC by default. So does Verisign Public DNS (64.6.64.6). Some measurements of DNSSEC validation show that as much as 15% of Internet domain lookups validate DNSSEC: http://stats.labs.apnic.net/dnssec/XA http://stats.labs.apnic.net/dnssec/XA. Approximately half of that is due to Google Public DNS validation (many sites use both Google Public DNS and other resolvers that do not validate, so do not actually validate DNSSEC overall). It is very true that less than 1% of DNS zones are signed with DNSSEC, so it is true that "secure DNS" doesn't practically exist, but this a serving side issue, not a lack of client validation.

byuu 10y ago

> 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.

hannob 10y ago
agl has explained in detail why they don't do that: https://www.imperialviolet.org/2015/01/17/notdane.html https://www.imperialviolet.org/2015/01/17/notdane.html tl;dr they can't, because DANE is undeployable in the current Internet.
- byuu 10y ago
  Thank you for the link. I was previously only working from these links: https://www.ietf.org/mail-archive/web/dane/current/msg06996.html https://www.ietf.org/mail-archive/web/dane/current/msg06996.... https://bugzilla.mozilla.org/show_bug.cgi?id=1077323 https://bugzilla.mozilla.org/show_bug.cgi?id=1077323 https://bugs.chromium.org/p/chromium/issues/detail?id=50874 https://bugs.chromium.org/p/chromium/issues/detail?id=50874 > Instead, for this we have HPKP, which is a memory-based pinning solution using HTTP headers. The problem with HPKP is that you still need a certificate from a CA. And if you want wildcards or a >90 day length (regardless of what you think of their security, many people do -- the biggest sites on the internet have both), that means paying money. And it also still leaves you vulnerable to MitM rogue CA attacks. HPKP requires the user to connect the first time to get the pinned key. If an MitM has a fake certificate for your domain, they can send that to you on your first connection and fool you. DANE does not have this problem. Well, to be fair, DANE has it for the DNSSEC provider used. But that is one thing to trust, and said certificate can be bundled with the OS or browser. One thing to trust beats the current 2000+ intermediate CAs we have to trust. Further, DANE allows a way to verify self-signed certificates, allowing security to be free for everyone. We could see a lot more innovation than just certbot if Let's Encrypt weren't the only way to generate free certificates. For just one example, web servers could generate certificates from fresh installs; zero configuration requied. Like Caddy, but in nginx and Apache. Lastly, HPKP is riskier. You have to include a backup pin. But, what would happen if your had your own pinned, and StartSSL as the secondary? And you set HPKP for a year? And two weeks from now, Mozilla revokes StartCom entirely? Well, good luck with that one. Deleting HPKP is a royal pain for a regular user (about:permissions in Firefox, chrome://net-internals#hsts in Chrome) > We also have pre-loaded pinning in Chrome for larger or more obvious targets. Nice for Google and Facebook, not so nice for byuu.org =( > It's also worth noting that CryptoCat has committed pinning-suicide in Chrome at at the moment due to their CA having switched intermediates between renewals. Another good negative of HPKP. > But support for that was removed because it was a bunch of parsing code outside of the sandbox, wasn't really being used and it conflicted with two long-term plans for the health of the HTTPS ecosystem: eliminating 1024-bit RSA and Certificate Transparency. The conflicts are probably the most important reasons for not wanting to renew the experiment. RSA-1024 is bad, yes. Perhaps we should start asking how we can get DNSSEC on RSA-2048+. Having a commitment to implement it in Chrome, Firefox, Edge, Safari if we do would go a long way toward making that happen, I'm sure. Further, we can reject any RSA-1024 signed DNSSEC after that point, just like we reject weak crypto in browsers today. If they can't change DNSSEC to stronger crypto, how about they make an alternative? If Google introduces one that has stronger crypto, supports it in Chrome, and offers a free "DNSSEC+" hosting service, I'll definitely take immediate advantage of that. But the latter is the whole point of DANE -- self-signing. Certificate Transparency is a crutch due to the CA system having 2000+ intermediate CAs that can sign any domain name they want. With DANE, you don't need that anymore. DANE is about providing an alternative to the CA signing business. And there's nothing stopping users from serving up trusted CA-signed endpoint certificate signatures over DANE/TLSA records. That would obviously remain the only sensible way to do EV certificates. The way I see it, a DANE certificate would act like HTTP does now: you get the globe (or even the question mark circle), but your page actually loads over HTTPS, instead of sending you to Defcon-1 advisories that are all but impossible for the casual user to work around (and indeed, we don't want to train them to work around these warnings anyway.) There's no way this would be worse than plain-text HTTP. > You literally can't avoid it because the root zone transits through a 1024-bit key. Does this really matter for the root? There are root CAs with RSA-1024 still. ... At any rate, Google apparently feels DNSSEC+DANE is good enough for this web service API. So, honest question, why offer that if it's really such an unworkable system?

jbb555 10y ago

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

Beltiras 10y ago
Becoming? When has it not been?

SFJulie 10y ago

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?

Dylan16807 10y ago
> Even more leverage for a DDoS attack! HTTPS already exists and is slightly less vulnerable than normal DNS traffic. This opens no new DDoS opportunities. The rest of your post is irrelevant.

deleted 10y ago

[deleted]

chris_wot 10y ago

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.

dorianm 10y ago

Pretty cool, DNS as an API: - JSON: https://dns.google.com/resolve?name=doma.io https://dns.google.com/resolve?name=doma.io - Web interface: https://dns.google.com/query?name=doma.io&type=A&dnssec=true https://dns.google.com/query?name=doma.io&type=A&dnssec=true

tony-allan 10y ago

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 https://bitbucket.org/tony_allan/dnslib

mtyaka 10y ago

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

youdontknowtho 10y ago

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

ingenter 10y ago
- It has happened, see the comment below (openresolve). - It doesn't solve the problem, unlike other existing solutions for encrypting DNS. - It adds unnecessarily high overhead.
- youdontknowtho 10y ago
  Awesome. There maybe more than one problem. That's relative to the aforementioned problem. Cheers.

majewsky 10y ago

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

OJFord 10y ago
If not filled, probably full-rank such that all X-over-Y is possible, via-S-via-T!

pjf 10y ago

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

poorman 10y ago
Why have you disabled "Issues" on your repo?
- pjf 10y ago
  For now I prefer to communicate through email
  - lox 10y ago
    I find it very annoying when people do this, it makes it very hard to gauge what sort of issues the software has and how the author responds to them.
    - pjf 10y ago
      If you find an important issue and document it properly, I will be happy to re-enable issues and add your input there. Github just doesnt provide enough moderation tools there, IMHO.

textmode 10y ago

"... greatly enhances privacy and security between a client and a recursive resolver." And that recursive resolver should be bound to the loopback. (It should not be a remote resolver controlled by a third party, such as GoogleDNS.) This is assuming for argument's sake that "privacy and security" were the true goals.

garaetjjte 10y ago

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

aomix 10y ago

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.

znpy 10y ago

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)