Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-attrleaf

On 7/6/2018 8:22 AM, Stephane Bortzmeyer wrote: Editorial: I would prefer all occurrences of "right-most" to be replaced by "most general", to emphasize that it is not the position which matters, it is the closeness to the root. Editorial: 'that is they are the "top" of a DNS branch, under a

Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-attrleaf-fix

On 6/28/2018 12:02 PM, Paul Hoffman wrote: On 28 Jun 2018, at 7:19, Dave Crocker wrote: On 6/27/2018 3:01 PM, Paul Hoffman wrote: Due to its nature, the document is a bit difficult to read, but I don't have any suggestion about how to make it better. Could you at least provide some

Re: [DNSOP] SRV and HTTP

> On 12 Jul 2018, at 10:48 am, Nico Williams wrote: > > 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

Re: [DNSOP] SRV and HTTP

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 > >

Re: [DNSOP] SRV and HTTP

> On 12 Jul 2018, at 7:24 am, Nico Williams wrote: > >>> On 11 Jul 2018, at 11:30 am, Mark Andrews wrote: >>> > On 11 Jul 2018, at 3:55 am, Joe Abley wrote: > > *cups hand to ear* > > Was that the sound of a distant desire to specify use of SRV for > HTTP? >>> >>>

Re: [DNSOP] [Doh] SRV and HTTP

I'm in, but will need to catch up on the convo... I'll do so. BTW, don't look at the Yelp/Foursquare reviews for the social venue... yikes On Tue, Jul 10, 2018 at 9:32 PM Mark Nottingham wrote: > I didn't find those, but I found many others. > > I'll start collecting. How about Tuesday, say

Re: [DNSOP] SRV and HTTP

> > On 11 Jul 2018, at 11:30 am, Mark Andrews wrote: > > > > > > On 11 Jul 2018, at 3:55 am, Joe Abley 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. > >

Re: [DNSOP] [Doh] [Driu] Resolverless DNS Side Meeting in Montreal

But it's not necessarily the CDN that's generating the signed records in the general case. You're wanting proof that the customer's domain is pointed to that CDN, so it's signed by whoever manages the DNS infrastructure instead. That could be one of the CDNs, or the customer's operations

Re: [DNSOP] SRV and HTTP

On 11 Jul 2018, at 8:21, Mark Andrews wrote: > As for lib curl, there is not a RFC that says to lookup SRV records for HTTP > or HTTPS. Agree, and I have wanted it to be part of HTTP/2, or at least resolve this mess, but it did not happen. This is my recurring discussion with Daniel when we

Re: [DNSOP] SRV and HTTP

> On Jul 10, 2018, at 7:22 PM, Mark Nottingham wrote: > > > >> On 11 Jul 2018, at 3:55 am, Joe Abley wrote: >> >> On Jul 10, 2018, at 18:02, Adam Roach wrote: >> >>> In large part because DNS provides "a richer scheme that accommodates >>> address families and multiple addresses with

Re: [DNSOP] [Ext] Re: [Doh] [Driu] Resolverless DNS Side Meeting in Montreal

I caught wind of this in my DNSOP folder...(cutting down the reply a *little* bit) On 7/11/18, 04:23, "DNSOP on behalf of Petr Špaček" wrote: > On 10.7.2018 20:57, Ryan Sleevi wrote: > > > > > > On Tue, Jul 10, 2018 at 2:09 PM, Mike Bishop> > wrote:

Re: [DNSOP] [Doh] [Driu] Resolverless DNS Side Meeting in Montreal

On 10.7.2018 20:57, Ryan Sleevi wrote: > > > On Tue, Jul 10, 2018 at 2:09 PM, Mike Bishop > wrote: > > Yes, the multi-CDN case is the scariest aspect of coalescing and the > various DNS tricks we’ve been doing in recent years.  The server may > not be

Re: [DNSOP] SRV and HTTP

> On 11 Jul 2018, at 3:53 pm, Patrik Fältström 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