[DNSOP] Re: Is DELEXT too restrictive?

Michael Richardson <[email protected]> Tue, 28 Jul 2026 21:03:54 +0200
Newsgroups gmane.ietf.dnsop
Message-ID <3439850.1785265434@dyas>
--===============3940747516796578536==
Content-Type: multipart/signed; boundary="=-=-=";
	micalg=pgp-sha512; protocol="application/pgp-signature"

--=-=-=
Content-Type: text/plain


Pieter Lexis <[email protected]> wrote:
    > On Tue, 2026-07-28 at 11:59 +0100, Roy Arends wrote:

    >> [...]

    > Moving the requirement to specify NS and DelExt Record interaction to
    > the specifications of those records makes a lot of sense to me.

    > Leaving the usage of NS vs. DelExt Records decision to the resolver and
    > allowing the auths to serve DelExt Records alongside NS records in
    > delegations makes introducing new DelExt Records easier. As namservers
    > supporting DelExt, but not those new records, can just serve them
    > without extra processing.

Agreed.
I just wish we'd done this for (before) DS :-)

(I don't really understand the pushback. I guess I shall re-read archives)


--
Michael Richardson <[email protected]>, Sandelman Software Works
 -= IPv6 IoT consulting =-                      *I*LIKE*TRAINS*




--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAmpo/RoACgkQlUzhVv38
QpAJzAf/WTDok7syX1KIK9loA4zkTLAwPssV9Ctv4QPnwn/WRUX7t4qWVaiAQ3hk
tzTzkqsHKZsUDbWfNm8ygNFchh5p91Pg8mk3llN1/p9ZC4VylG9wbxH2sgaYAPOZ
I9GtYs4PERMNnUnnacnpZ5fsijW1jDYszR1kRIJwOknKFLMOpcfKPQ5/79d40biM
IMqtz8fxALZKS/01cq4UT4gOGI7s675fQ3dMDLL0r/NM9hFG3CnZSyMlXR+LoLRV
FGY2HQZ1dAFjvztWudCYkwHpwBOlbQLP9ooEPkSr4LOjo34k6t51WZ53GZOf6HOZ
FcVJ6BCE+B0vYNTCcO4gKge/QNNAuA==
=zf8A
-----END PGP SIGNATURE-----
--=-=-=--


--===============3940747516796578536==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KRE5TT1AgbWFp
bGluZyBsaXN0IC0tIGRuc29wQGlldGYub3JnClRvIHVuc3Vic2NyaWJlIHNlbmQgYW4gZW1haWwg
dG8gZG5zb3AtbGVhdmVAaWV0Zi5vcmcK

--===============3940747516796578536==--