On Thu, Jul 12, 2018 at 08:51:43AM +1000, Mark Andrews wrote: > >>> 1) is addressed by defining a new type(s) rather than using prefixes. > > > > While that is correct, and truly, it is trivial to implement, it is not > > trivial to deploy: too many DNS hosting providers would have to update > > UIs. > > Garbage. There really isn’t. People keep saying something can’t be done > because there are too many X. X get replaced. X get updated. As for DNS > hosting providers that support a given type, we create a site and report > what software by version and date and what DNS hosting providers support > the type native or unknown formats.
I didn't mean to say not to go this way. On the contrary, we should. Just that this is an issue. > We also don’t have to achieve 100%. People can move to DNS hosters that > do support the type or host their own DNS. Every DNS hoster that provides > slave/secondary services already supports they type as UNKNOWN has been out > there so long. Ah yeah, that's true -- not a great UI, but it works. > >>> 2) is addressed by getting recursive servers to fill in missing > >>> additional data before returning. Named has code in review for this for > >>> SRV as proof of concept. > > > > That would be very nice indeed. Unbound will need that too. > > > >>> 3) is addressed by adding some signalling between the client and > >>> recursive server to indicate if the additional section is complete or not. > > > > Well, OK, but as with (2) that requires recursive resolver critical > > mass. Not necessarily a big deal, though it will take enough time that > > many apps will need to support falling back to doing multiple queries > > one by one. > > They can do the queries in parallel, that 2 RTTs. Yes, that's a big deal. _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
