[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==--