Re: [Http-srv] Alternative to SRV?

[Erik Nygren <[e-mail]>]

On Fri, Aug 24, 2018 at 7:06 AM Shumon Huque <[e-mail]> wrote:

> On Fri, Aug 24, 2018 at 6:36 AM Ray Bellis <[e-mail]> wrote:
>
[deleted]


>
>
>> FWIW, I'd also like to do away with underscore labels for these records,
>> since (again from the web / DNS hosting point of view) they interact
>> badly with DNS wildcard records.
>>
>
> Yes, I think this issue is definitely worth addressing. One question is:
> does HTTP need port or other parameter specific redirection, which
> presumably is why the DNS ALTSVC record has the underscore labels. And if
> so, what is the best way to achieve that? Pushing those parameters into the
> RDATA is one way, but that will lead into predictable arguments about
> record subtyping and inability to surgically extract just the required
> response.
>

They unfortunately may be needed as otherwise we'd be back in the same boat
around CNAMEs at the zone apex.  At least for the CDN use-case, once a
non-trivial amount of information shows up in the rrtype, it likely needs
to be managed by the CDN.  Having "_443._https.example.com" means it can be
a CNAME'd whereas if was a record on "example.com" we'd be back in the same
boat.

The underscore labels also provide the ability to have multiple services on
the same hostname.

I haven't fully thought it through, but perhaps there is a better way to
support underscore labels and wildcards in a way that only authorities need
to worry about?  For example, allowing for "_443._https.*" records in an "
example.com" zone in a way that authorities could know how to handle?

      Erik