Most active commenters

    ←back to thread

    1895 points _l4jh | 14 comments | | HN request time: 0.949s | source | bottom
    1. infinisil ◴[] No.16727966[source]
    9.9.9.9 [1] has been praised by a bunch of people in the thread from a couple days ago [2]. How do those two compare?

    [1] https://www.quad9.net/

    [2] https://news.ycombinator.com/item?id=16716606

    replies(6): >>16727979 #>>16727988 #>>16728107 #>>16728131 #>>16728194 #>>16728214 #
    2. yjftsjthsd-h ◴[] No.16727979[source]
    Logging: https://www.quad9.net/privacy/
    replies(1): >>16728217 #
    3. okket ◴[] No.16727988[source]
    "Here are some DNS measurements comparing @Google Public DNS, @Quad9DNS and @Cloudflare, v6 and v4. Sourced from AS3320 near Frankfurt. Quad9 is fastest in avg. The proposed v6 address from Cloudflare is not yet working, but the longer ones."

    https://twitter.com/webernetz/status/980055981282484225

    4. dorfsmay ◴[] No.16728107[source]
    I love the fact that the consortium managed to get 9.9.9.9 (because Google's 8.8.8.8) and named themselves Quad9!
    5. r3bl ◴[] No.16728131[source]
    I don't use them (even though I would love to) because it takes approximately 3x as long to reach the server.

    To compare the two, together with Google's DNS as a reference, from a fast connection:

        64 bytes from 1.1.1.1: icmp_seq=5 ttl=59 time=3.62 ms
        64 bytes from 8.8.8.8: icmp_seq=5 ttl=60 time=3.60 ms 
        64 bytes from 9.9.9.9: icmp_seq=5 ttl=60 time=9.20 ms
    
    ...and from a slower (home) connection:

        64 bytes from 1.1.1.1: icmp_seq=5 ttl=58 time=11.1 ms
        64 bytes from 8.8.8.8: icmp_seq=5 ttl=59 time=11.9 ms
        64 bytes from 9.9.9.9: icmp_seq=5 ttl=59 time=34.2 ms
    
    Note that I just used the speed of every fifth package instead of the average for five packets in order to keep the comment relatively short and more humanly readable than "rtt min/avg/max/mdev".
    replies(1): >>16728437 #
    6. DesertBattery ◴[] No.16728194[source]
    Quad9 not friendly to CDN.

      $ dig +short @8.8.8.8 icnerd-1e5f.kxcdn.com
      p-rumo00.kxcdn.com.
      188.42.31.172
      $ dig +short @1.1.1.1 icnerd-1e5f.kxcdn.com
      p-rumo00.kxcdn.com.
      188.42.31.172
      $ dig +short @9.9.9.9 icnerd-1e5f.kxcdn.com 
      con-na00.kvcdn.com.
      p-ussj00.kxcdn.com.
      209.58.130.199
      $ dig +short @9.9.9.10 icnerd-1e5f.kxcdn.com
      con-na00.kvcdn.com.
      p-ussj00.kxcdn.com.
    7. 0x0 ◴[] No.16728214[source]
    Note that 9.9.9.9 is NOT a regular DNS service and does not give you an unrestricted view of the global internet domain name system.

    They match your requests with IBM's X-Force threat intelligence database and give you filtered results.

    https://www.theregister.co.uk/2017/11/20/quad9_secure_privat...

    replies(1): >>16728567 #
    8. matwood ◴[] No.16728217[source]
    Anonymized logging to improve the service and security. Is this different from Cloudflare?
    replies(1): >>16728359 #
    9. bitxbitxbitcoin ◴[] No.16728359{3}[source]
    Cloudflare is saying they won't log and will have audits by KPMG yearly to prove as such. Not logging and logging anonymized data are different approaches.
    replies(1): >>16728483 #
    10. Reason077 ◴[] No.16728437[source]
    Do you think that ~23ms is going to make any real, perceptible difference to your internet performance? Considering that a) your browser will make any DNS requests it needs in parallel when loading a web page, and b) most DNS requests will be cached anyway.
    replies(1): >>16728821 #
    11. matwood ◴[] No.16728483{4}[source]
    FTA: While we need some logging to prevent abuse and debug issues, we couldn't imagine any situation where we'd need that information longer than 24 hours.

    So the difference is how long the logs are kept, and possibly what the log data is used for.

    12. mandelbulb ◴[] No.16728567[source]
    https://quad9.net/faq/#Is_there_a_service_that_Quad9_offers_...

    Is there a service that Quad9 offers that does not have the blocklist or other security?

    The primary IP address for Quad9 is 9.9.9.9, which includes the blocklist, DNSSEC validation, and other security features. However, there are alternate IP addresses that the service operates which do not have these security features. These might be useful for testing validation, or to determine if there are false positives in the Quad9 system.

    Secure IP: 9.9.9.9 Provides: Security blocklist, DNSSEC, No EDNS Client-Subnet sent. If your DNS software requires a Secondary IP address, please use the secure secondary address of 149.112.112.112

    Unsecure IP: 9.9.9.10 Provides: No security blocklist, DNSSEC, sends EDNS Client-Subnet. If your DNS software requires a Secondary IP address, please use the unsecure secondary address of 149.112.112.10

    Note: Use only one of these sets of addresses – secure or unsecure. Mixing secure and unsecure IP addresses in your configuration may lead to your system being exposed without the security enhancements, or your privacy data may not be fully protected

    --------------------------

    IPV6: https://quad9.net/faq/#Is_there_IPv6_support_for_Quad9

    Is there IPv6 support for Quad9?

    Yes. Quad9 operates identical services on a set of IPv6 addresses, which are on the same infrastructure as the 9.9.9.9 systems.

    Secure IPv6: 2620:fe::fe Blocklist, DNSSEC, No EDNS Client-Subnet

    Unsecure IPv6: 2620:fe::10 No blocklist, DNSSEC, send EDNS Client-Subnet

    13. kentonv ◴[] No.16728821{3}[source]
    Yes, absolutely.

    I'm not sure what you meant in point (a) but, of course, DNS cannot be parallelized with HTTP since the browser doesn't know where to connect until DNS completes. Also, DNS requests for subresources can't start until the referring resource has been loaded. So you could easily see a few serialized DNS requests in the long pole for loading a web site.

    Also note that the timing above were ping times. An actual DNS query will have to recurse if the result is not cached at the DNS server -- which in these days of 60-second TTLs for is not uncommon. Cloudflare, though, happens to be the authoritative DNS for quite a few web sites, in which case no recursion is necessary.

    replies(1): >>16729484 #
    14. Reason077 ◴[] No.16729484{4}[source]
    "DNS cannot be parallelized with HTTP"

    I meant that DNS requests are parallelized within the browser. Once it loads the initial resource (html), there might be 10 more dependencies it needs at various different URLs under different domain names. It's usually loading all these dependencies that make up the vast majority of the load time on a complex web page.

    Those subsequent DNS requests can of course be made in parallel, so if your DNS latency is 20ms then you're adding ~20ms, not 10 x 20ms.

    Even then, DNS is probably making up a small fraction of the overall load time. If a complex page is taking, say, 3000ms to load and render, then adding 20-40ms of DNS time is not going to make a perceptible difference.