On Mon, Oct 20, 2025 at 03:57:24PM +0000, Paul Hoffman wrote:
> SVCB/HTTPS, and the future DELEG/DELEGI, use subtypes for more than
> just reducing the number of new RRtypes: they use them for grouping
> subtyped data into a logical record. Saying "you can't do that" puts a
> limit on designs where one qname might have sets of related data. It
> feels inappropriate for DNSOP to say "you can't do that in the DNS"
> just to make life easier for API developers.
If you read my initial post in this thread, you'll see that I
specifically called out SVCB and HTTPS as cases in which open typed
extension fields were justified. My point was that this has a
non-trivial cost, and such extensibility should be avoided when
the YAGNI principle is plausibly applicable. I am pointing out
AMTRELAY as such a case.
Yes, DELEG will be another case with open-typed fields, and would
likely reuse code or code patterns from SVCB and HTTPS. Most
applications will never deal with DELEG, it is internal DNS metadata.
On Mon, Oct 20, 2025 at 01:13:29PM -0400, Michael Richardson wrote:
>
>
> I think, but I hope Viktor will confirm, that the problem isn't so much the
> subtyping itself, but rather the syntax of the value side of things.
> SVCB/HTTPS (DELEG) are maps with keys and values.
>
> If the values have wide-open to-be-defined-by-extension formats, then it
> becomes hard.
Yes, it complicates the data model and APIs. OK, when justified, best
avoided when YAGNI.
> If they are restricted to some clear set of value-types, then it's
> better. That might be a good middle ground: the RR type RFC needs to
> define valid formats for values, and any extension requires a new
> RR-type.
Sure, if the syntax of extensions is fixed to a small "vocabulary", and
all that the future brings are semantic variations over the same
underlying data types, that can make it simpler to implement a
future-proof API.
On Mon, Oct 20, 2025 at 05:23:01PM +0000, Paul Hoffman wrote:
>
> > If they are restricted to some clear set of value-types, then it's better.
> > That might be a good middle ground: the RR type RFC needs to define valid
> > formats for values, and any extension requires a new RR-type.
>
> That proposal sounds fine to me, but that's not how I read Viktor's
> request. (And I'm not sure how that restriction could be made in a way
> that future creators of new RRtypes would find it, which would make
> this effort moot.)
I am suggesting paying attention to the trade-off between extensibility
and usability. If the need for extensions is remote at best, I'm
suggesting not building that into the specification.
On Mon, Oct 20, 2025 at 10:33:50AM -0700, Watson Ladd wrote:
>
> I disagree to a point. An API that exposes the fields it knows about,
> while also exposing unknown extensions is possible while also giving
> raw access to all when needed. This is fairly well established in
> dealing with X509. It's true that if there's a format restriction that
> the library/ecosystem doesn't have a way to support, application
> writers have a more difficult time, but there's no working around that
> even with a new RR type.
I have exactly that sort of API for SVCB and HTTPS, and applications
can even extend the set of supported key/value codecs without upgrading
the library. The stub resolver is table driven:
- Table mapping RRTYPE ordinals to encode/decode functions
that consume or produce an abstract RDATA value, that
supports a safe type cast to its concrete type.
- For a few RRTYPEs (currently OPT, SVCB and HTTPS) additional
tables abstracting the sets of supported EDNS options, or
key/value pairs.
When a "resolver" object is initialised, the application can extend
the RRTYPE table, and/or extend the EDNS, SVCB or HTTPS extension
tables. None of this is particulary deep, but it has a cost, which
should I think be imposed only when justified.
Thus, if, for example, the library had not yet supported the "ohttp"
SVCB key type, an application could add[1] it, in pretty much the
same way that the built-in keys are defined. And if the "RP" RRTYPE
had not yet been implemented, an application could add[2] that.
--
Viktor. 🇺🇦 Слава Україні!
[1]
https://github.com/dnsbase/dnsbase/blob/5c50dd637238d05cb3f336f6d7d410b5c4467205/extensible.hs#L75-L94
[2]
https://github.com/dnsbase/dnsbase/blob/5c50dd637238d05cb3f336f6d7d410b5c4467205/extensible.hs#L17-L71
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
