Re: [Driu] [DNSOP] SRV and HTTP

[Mark Andrews <[e-mail]>]

> On 12 Jul 2018, at 7:24 am, Nico Williams <[e-mail]> wrote:
> 
>>> On 11 Jul 2018, at 11:30 am, Mark Andrews <[e-mail]> wrote:
>>> 
>>>>> On 11 Jul 2018, at 3:55 am, Joe Abley <[e-mail]> 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: [phone]              INTERNET: [e-mail]