On Mon, Oct 24, 2022 at 12:45 PM Paul Wouters <p...@nohats.ca> wrote:
> On Mon, 24 Oct 2022, Brian Dickson wrote: > > > Just to expand on this idea (which I quite like), the original AS112 was > enhanced to handle new/arbitrary names, so > > that AS112 operators don't need to do anything to support being a sink > for new domains. > > > > This was done in RFC7534 and RFC7535, using the new "empty.as112.arpa" > target for use via DNAME. > > (The DNAME bit is so there isn't a delegation for which the AS112 > operator would need to have a zone configured.) > > > > Using this via the root zone would be a new kind of entry for the root > zone, but is otherwise non-controversial > > (IMHO). > > It would basically look like: > > alt. DNAME empty.as112.arpa > > this is dangerous. Anyone who runs an as112 node, or an attacker who > compromises one, can then serve a "real" .alt to a percentage of > queriers. Imagine millions being lost in some cryptocurrency .alt > non-dns scheme. > > This is accurate. It is dangerous to other namespaces if they don't take appropriate safeguards. What this points out is that ".alt" is intended to protect DNS (at the root at least) from the effects of other namespaces. It is not (or at least has not been explicitly established for) use by other namespaces to protect themselves from errors like this. In the jargon of mathematics, "alt" is necessary, but not sufficient. Any namespace that would fall under the "please use .alt" umbrella, would be wise to build into the protocol(s) or implementation(s) some guard-rails against leakage. So, another reason for "MUST NOT", but perhaps out of scope for dnsop itself to say (other than to indicate, "here be dragons".) Brian
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
