[ TL;DR
The API design is of course doable, I'm even doing it for HTTPS,
SVCB and OPT, but it has a cost, not only for the library
maintainer, but, also crucially, for the application user, in terms
of more elaborate accessors and data types.
My point, perhaps by now somewhat lost in the long thread, is that
the cost should be justified. I agree it is justified with SVCB and
HTTPS, but IMNSHO it is not justified with AMTRELAY, where the
reserved relay types 4–127 and associated IANA registry are I wager
just YAGNI bloat. This thread was motivated by my decision to punt
on building extensibility into that RRTYPE, based on a strong
intuition that it would not ever be needed. ]
On Sun, Oct 19, 2025 at 03:35:50PM -0400, John Levine wrote:
> It appears that Viktor Dukhovni <[email protected]> said:
> >We're lately seeing novel DNS RRTYPEs that are extensible by
> >introduction of new RDATA field types. ...
>
> >One ends up with complex models, with abstract classes for the value
> >slot, and extensible codecs with pluggable cocrete methods for the known
> >value types, and a generic "opaque" decoder that handles octet string
> >blobs for the unknown types. Applications can then do type-safe casts
> >of an abstract value field to a known concrete type.
>
> It seems to me that when there's a new RRTYPE, you have to add a new RRTYPE
> routine to your library to handle the RRTYPE, or if there's a new field type,
> you have to add a new field option to an existing RRTPE routine. I don't see a
> lot of difference.
When the DNS is extended with new RRTYPEs, that "you" is the library
maintainer, the application developer of an existing application, that
uses existing RRTYPEs is unaffected. For a trivial example, applications
can still retrieve "A" and "AAAA" records in exactly the same way, even
after the introduction of "SVCB".
> I suppose there might be a few situations where you need to pass
> everything to some upper layer, but if the upper layer is going to
> have new code to handle new fields, fix the library too.
The Haskell stub resolver I am maintaining allows applications to
augment the set of supported RRTYPEs without requiring a corresponding
change in the library. Applications can provide a definition for a new
codepoint that specifies encoding and decoding the wire form to a new
data type, and returning a "builder" (streaming serialiser) for its
presentation form. This is how the library itself adds new RRTYPEs,
only these are then available in the default resolver instance, without
additional configuration.
With RRTYPEs such as SVCB, extensibility leads the API to model the
RData as an "existentially quantified" set of key value pairs, that is
internally indexed by the key number. Each of the associated "known"
(or application provided) key/value types comes with its own wire-form
codec and presentation form builder. A lookup function "spvLookup"
allows an application to query the set for particular value type:
spvLookup :: KnownSVCParamValue a => SPVSet -> Maybe a
the associated key number is looked up, and the "existentially
quantified" union is safely cast to the requested type. Thus
one can pattern-match a non-empty list of IPv4 addresses from
an HTTPS RRset (T_https) via:
getHints4 :: T_https -> [IPv4]
getHints4 (T_HTTPS _ _ spvset) = case spvLookup spvset of
Just (SPV_IPV4HINT ips) -> toList ips
Nothing -> []
which returns a non-empty list when the key is present, and an empty
list otherwise. Similarly,
getHints6 :: T_https -> [IPv6]
getHints6 (T_HTTPS _ _ spvset) = case spvLookup spvset of
Just (SPV_IPV6HINT ips) -> toList ips
Nothing -> []
getPort :: T_https -> Maybe Word16
getPort (T_HTTPS _ _ spvset) = case spvLookup spvset of
Just (SPV_PORT port) -> Just port
Nothing -> Nothing
getAlpn :: T_https -> [ShortByteString]
getHints6 (T_HTTPS _ _ spvset) = case spvLookup spvset of
Just (SPV_ALPN alpn) -> toList alpn
Nothing -> []
...
Through resolver configuration, applications can extend the resolver
with definitions of additional "KnownSVCParamValue" types that can then
be accessed via the same `spvLookup`, converted to presentation form,
or, if one is perhaps writing a DNS responder, serialised to wire-form.
--
Viktor. 🇺🇦 Слава Україні!
P.S. I haven't had a need for parsing RRs from their presentation form,
so that's not currently a feature of the library, but could probably be
added along the same lines.
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
