On Sep 17, 2024, at 10:37 AM, Petr Špaček <[email protected]> wrote: > > On 17. 09. 24 15:57, Stephane Bortzmeyer wrote: >> On Tue, Sep 17, 2024 at 03:16:43PM +0200, >> Petr Špaček <[email protected]> wrote >> a message of 30 lines which said: >>> I think EDE 29 (Synthesized) with text note "RFC 8482" is perfectly >>> appropriate for the made-up HINFO answer to ANY (or RRSIG or ...) query. >> I tend to disagree since RFC 8482 is about removing data that exists, >> not the opposite. > > I tend to disagree. HINFO is (nowadays) very unlikely to exist in the first > place, so it is _also_ about making stuff up. Especially when asked for > nonexistent.whatever.example ANY the server might conjure new HINFO answer > from nothing. > > In my view it's not about removing data, it's about _not even looking at the > data_ in the first place. > >> But there is another question: should we try to save codepoint space >> by using the same EDE for many different uses (and using the extra text >> to demultiplex) or should we use the fact that the registration policy >> is quite open to register many codes? RFC 8914, section 5.2, does not >> offer any guidance. > > I agree that code points are cheap, but on the other hand if there is too > many code points to chose from implementations will use different codes for > the same thing and that will make it _harder_ for consumers to make sense of > meaning. > > Specifically for RFC 8482, I think special code is warranted only for section > "4.2. Answer with a Synthesized HINFO RRset", and the existing EDE 29 > (Synthesized) fits that very nicely. > > > All the rest is normal 'ANY means literally "any"' [1] and I think RFC 8482 > sections 4.1 and 4.3 do not need special code because it would not add useful > information. >
To be sure, I looked for the title of “RFC 8482” : "Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY” (I’m too old to memorize numbers anymore.) It’s important to start with this as “denying ANY” isn’t the same as a “synthesized response” despite one practice in the document is to synthesize HINFO. Examples of synthesized responses - wildcards and, to some extent, negative answers from cached NSEC information, plus there is always the “proprietary option” - synthesizing from some other (non-documented maybe) process. I do recall giving a talk at DNS-OARC, a lightening one, in February 2020 (San Fran) about the annoying nature of that document (RFC 8482). It has too many ways a responder can “weasel out” of responding will all the data sets at a name. To be clear, I applaud “eliminating” the practice of sending all data sets in response to one query. But given that it was common practice at one time, an explicit, deterministic response is needed to say “no”. The reason I cared is that I used to observe all the data published at TLD apex names to determine how DNSSEC was being implemented. I used ANY queries to grab what was at an apex name, if I wasn’t allowed to do that, I’d poll for the types of interest. The fallback is pretty simple. A simple indicator that the responder would not reply to a query for type = ANY, is sufficient. _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
