7 ms·

I believe the point they were making is that they could use their own domain and infrastructure for the same kind of testing. Something like "<random-chars>.nxd

I believe the point they were making is that they could use their own domain and infrastructure for the same kind of testing. Something like "<random-chars>.nxdetect.firefox.com" would keep the responsibility for the feature on Firefox's name servers. The same could be done for Chromium rather than contributing to a tragedy of the commons situation. There is an obvious flaw which is that this behavior is detectable and avoidable by ISPs that become aware of what that domain is being used for... But that argument applies to the current detection method as well (as this post demonstrates).

lifthrasiir 4y ago
> But that argument applies to the current detection method as well (as this post demonstrates). No, because the post is a post-mortem analysis. If ISPs are going to block this they will have to do so in live, and as presented I don't think they can do that without a disruption.
- TrueDuality 4y ago
  Sorry, I realized its not directly covered by the post and I read between the lines a little bit. What I read (between the lines) is that there are only a handful of truly valid roots which are all well known. None of the randomly generated Chrome domains will ever resolve to a real address because the random characters are not valid top level domains. A malicious filtering actor could fairly easily change their redirect behavior to only apply to NXDOMAINs issued to valid TLDs and bypass this check. The original point stands in that this feature abuses a common good at the expense of an operator (requiring 2x the capacity without it by the metrics given in this post) for a niche feature that they could run with equal effectiveness against a domain they control instead.
  - tptacek 4y ago
    It's not abusing anything. All it's doing is creating a prominent feature on a graph. The roots are designed to handle this kind of traffic, required to do so, and more than capable of doing so. Application developers are not required to use the DNS parsimoniously, and never have been.
    - TrueDuality 4y ago
      The roots are a "common good" and yes they're designed to handle this level of traffic because they have to. I also agree application developers don't have to be generally restrained in their use of DNS when using the protocol for its intended purposes. Attempting to look up domains with the intention that they don't exist and are expecting the general case to be a failed query is not using the DNS system as intended. As I mentioned this could be solved by the application including a domain they control so they are not excessively consuming a public good at the expense of others (someone does have to pay for these servers). The roots should not be expected to double their capacity because one application implements a feature in bad faith.
      - tptacek 4y ago
        The roots aren't "doubling their capacity". They're not doing anything resembling doubling their capacity. The only thing that "doubled" is a line on a graph. If your conception of the root servers is that they're generally redlining and we're just scraping by with the capacity we need for current load: no. If we don't have a shared understanding of the facts here, we can't have a productive discussion about this topic.

lifthrasiir 4y ago

> But that argument applies to the current detection method as well (as this post demonstrates). No, because the post is a post-mortem analysis. If ISPs are going to block this they will have to do so in live, and as presented I don't think they can do that without a disruption.

TrueDuality 4y ago
Sorry, I realized its not directly covered by the post and I read between the lines a little bit. What I read (between the lines) is that there are only a handful of truly valid roots which are all well known. None of the randomly generated Chrome domains will ever resolve to a real address because the random characters are not valid top level domains. A malicious filtering actor could fairly easily change their redirect behavior to only apply to NXDOMAINs issued to valid TLDs and bypass this check. The original point stands in that this feature abuses a common good at the expense of an operator (requiring 2x the capacity without it by the metrics given in this post) for a niche feature that they could run with equal effectiveness against a domain they control instead.
- tptacek 4y ago
  It's not abusing anything. All it's doing is creating a prominent feature on a graph. The roots are designed to handle this kind of traffic, required to do so, and more than capable of doing so. Application developers are not required to use the DNS parsimoniously, and never have been.
  - TrueDuality 4y ago
    The roots are a "common good" and yes they're designed to handle this level of traffic because they have to. I also agree application developers don't have to be generally restrained in their use of DNS when using the protocol for its intended purposes. Attempting to look up domains with the intention that they don't exist and are expecting the general case to be a failed query is not using the DNS system as intended. As I mentioned this could be solved by the application including a domain they control so they are not excessively consuming a public good at the expense of others (someone does have to pay for these servers). The roots should not be expected to double their capacity because one application implements a feature in bad faith.
    - tptacek 4y ago
      The roots aren't "doubling their capacity". They're not doing anything resembling doubling their capacity. The only thing that "doubled" is a line on a graph. If your conception of the root servers is that they're generally redlining and we're just scraping by with the capacity we need for current load: no. If we don't have a shared understanding of the facts here, we can't have a productive discussion about this topic.