dc396

No. But given many of (e.g.) Balenciaga's ... offering's (https://www.balenciaga.com/en-us/women/accessories/sunglasse...), I'm sure there is a segment that would with the right marketing.

Fair warning: you have to log in prior to seeing example output. Would've been nice to know prior to entering information.

What a particularly stupid way of distracting from the Epstein files.

I guess it's just too bad if you're immunocompromised, allergic to vaccines, too young to be vaccinated, in the middle of a virulent, highly transmissible pandemic, etc. -- wouldn't want to protect society from disease ravaged individuals because it might intrude on their "bodily autonomy."

To paraphrase Captain Renault, "I'm shocked, shocked, to find that cocaine use is going on in here."

Accusing ICANN of incompetence when you can't be bothered to configure your DNS to avoid leaking queries to the root is an interesting approach.

The parent comment said "cross country".

You might want to look at the "domain" directive of resolv.conf and the concept of "split horizon DNS".

Ah, resolver (not DNS) search paths. They were a really bad idea that can and do lead to leaked queries that can result in all sorts of unpleasantness and risks.

As for certs, AFAIK, you can't get a certificate for a non-fqdn from a public CA since 2015.

The DNS is hierarchical. How would you replace TLDs?

Well, it depends. If all you were interested in was getting a "good" (e.g., short) name in .COM, no.

In the late 90s, when NSF allowed Network Solutions to charge for domain names, people complained that they (now Verisign) had a monopoly, so after a number of fine lunches and dinners in far off exotic places (see https://en.wikipedia.org/wiki/IAHC), there was a proposal to create more top-level domains, created the registry/registrar split, proposed the Uniform Dispute Resolution Policy (primarily for Intellectual Property owners), etc. Then, the US government stepped in and started a process that led to the creation of ICANN.

The whole point of this exercise was to introduce competition into the domain name system. It did with the registry/registrar split and tried with the registries by having multiple rounds of a limited number of new top-level domains. However, the latter was kind of stupid (IMHO): the switching costs for changing TLDs is way too high for the existence of new TLDs to significantly impact Verisign's monopoly -- instead, it created a bunch of monopolies.

However, people weren't happy with the "limited number" part of ICANN's efforts to introduce competition in the TLD space, so in 2012, the ICANN community (which anyone can be a part of) opened the flood gates, removed the arbitrary restrictions on how new top-level domains could be created, and we now have over 1500 TLDs.

I'm not sure what you mean by "DNS allows search" -- by the usual definition of "search", the DNS doesn't: it is a lookup mechanism. I'm also not sure who "we" are in your idea or what you mean by "qualified with an end dot": all domains that get looked up implicitly have a "." (a zero length label that signifies the end of the query name) if it isn't explicit.

.VA is a country code TLD, assigned because it is listed in ISO-3166. The others are "generic top-level domains" which had to go through ICANN's new gTLD program, which has a lot of rules (338 pages of them for the 2012 round) and costs a lot of money (US$185K to start with recurrent fees dependent upon the number of registrations). I suspect it isn't about centralization, but rather about perceived cost/benefit ratios.

Ignoring the point that climate sensitivity wasn't in the parent comment, AFAIK, airplanes generate 0.16 kg/km, whereas trains are around 0.1 kg/km and container ships are at 0.016 kg/km. However, passenger ships and gas cars are at 0.25, diesel cars at 0.28 kg/km and rockets are over 1.0 kg/km, so it appears planes are in the middle, not really "one of the best ways" to worsen climate change.

Sure, through a simple analysis of CO2 kg/km, trains are better for the climate for long distance travel, but they are vastly slower (average time from LA to DC is over 80 hours), which has knock-on effects, e.g., sleeping at home averages 0.25 - 0.32 kg/night, whereas staying at a hotel averages 10-40 kg/night, eating at home averages 2.3 kg/meal vs. 3-8 kg/meal, etc.

That's quite a reach.

Corruption in Washington DC causes people to die through environmental, engineering, and military catastrophes. It leads to a degradation of rule of law throughout the country and even the world. Corruption in student governments at large universities would not appear to be "just as impactful".

Yes, US rail is pathetic, at least for passenger travel. However, a quick search on Google Flights shows a one-way ticket from LA to DC costs $98.00 on Frontier via Atlanta (YMMV) so I don't think it's correct to say there isn't cheap, easy, high speed travel across the country.

User experience is always at the whim of ISP agreements unless you are paying for point to point links.

Sounds like you're experiencing vagaries of somebody (maybe Cloudflare, maybe some other ISP Cloudflare is peering with) doing traffic engineering, probably to reduce congesting on particular paths. The recommendation to go with the Pro plan is likely just the first step, the next step is to open a ticket and get them to fix it -- that's what you're paying them for.

Dropping Cloudflare is, of course, an option as most of the security stuff they do can be handled by competent security folks, but you (may?) need to find someone similar if your site is at risk of DDoS.

> corruption at that [student gov't at large state universities] level is probably just as impactful as corruption in Washington, DC.

Um, what?

A few possible answers: inflation, cost to upgrade infrastructure to keep up with e.g., DDoS attacks, costs to deal with revised ICANN rules, etc. And/or greed.

A TLD is a bit more than simply a registry of domain names. For gTLDs, you might look at https://www.icann.org/resources/pages/gtld-2012-02-25-en

Just don't say bad things about the king...

Nope. A variation on Ribbon filters (https://engineering.fb.com/2021/07/09/core-infra/ribbon-filt...). See https://hacks.mozilla.org/2025/08/crlite-fast-private-and-co....

> Too many domains which are incorrectly configured leading to non-existing domain errors.

That's an interesting and somewhat surprising data point given the use of DNSSEC validation at public resolvers (e.g., 1.1.1.1, 8.8.8.8, etc.). Might be something that would be useful to track by those following DNSSEC deployment.

For selectively disabling DNSSEC validation, I gather PiHole+dnsmasq doesn't support Reverse Trust Anchors (RTA). Unfortunate.

So you're saying the end user does not care about the data (IP addresses, mail servers, etc.) for the domain names they're trying to reach and they'd be perfectly happy (say) going to the IP address of an attacker controlled website instead of their bank? Interesting position.

I'm unclear there is a security issue with dnsmasq -- maybe leaving a transaction alive too long (but then again, what does "too long" mean these days?). However, I haven't looked into the "vulnerability" referenced to be sure (the "malformed name" aspect of the report doesn't fill me with confidence).

I contend that creating signatures over the data at the sending side and then validating those signatures at the receiving end is superior protection to encrypting the channel over which the data is transmitted. Protecting the data is end-to-end. Protecting the channel is hop-by-hop. If you could ensure that the client speaks directly to the authoritative(s), the protection would be equivalent. But that's not how the DNS is operationally deployed (dnsmasq is a perfect example: forwarders really shouldn't exist).

I would agree with you that operationally, DNSSEC deployment is lacking (i.e., water is wet) and the requirement for both the authoritative side and resolving side to simultaneously implement is a (very) heavy lift. However, even your Tranco stats show that there are pockets of non-trivial deployment (e.g., governments) and I believe the trend is increased deployment over the long term globally.

Fortunately, it's not either/or. I personally prefer DoT/DoH to a trusted (i.e., that I run) resolver that DNSSEC validates. Unfortunately, as dnsmasq doesn't appear to implement forwarding to DoT/DoH resolvers, you're left with DNSSEC or not using dnsmasq (which is what I gather you're recommending).

While the functionality/complexity of dnsmasq makes me nervous and I use it (I don't have a use case for it), it isn't clear to me that dnsmasq is doing anything wrong in this particular case.

I guess you and I were at different meetings. I was at meetings at NSF with TIS folks that resulted in funding for DNSSEC implementation in BIND where the presentation focused on the 16-bit transaction field (and included a live demonstration), so I'll stand by my view that the point of DNSSEC was to address that particular flaw.

In any event, that's a nice site that provides useful stats.

Transport security protects the channel, not the data. DNSSEC protects the data so that the channel doesn't matter. Given how the DNS is deployed particularly in enterprise environments, there have been too many times when protecting the channel simply meant data corruption crept in someplace in the sometimes ridiculous chains of forwarders and caches.

Oh, and it doesn't appear dnsmasq supports DoH/DoT forwarding (not positive as I don't use it and haven't looked at the code). It does support DNSSEC.

It's unclear to me what "make the DNS security model cohere with IPSEC" means. DNSSEC was a direct response to the vulnerabilities identified by a number of folks and documented by Christoph Schuba (https://www.cerias.purdue.edu/assets/pdf/bibtex_archive/94-0...). ISC was hired as a sub-contractor by TIS (I signed the contract for ISC) to implement DNSSEC in BIND specifically to address the transaction ID flood vulnerability.

> Query ID prediction attacks are not in fact the point of DNSSEC

Do you deny DNSSEC's goal is to protect DNS data? Do you deny "Query ID prediction attacks" (or more generally, flooding attacks) aim to corrupt DNS data? Do you deny the 16-bit transaction ID allows for effective flooding attacks?

As for "almost nothing in the DNS is signed", while it's true the percentage of second-level domains aren't signed, the DNS root is signed, all generic top-level domains, and the vast majority of country code TLDs are signed. In some countries (e.g., The Netherlands) more than 50% of the zones in their ccTLD are signed. As we've seen empirically, with improved automation/tools and authoritative servers that turn on DNSSEC-signing by default, the percentage will go up.

> DNSSEC was created because we needed to put root and gTLD servers in Russia and China (lying authoritatives).

Interesting assertion -- do you have anything to back this up?

While DNSSEC can prevent a name server operator from effectively modifying zone data (at least without the signing key and for resolvers that bother to validate), protecting against an authoritative name server operator from maliciously modifying the zone data in their server was not a significant consideration in any of the IETF/implementation discussions I was in (back in the late 90s, I ran ISC during the development of BIND 9.0 and participated quite heavily in DNS-related working groups).

Transport security obviously only protects the channel of communication. It does nothing for ensuring the authenticity of the data. In order to protect the data so it doesn't matter where the data comes from (authoritative, resolver, off the back of a truck, etc.), you have to take the steps DNSSEC takes. This was recognized as far back as 1993.