On Sun, Oct 19, 2025 at 06:53:03PM +0200, Philip Homburg wrote:
> In the context of DNS, I don't really see the problem because we already have
> many instances of extensible fields.
Having recently implemented a stub resolver API for the vast majority[1] of
registered RRTYPEs, that decodes each RRTYPE to a corresponding
application-layer structure, I very much disagree with the above.
Almost none of the DNS RDATA types contain fields with open data types.
The only exceptions that forced complex abstractions in application API
were:
- AMTRELAY (I decided to essentially ignore its extensibility)
- HTTPS (Pluggable value types)
- SVCB (Pluggable value types)
The EDNS OPT RR is largely internal, and does not leak into the types
seen by applications retrieving data from DNS.
With A and AAAA records the resulting RData can be used directly, and
the library providers "lookupA" and "lookupAAAA" functions that return
lists of IPv4 and IPv6 addresses respectively.
On the other hand with HTTPS lookups the return value is a list of
"HTTPS" RData structures, each with a preference and target, and then a
set (indexed by key ordinals) of values of the corresponding type
associated with each key. There is a lookup function to extract from
that set a particular value type (or nothing if the key is absent).
位> :set args www.cloudflare.net
位> main
www.cloudflare.net. 104.16.208.90 104.17.156.85 2606:4700::6810:d05a
2606:4700::6811:9c55
So the code to print any IPv4 and IPv6 hints in an HTTPS RR returned
by "lookupHTTPS" looks like:
iphints :: T_https -> IO ()
iphints (T_HTTPS pref tgt spvset) = putBuilder $
present pref
. presentSp tgt
. flip (foldr presentSp) ip4
. flip (foldr presentSp) ip6
$ present '\n' mempty
where
ip4 = case spvLookup spvset of
Just (SPV_IPV4HINT ips) -> toList ips
Nothing -> []
ip6 = case spvLookup spvset of
Just (SPV_IPV6HINT ips) -> toList ips
Nothing -> []
位> :set args www.cloudflare.net
位> main
1 . 104.16.208.90 104.17.156.85 2606:4700::6810:d05a 2606:4700::6811:9c55
> The oldest is of course the introduction of new RRtypes. Any library
> that deals with DNS as a whole needs to be able handle unknown
> RRtypes.
Multiple RRtypes do not force end-applications to deal with open types,
the result of a specific lookup is a (possibly empty) RRset of the
corresponding type, an indication of its absence or a loopup error.
This type of extensibilty DOES NOT complicate APIs except for
DNS-utility applications like "dig", ... that choose to dabble in
processing of ad hoc query results.
> With EDNS(0) came unknown options. Again, something software has to
> deal with.
DNS software, yes. A good DNS API isolates the application from having
to parse opaque RDATA blobs and supports returning already parsed parsed
structures of the requested types. These types are simple when the
RDATA schema ia fixed. They become complex when the RDATA schema is
extensible to contain future field values of not yet specified types.
--
Viktor. 馃嚭馃嚘 小谢邪胁邪 校泻褉邪褩薪褨!
[1] A -- 1
NS -- 2
MD -- 3
MF -- 4
CNAME -- 5
SOA -- 6
MB -- 7
MG -- 8
MR -- 9
NULL -- 10
WKS -- 11
PTR -- 12
HINFO -- 13
MINFO -- 14
MX -- 15
TXT -- 16
RP -- 17
AFSDB -- 18
X25 -- 19
ISDN -- 20
RT -- 21
NSAP -- 22
NSAPPTR -- 23
SIG -- 24
KEY -- 25
PX -- 26
GPOS -- 27
AAAA -- 28
NXT -- 30
SRV -- 33
NAPTR -- 35
KX -- 36
A6 -- 38
DNAME -- 39
Reserved -- 41 OPT (EDNS open typed options)
DS -- 43
SSHFP -- 44
RRSIG -- 46
NSEC -- 47
DNSKEY -- 48
NSEC3 -- 50
NSEC3PARAM -- 51
TLSA -- 52
SMIMEA -- 53
CDS -- 59
CDNSKEY -- 60
OPENPGPKEY -- 61
CSYNC -- 62
ZONEMD -- 63
SVCB -- 64 (open typed key-dependent value slots)
HTTPS -- 65 (open typed key-dependent value slots)
DSYNC -- 66
NID -- 104
L32 -- 105
L64 -- 106
LP -- 107
Reserved -- 128 NXNAME
Reserved -- 249 TKEY
Reserved -- 250 TSIG
Reserved -- 251 IXFR
Reserved -- 252 AXFR
Reserved -- 253 MAILB
Reserved -- 254 MAILA
Reserved -- 255 ANY
CAA -- 257
AMTRELAY -- 260 (open typed (4-127) relay slot)
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
