Re: [DNSOP] SRV and HTTP

> On 11 Jul 2018, at 3:53 pm, Patrik Fältström <paf@frobbit.se <mailto:paf@frobbit.se>> wrote:
> 
> On 11 Jul 2018, at 3:30, Mark Andrews wrote:
> 
>> 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.
> 
> 4) Various libraries in PHP and ultimately lib curl do not include SRV in the resolution

Then PHP is not STD 13 compliant.  Resolver libraries are supposed to be able resolve UNKNOWN records per STD 13 and that includes SRV.
As for lib curl, there is not a RFC that says to lookup SRV records for HTTP or HTTPS.

> 5) New resource record types are very hard to implement (same argument as why we use TXT for SPF and not SPF for example)

SPF was just plain unwillingness to complete the transition.  The code was out there.  It was being deployed.  TXT to SPF transition was never part of the experiment, it was in addition to the experiment.

No resources record is hard to implement.  What hard is getting someone to commit 30 minutes to 1 hour of time to do something at all.  That is what it takes most pieces of software to add a new record type.  Thats been true since I started in the DNS back in the early 90’s.

> 6) You "only" change hostname with SRV and not a "complete change of the URL

>> 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.
>> 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.
>> 3) is addressed by adding some signalling between the client and recursive server to indicate if the additional section is complete or not.
> 
> 4) Is of course "just code" in lib curl and what not
> 
> 5) Is like (4) but possibly harder if you want it implemented in PHP, javascript etc and not in the underlying libraries
> 
> 6) This is why I came up with URI which is supposed to be a competitor to "well known URI"
> 
>  paf

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org <mailto:marka@isc.org>