> On 12 Jul 2018, at 7:24 am, Nico Williams <n...@cryptonector.com> wrote: > >>> On 11 Jul 2018, at 11:30 am, Mark Andrews <ma...@isc.org> wrote: >>> >>>>> On 11 Jul 2018, at 3:55 am, Joe Abley <jab...@hopcount.ca> wrote: >>>>> >>>>> *cups hand to ear* >>>>> >>>>> Was that the sound of a distant desire to specify use of SRV for >>>>> HTTP? >>> >>> I think there are three main objections. >>> >>> 1) Wildcards don’t work with prefixes. >>> 2) Additional data isn’t always returned it may require multiple round >>> trips. >>> 3) Additional data processing doesn’t support negative responses. >>> >>> All of these issues are trivially easy to fix. It just require willingness >>> to implement. >>> >>> 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. 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. > Let me add my voice in favor of new RR types by which to replace SRV > RRs. URI is one of them, for the sorts of things we do in Kerberos for > KDC discovery, but no really appropriate for resolving HTTP authorities. > >>> 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. > Nico > -- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
