back to article IETF plants privacy test inside DNS

The Internet Engineering Task Force's (IETF's) years-long effort to protect Internet users has taken a small step forward, with one option for better Domain Name System (DNS) privacy reaching the test stage. "Stubby", created by the getdns project team, lets users test encrypted DNS queries. The idea isn't to flick the switch …

  1. John Smith 19 Gold badge
    Go

    “pervasive monitoring is an attack”

    Because it is?

    This looks like a small first step to making that attack more difficult.

    Hopefully it's something simple enough that people will be be comfortable about rolling into their stacks sooner rather than later.

    1. Drew 11

      Re: “pervasive monitoring is an attack”

      Later rather than sooner if Google/Mozilla foot-dragging regarding DANE support in browsers is anything to go by.

    2. MonkeyJuice

      Re: “pervasive monitoring is an attack”

      It's probably simple enough but how will uk ISP's rewrite DNS requests to blacklisted sites? Solution: drop such packets. Good idea but DOA in a land in which IP enforcement outweigh privacy concerns.

  2. Warm Braw Silver badge

    I'm confused

    Even after looking through the slides from the IETF talk.

    DNS is just a directory service, designed (largely) to look up network addresses. Even if you completely secure the directory lookup, you reveal the network address (and hence the domain name you looked up) immediately you initiate any traffic based on the lookup. Admittedly, you reveal this initially only to your ISP, but your ISP is likely to be the principal culprit in pervasive monitoring.

    Now, you may be able to reduce the amount of information that's leaked to intermediate and authoritative nameservers by concealing the origin of the lookup, but you can't do that if you use TLS end-to-end and in any case, that's probably the least of your problems.

    What bit did I miss?

    1. Dazed and Confused

      Re: I'm confused

      Although DNS provides a mapping from a domain name to an IP address and you then contact that IP address, the IP address in itself doe not identify the domain name or website you are contacting. Lots of website run on shared servers so a log of IP addresses accessed doesn't reveal a great deal about the sites you're visiting.

      When you posted here the domain name forums.theregister.co.uk returned an IP address, but checking that IP address just reveals that currently El'Reg seems to be hosted by Cloudflare.

      If you are using HTTP then of course the website you want is going to be in the packets you send to that address, so the ISP / BigBrother / monitoring service can see them then. If you are using HTTPS then the negotiation over the certificate is in plain text, but even this doesn't need to reveal the name of the site you are visiting as one certificate can cover multiple websites.

      1. Warm Braw Silver badge

        Re: I'm confused

        If you are using HTTPS ... this doesn't need to reveal the name of the site you are visiting

        Unless the host uses Server Name Indication, I gather. A blog site might well use a wildcard SSL certificate to cover its subdomains, multi-tenanted HTTPS is likely to use SNI with unrelated domain names.

        As it's apparently sent in clear text at an early stage in the handshake, I suspect there may be a MITM attack that would cause the browser to emit an SNI even if one were not required by the server.

        1. Warm Braw Silver badge

          Re: I'm confused

          there may be a MITM attack

          Actually, it seems you don't need one as the recommendation in RFC 3546 seems to be that the browser should include the SNI where it can and it's up to the server to decide if it's relevant.

        2. Arthur the cat Silver badge

          Re: I'm confused

          Unless the host uses Server Name Indication, I gather. A blog site might well use a wildcard SSL certificate to cover its subdomains, multi-tenanted HTTPS is likely to use SNI with unrelated domain names.

          As it's apparently sent in clear text at an early stage in the handshake, I suspect there may be a MITM attack that would cause the browser to emit an SNI even if one were not required by the server.

          If the web server is correctly implemented (nginx does this AFAIR) the initial connection can contain one SNI visible in plain text, but after TLS is negotiated the browser has to start the request all over again and can give a different, this time TLS protected, SNI.

          Thus the visible SNI could be completely-innocuous.com but the secret one could be trump-porn.org. Whether any browser actually supports this split site working is left as an exercise to the readercoder.

      2. Doctor Syntax Silver badge
        FAIL

        Re: I'm confused

        "When you posted here the domain name forums.theregister.co.uk returned an IP address...If you are using HTTPS"

        If.

        el Reg isn't a good example.

        1. joed

          Re: I'm confused

          "el Reg isn't a good example." Speaking of which. When the team gets around this task please make sure to pin that cert so I can start posting - again - from work (no intentions on linking my generic username to credentials used by ZS, make the watchmen work harder for their pay;).

    2. Graham Cobb Silver badge

      Re: I'm confused

      I think you missed three things:

      1) IP address to name reverse lookups are not unique. I can look up many different names to get the same IP address. This is particularly relevant when reading blogs (thousands may be hosted on a single server, including many bland ones and some radical ones) and can also be relevant for CDNs.

      2) You may be using a VPN, a proxy server or even Tor to protect your network connection but many browsers still look up the name first (for example, that is the default configuration in the version of Firefox I use).

      3) A matter of principle: name lookup and network connection are separate issues and both need to be protected (otherwise your question could just be raised the other way around).

    3. sitta_europea Silver badge

      Re: I'm confused

      What did you miss? Probably that the whole idea is a non-starter.

      The DNS protocols are designed to be very lightweight. Most traffic is single UDP packets. There are good reasons for that. If you try to drop security/privacy into that you multiply the traffic, not to mention latencies, by more than an order of magnitude and people who know about this stuff have serious reservations about that.

      This is not new. See for example https://www.quora.com/Why-does-DNS-use-UDP

      What do I care if people know where my browser has been? Most of the time it does it on its own without my input anyway.

      1. Anonymous Coward
        Anonymous Coward

        @sitta_europea

        Read the article again. It is encrypting not the DNS lookups from your browser, but the lookups from a stub resolver like the one your wireless router likely has to a full fledged DNS server like the one your ISP likely has. Since your stub resolver caches things you've looked up recently, the traffic to your ISP's resolver is a lot smaller and it can absorb the additional traffic from using encryption. DNS servers are hardly bandwidth bound (barring amplification attacks)

        Since the UDP packet size for DNS is limited, due to all the additional stuff getting crammed into DNS these days it is more and more common to use TCP anyway.

    4. Anonymous Coward
      Anonymous Coward

      Re: I'm confused

      > Admittedly, you reveal this initially only to your ISP, but your ISP is likely to be the principal culprit in pervasive monitoring.

      True; but you don't *have* to use your ISP's DNS services.

      Now whether you'd trust Google or OpenDNS with their handling of your query history is another thing again. So this requires some privacy-conscious DNS services to spring up - which you either pay to use, or somehow trust their public-spirited efforts.

      If you're going to go that route, arguably you could just use something like IPSEC or (D)TLS to protect that traffic. But in the real world, people are behind NAT and on dynamic IP addresses, so maybe it makes sense to do this as a DNS extension.

  3. Aodhhan

    DNS doesn't use...

    This is really simple, don't make it difficult.

    DNS doesn't use HTTPS (port 443) or your VPN. It runs over a separate unencrypted channel.

    DNS typically uses a high number UDP port to send and UDP port 53 to receive. However, it can also use TCP under certain circumstances.

    If someone is sniffing, they can see all the information in the packet... which includes who is asking, where it's asking and what it's asking about in plain text.

  4. Alistair
    Windows

    stubby.

    Brings to mind old fashioned beer bottles up here at least, likely down south of the (soon to be built) wall as well.

    DNS resolver logs make interesting reading for TLAs. NAT is one thing, but is only partially sufficient to mask the paths your browser travels. TLAs have access to your ISP's logs, and assuming that DNS over UDP is cleartext, they can pin bows on the IP connections.

    Over here in the 'western' world it means very little to most of us that the TLA's and such can put all this together. At least at this moment. There are places where this sort of collation of information is already a threat to one's continued ability to walk about town and enjoy sunshine. At some point, cat videos will become the equivalent of porn.

    Nice to see some work being done on these fronts. I'm sure they will put down the latencies and efficiencies so that those who need to can make the call if its 'worth doing'. Because, there will always be that moment, for someone, when it will be worth doing.

  5. MNGrrrl
    Megaphone

    Corrections

    To clear up a few misconceptions posted in the comments (not the article):

    - DNS lookups are not encrypted -- even if you are using a VPN, they typically are sent in the clear over the 'default' routing rule. Thus, what you're looking for from within the VPN is leaked over clear channel.

    - This is NOT a protocol to prevent DNS poison pill attacks, or man in the middle attacks. You must still trust your DNS resolver (typically your ISP). This is designed to protect your queries between you and your ISP's DNS server *only*. As you may well know, ISPs often sell this data, and are often required by various local laws to store it. This protocol will not stop that.

    - This protocol is NOT for establishing chains of trust between DNS providers. That is handled elsewhere (DNSSEC).

    - This protocol does NOT protect against traffic analysis, nor does it provide any encryption beyond the IP->name lookup. Which means, by itself, it provides little, if any, protection against "pervasive surveillance". Anyone who can intercept your DNS packets can probably also intercept your plain-text HTTP lookups, screw with SSL connections, and more.

  6. batfastad

    dnscrypt?

    Is this not the same as dnscrypt?

    https://dnscrypt.org

    https://github.com/jedisct1/dnscrypt-proxy

    Anyway ICRs are harmless, the government said so.

  7. Alistair
    Black Helicopters

    @MNGrrl -

    "- DNS lookups are not encrypted -- even if you are using a VPN, they typically are sent in the clear over the 'default' routing rule. Thus, what you're looking for from within the VPN is leaked over clear channel."

    This somewhat depends on *what sort* of VPN you're using and how it is configured. This functionality is how some of the 'netflix/hulu' vpn's actually function.

    In quite a few cases, the 'open internet vpn' providers *do not* reroute the DNS traffic through the tunnel, but override the default resolver. The queries may still go out over the untunnelled path, but they end up going to some other dns server, the overall affect of this depends on where the pervasive monitoring is being done.

    What this *can* do for you is handle local resolver requests, wrapping them in TLS and sending them to one of 4 "privacy servers". What this can do for you if your skillset were sufficient is provide you with a local DNS stub on your local network, wrapping all local queries similarly. On the local wire, your queries would still be readable. But between the stub and the 'privacy server' they would indeed be encrypted.

    Once more, this depends on overall configuration of the systems on the network and what one wishes to accomplish.

    Great Gaping Hole at the moment is that there are only 4 of these 'privacy' servers. Far far far too easy to compromise that.. even without handling the servers themselves - one could watch both ends of their connections - TLS in -> UDP out to the root servers perhaps? I'm sure that someone could come up with correlative data. In any case, it is a *very* small step forward of sorts. And forward we should be going.

    It all depends on how much tinfoil one wishes to wrap around one's hat.

    (since we don't have a tinfoil hat icon)

  8. aarond10

    I wrote something similar using Google's dns-over-https

    https://github.com/aaron10/https_dns_proxy

    Can install in seconds on openwrt/lede with "opkg install https_dns_proxy" and a few tweaks to /etc/config/dhcp. Does a lookup over regular DNS to get the IP of dns.google.com then routes all requests through a set of http/2 pipelined connections to Google. Still need something like dnsmasq as it isn't a caching proxy.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2022