Mark Andrews wrote on 2024-06-26 16:02:
...
Adding a new RRTYPE requires zero infrastructure upgrades. It’s a database
entry at IANA. Every DNS server on the planet should handle these
transparently. That was required by RFC 1034 and RFC 1035. You can even add
them to zones before the parsing software is updated using unknown type
representation (RFC 3597) which was one thing that was missing from RFC 1035
that would have made adding new types easier. Nameservers and stub resolvers
were always required to treat unknown records as opaque objects.
in terms of dns infrastructure this is true. while the open source
implementations are fastest to adopt and deploy new rr types, even
proprietary dns implementations are rarely more than a year behind.
but there's infrastructural middleware for which this is not true.
registries and registrars and things like "webmin" are usually five to
ten years behind on adding support for new rr types. thus, the SPF
debacle in which the application had to back off and go with TXT. and
thus the tendency today to use an existing rr type and a well-known
subdomain beginning with an "_" as a way to deploy more or less immediately.
dns itself is not the problem. but there is a real problem here about
which the dns technical community can do precisely nothing.
This doesn’t mean that there weren’t mis-implementations of the standards which
failed to handle unknown types correctly but there have been 78 types added
since RFC 1034 and RFC 1035. That’s 2-3 per year. Nameserver developers know
how to add new record types quickly.
agreed, but that's not the point being argued.
--
P Vixie
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
