It's a viable strategy. No legitimate implementation produces compression pointers that go anywhere other than backwards. I track the start of a label sequence and whether I've followed a pointer. If I've just followed a pointer, I must be at a point earlier than the last start, or I consider it a malicious name. I also disallow pointers to pointers but I'm less confident that there's not something out there that does that.

So, using () as a marker for the length of a label, and (^name) for a label pointer, how do you handle

    ()a()b(^b)

The pointer goes backwards, but it doesn't go back to the start of a label sequence. So do you track the start of each label? Or just the start of each domain name?

Edit: nevermind, I see what you are doing.

> On the TLSA side, the argument is roughly that (1) the WebPKI is bad ...

Is that a common argument? I've seen it argued that WebPKI shouldn't be used because it outsources DNS trust to the CAB forum, but not "WebPKI is bad".

There's private use ranges for classes and types. They don't have specific mnemonics but you can use the generic ones (eg: CLASS65280 and TYPE65280).

CHAOS probably gets used most because that's what BIND happened to do.

I just sort of assume it's because `dig` already has the string mapped. But maybe people just like typing "chaos".

A possibly needless clarification: The DNS is organised by class, name, and then type. Each class is a seperate space, so ycombinator.com in the IN (Internet) class and ycombinator.com in any other class aren't necessarily the same entities. Types can also be class specific, for example A in the IN class is different to A in the CHAOS class. Types may also only be defined in specific classes like SRV (amongst others) in IN. (Aside: this model is why CNAMEs can't coexist with other records.)

> ... especially on a "nonstandard" TLD.

I guess that's a dig but I'm not sure why. It's resolvable via the ICANN root and is no more "nonstandard" than any of its siblings.

I've found that I tend to ignore any sites which aren't the traditional net/com/org or the well-known ccTLDs when they show up in search results. Perhaps because the majority of them seem to be used for hosting vapid SEO spam. It's an almost subconscious aversion trained by years of browsing experience, when assessing the trustfulness of a site, that "weird TLD" will be a negative weight.

I can understand how you might arrive at such an intuition but I'm not sure how well it serves you, particularly when you apply it outside of the search results that have formed it. There's over 150 million names under .com, people are going to go elsewhere.

Has anyone here had experience with Glauca? I'm curious about them because they support RFC 2136.

Namecheap's DNSSEC implementation has broken a number of times and last I looked their API was pretty poor.

My problem with this spec is it requires Service Providers and DNS Providers to know about each other. It's essentially formalising the status quo of cookie cutter setups for big name providers.

Yeah, I read the website and the entire spec. I think it's pretty good, but it's built by big names for big names. There's nothing wrong with that, but I'm concerned it might not be appropriate for things like quickly pointing a simple A Record at a self-hosted open source service. Maybe I'm wrong. I'm having a good discussion with the spec developers here: https://github.com/Domain-Connect/spec/issues/64

Dynamic responses make transfers difficult to implement in some server architectures. Which is not to take away from your point - trying to hide things in the DNS is a fairly pointless exercise.