5 ms·

Just thinking for a few seconds, I can think of a number of ways to not repeatedly spam DNS servers while still accomplishing the objective. If you were to send

Just thinking for a few seconds, I can think of a number of ways to not repeatedly spam DNS servers while still accomplishing the objective. If you were to send 3 random queries to Google every time you opened your browser, you would quickly get hellbanned behind a recaptcha. Not saying that we should embark on some quest for retribution against Google. It's just sad.

why_only_15 6y ago
I bet they just made this as a throwaway and it worked fine when it was 1% of traffic and maybe they just haven't looked at it again. I bet if the APNIC people harassed them they would change it.
thayne 6y ago
Google could, you know, use their own DNS servers for this...
- Slartie 6y ago
  No, they couldn't. The whole purpose of these probe requests is to assess whether the DNS server used by a particular client is acting normally (responding with NXDOMAIN if a domain does not exist), so these must bde sent to the DNS server of the client, which effectively means that unless this DNS server performs the hijacking that is to be detected, they will inevitably end up on a root DNS server, because no server in the hierarchy will know those domains. Forcing these probe requests onto Google's DNS would completely defy their purpose in the first place.
  - majewsky 6y ago
    Instead of http://asdoguhwrouyh http://asdoguhwrouyh, they could probe something like http://asdoguhwrouyh.google http://asdoguhwrouyh.google or anything else in a zone owned by them, so the uncachable traffic would hit only their authoritative name servers and not the root servers.
    - warp 6y ago
      But then a lying DNS server could easily identify those, and NOT lie about http://*.google http://*.google -- the reason these requests are entirely random domain names is so they're not easily recognized as probes.
      - xnyanta 6y ago
        Except that the queries are already totally identifiable as probes in their current form, which is demonstrated in the article.
    - JdeBP 6y ago
      ... only when the delegation for google. is cached.
  - thayne 6y ago
    ah, good point.
- corty 6y ago
  They could just use DNSSEC...
  - johncolanduoni 6y ago
    DNSSEC has to be supported by your ISP’s DNS server, which they won’t if they’re trying to intercept your queries.
    - tptacek 6y ago
      They're suggesting you install your own local DNS server --- nothing prevents you from doing that, and just talking straight to the roots instead of through your ISP's DNS server. The real problem is not your ISP, but rather the fact that the most important sites on the Internet have rejected DNSSEC and aren't signed. DNSSEC can't do anything for you with hostnames in zones that haven't been signed by their operators, and, to a first approximation, every zone managed by a serious security team (with a tiny number of exceptions like Cloud Flare, who sells DNSSEC services) has declined to do so.
      - johncolanduoni 6y ago
        Do any ISPs intercept upstream requests when running your own recursive resolver? If not, DNSSEC isn’t relevant here and you should be fine just fine with “only” running your own without requiring DNSSEC.
        tptacek 6y ago
        They could. I doubt they do.
- amalcon 6y ago
  It wouldn't usually help to use 8.8.8.8, but they probably could use their own authoritative servers instead of the root servers. Look up <random chars>.dnstest.google.com or <random chars>.dev or something. The problem with this is, of course, that a malicious resolver could detect this and NXDOMAIN those queries, while passing others through. I don't see what the incentive would be for ISPs to do that, but ISPs are weird.
  - londons_explore 6y ago
    > that a malicious resolver could detect this I assume the reason for changing from a 10 char random string to a 7-14 char random string was exactly because some ISP's were detecting it...
    - jml7c5 6y ago
      Unfortunately the commit message doesn't explain why the change was made: https://chromium.googlesource.com/experimental/chromium/src/+/badf5acbd419d31eaddeb4480c5df1d57111755e https://chromium.googlesource.com/experimental/chromium/src/...
      - londons_explore 6y ago
        @agl?? You here? Do you remember the motivation for this change?

why_only_15 6y ago

I bet they just made this as a throwaway and it worked fine when it was 1% of traffic and maybe they just haven't looked at it again. I bet if the APNIC people harassed them they would change it.

thayne 6y ago

Google could, you know, use their own DNS servers for this...

Slartie 6y ago
No, they couldn't. The whole purpose of these probe requests is to assess whether the DNS server used by a particular client is acting normally (responding with NXDOMAIN if a domain does not exist), so these must bde sent to the DNS server of the client, which effectively means that unless this DNS server performs the hijacking that is to be detected, they will inevitably end up on a root DNS server, because no server in the hierarchy will know those domains. Forcing these probe requests onto Google's DNS would completely defy their purpose in the first place.
- majewsky 6y ago
  Instead of http://asdoguhwrouyh http://asdoguhwrouyh, they could probe something like http://asdoguhwrouyh.google http://asdoguhwrouyh.google or anything else in a zone owned by them, so the uncachable traffic would hit only their authoritative name servers and not the root servers.
  - warp 6y ago
    But then a lying DNS server could easily identify those, and NOT lie about http://*.google http://*.google -- the reason these requests are entirely random domain names is so they're not easily recognized as probes.
    - xnyanta 6y ago
      Except that the queries are already totally identifiable as probes in their current form, which is demonstrated in the article.
  - JdeBP 6y ago
    ... only when the delegation for google. is cached.
- thayne 6y ago
  ah, good point.
corty 6y ago
They could just use DNSSEC...
- johncolanduoni 6y ago
  DNSSEC has to be supported by your ISP’s DNS server, which they won’t if they’re trying to intercept your queries.
  - tptacek 6y ago
    They're suggesting you install your own local DNS server --- nothing prevents you from doing that, and just talking straight to the roots instead of through your ISP's DNS server. The real problem is not your ISP, but rather the fact that the most important sites on the Internet have rejected DNSSEC and aren't signed. DNSSEC can't do anything for you with hostnames in zones that haven't been signed by their operators, and, to a first approximation, every zone managed by a serious security team (with a tiny number of exceptions like Cloud Flare, who sells DNSSEC services) has declined to do so.
    - johncolanduoni 6y ago
      Do any ISPs intercept upstream requests when running your own recursive resolver? If not, DNSSEC isn’t relevant here and you should be fine just fine with “only” running your own without requiring DNSSEC.
      - tptacek 6y ago
        They could. I doubt they do.
amalcon 6y ago
It wouldn't usually help to use 8.8.8.8, but they probably could use their own authoritative servers instead of the root servers. Look up <random chars>.dnstest.google.com or <random chars>.dev or something. The problem with this is, of course, that a malicious resolver could detect this and NXDOMAIN those queries, while passing others through. I don't see what the incentive would be for ISPs to do that, but ISPs are weird.
- londons_explore 6y ago
  > that a malicious resolver could detect this I assume the reason for changing from a 10 char random string to a 7-14 char random string was exactly because some ISP's were detecting it...
  - jml7c5 6y ago
    Unfortunately the commit message doesn't explain why the change was made: https://chromium.googlesource.com/experimental/chromium/src/+/badf5acbd419d31eaddeb4480c5df1d57111755e https://chromium.googlesource.com/experimental/chromium/src/...
    - londons_explore 6y ago
      @agl?? You here? Do you remember the motivation for this change?