[DNSOP] HTTP dns-alt-svc draft

In other threads, Erik Nygren suggested that we review the proposed DNS record for HTTP Alternative Services draft: https://tools.ietf.org/html/draft-schwartz-httpbis-dns-alt-svc-02 (You might also want to read RFC7838 for background). This is an effort from people in the HTTP community.

Re: [DNSOP] DNS cookies and multi-vendor anycast incompatibility

On Fri, Jun 22, 2018 at 10:26:55PM -0400, Warren Kumari wrote: > I have not tried configuring cookie on Knot, but looking > in alg_containers.c, I can configure: > { 0, "FNV-64" }, > { 1, "HMAC-SHA256-64" } > > Under BIND: > cookie-algorithm: > Set the algorithm to be used when generating the serv

Re: [DNSOP] DNS cookies and multi-vendor anycast incompatibility

On Fri, Jun 22, 2018 at 8:29 PM Evan Hunt wrote: > On Thu, Jun 21, 2018 at 11:19:55AM -0400, Warren Kumari wrote: > > There are a number of anycast clusters which run different > > implementations on the same IP. > > Sure, but as long as the algorithm is settable for each server in the > anycast

Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex

On Fri, Jun 22, 2018 at 09:18:25PM -0400, John R Levine wrote: > Like I said, it's a disctinction without a difference. The difference is implememtation complexity, which maybe isn't of concern to you but has been of concern to some people who argued with me about ANAME on this basis early on. Yo

Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex

On Sat, 23 Jun 2018, Evan Hunt wrote: Either way we end up importing all of the failure modes of a recursive server into an authoritative one. I wasn't disagreeing about it being regrettable, I just wanted to nip in the bud any repeat of the argument that the auth server would itself have to be

Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex

On Fri, Jun 22, 2018 at 03:18:43PM -0400, John R Levine wrote: > > Minor clarification here: ANAME doesn't require the authoritative server > > itself to do recursion; it requires it to have access to a reursive > > server. > > I suppose, but that seems to me a distinction without a difference. >

Re: [DNSOP] DNS cookies and multi-vendor anycast incompatibility

On Thu, Jun 21, 2018 at 11:19:55AM -0400, Warren Kumari wrote: > There are a number of anycast clusters which run different > implementations on the same IP. Sure, but as long as the algorithm is settable for each server in the anycast so that all of them can match, then I don't think it matters i

Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex

神明達哉 wrote: At Fri, 22 Jun 2018 16:00:51 -0400, Paul Vixie wrote: ... Either way we end up importing all of the failure modes of a recursive server into an authoritative one. +1. authority servers cannot be coerce-able into doing work, whether it's computation, memory allocation, or external

Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex

We do what we should have done from the very beginning and have a rdata type that combines A and records. Master servers automatically generate the type and sign it from the A and resets. Address family is determined from the rdata length. We have a EDNS option that tells the recur

Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex

At Fri, 22 Jun 2018 16:00:51 -0400, Paul Vixie wrote: > >> Minor clarification here: ANAME doesn't require the authoritative server > >> itself to do recursion; it requires it to have access to a reursive > >> server. > > > > I suppose, but that seems to me a distinction without a difference. > >

Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex

The problem with SRV (and MX) is that you can’t tell what an empty additional section means. (By “you” I mean anything in the resolver chain: app, stub, recursor, etc.) If the records are missing, does that mean there aren’t any? Does it mean they were not cached? Does it mean the server c

[DNSOP] Working Group Last Call on draft-ietf-dnsop-terminology-bis

Colleagues, This begins the working group last call for draft-ietf-dnsop-terminology-bis-10, "DNS Terminology”. The document has gotten significant feedback and the editors have worked hard to document current terminology usage, both among practitioners and for broader audiences; we’d like to

Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex

John R Levine wrote: On Fri, 22 Jun 2018, Evan Hunt wrote: Minor clarification here: ANAME doesn't require the authoritative server itself to do recursion; it requires it to have access to a reursive server. I suppose, but that seems to me a distinction without a difference. Either way we e

Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex

On Fri, Jun 22, 2018 at 3:27 PM Warren Kumari wrote: > On Fri, Jun 22, 2018 at 3:13 PM Mukund Sivaraman wrote: > >> >> With additional-from-cache (default on), BIND will return address of >> target of SRV if it is already in cache. The second RTT will get >> amortized. It won't take a lot to mak

Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex

On Fri, Jun 22, 2018 at 3:13 PM Mukund Sivaraman wrote: > On Fri, Jun 22, 2018 at 03:02:35PM -0400, Warren Kumari wrote: > > On Fri, Jun 22, 2018 at 8:57 AM Joe Abley wrote: > > > > > On 19 Jun 2018, at 17:03, Ray Bellis wrote: > > > > > > > On 19/06/2018 17:44, Tony Finch wrote: > > > > > > >

Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex

On Fri, 22 Jun 2018, Evan Hunt wrote: specified version of ANAME, and it avoids the ANAME ugliness of making authoritative servers do recursive lookups. Minor clarification here: ANAME doesn't require the authoritative server itself to do recursion; it requires it to have access to a reursive s

Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex

On Fri, Jun 22, 2018 at 03:02:35PM -0400, Warren Kumari wrote: > On Fri, Jun 22, 2018 at 8:57 AM Joe Abley wrote: > > > On 19 Jun 2018, at 17:03, Ray Bellis wrote: > > > > > On 19/06/2018 17:44, Tony Finch wrote: > > > > > >> SRV should have been part of the fix (and it was invented early > > >>

Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex

On Fri, Jun 22, 2018 at 8:57 AM Joe Abley wrote: > On 19 Jun 2018, at 17:03, Ray Bellis wrote: > > > On 19/06/2018 17:44, Tony Finch wrote: > > > >> SRV should have been part of the fix (and it was invented early > >> enough to be!) but it wasn't a complete fix without support from the > >> appl

Re: [DNSOP] SIG(0) useful (and used?)

On Wed, Jun 20, 2018 at 10:05:54AM +0100, Tony Finch wrote: > I think the problem is it isn't a complete implementation: you can't use > SIG(0) in all the places you can use TSIG. The TKEY support seems to be > specific to Kerberos, whereas broader support would make it a neat way to > use slow SIG

Re: [DNSOP] SIG(0) useful (and used?)

On Fri, Jun 22, 2018 at 9:48 AM Ted Lemon wrote: > It seems to me that the main benefit of SIG(0) is not securing connections > between resolvers and caches, but in securing DNS updates and other > transfers where you need authentication+authorization. In the case where > you just need authenti

Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex

On Tue, Jun 19, 2018 at 03:02:12PM -0400, John Levine wrote: > Agreed but it doesn't seem all that much less work than a well > specified version of ANAME, and it avoids the ANAME ugliness of making > authoritative servers do recursive lookups. Minor clarification here: ANAME doesn't require the a

Re: [DNSOP] 2nd Working Group Last Call for: draft-ietf-dnsop-kskroll-sentinel

Hi Benno, On 22 Jun 2018, at 11:04, Benno Overeinder wrote: > This starts a *one* week Working Group Last Call process, and ends on: > 23:59 29 June 2018. Which timezone? Seems odd to specify a timestamp with minute-accuracy without specifying the hour :-) === General I have read draft-ietf-

Re: [DNSOP] SIG(0) useful (and used?)

On Fri, Jun 22, 2018 at 12:05 PM Tom Pusateri wrote: > What’s the point of using DNS to look up a KEY RR to verify a signature if > you can’t trust the KEY? The KEY resides in the senders zone so no > relationship with a resolver will help you here. > Yeah, this is a limitation in the SIG(0) spe

[DNSOP] 2nd Working Group Last Call for: draft-ietf-dnsop-kskroll-sentinel

After the WG last call for the kskroll-sentinel draft, a number of issues were discussed and settled. The co-chairs want to announce a second WG last call of *one* week. We think the document is ready, but we want to give the working group the opportunity for a final reading. This starts a Work

Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt

On Wed, Jun 20, 2018 at 9:15 PM Shumon Huque wrote: > On Tue, Jun 19, 2018 at 7:15 PM Mukund Sivaraman wrote: > >> >> There also seems to be a scalability problem with SIG(0) in that >> generating the signature involves a public-key operation per DNS >> message. >> >> For a zone transfer of the

Re: [DNSOP] SIG(0) useful (and used?)

It seems to me that the main benefit of SIG(0) is not securing connections between resolvers and caches, but in securing DNS updates and other transfers where you need authentication+authorization. In the case where you just need authentication, we already have DNSSEC. I _guess_ Warren's use ca

Re: [DNSOP] SIG(0) useful (and used?)

On 06/22/2018 12:27 AM, Ted Lemon wrote: > Thanks. In the case where a zone isn’t signed but the authoritative > server supports SIG(0), the response could be verified that it > includes exactly what the server sent. But the KEY would need to be > DNSSEC validated or it probably can’t be trusted to

Re: [DNSOP] DNS cookies and multi-vendor anycast incompatibility

On 06/21/2018 05:09 PM, Mark Andrews wrote: > >> On 21 Jun 2018, at 5:21 pm, Daniel Salzman wrote: >> >> Hello Mark, >> >> On 06/20/2018 11:01 PM, Mark Andrews wrote: >>> On 21 Jun 2018, at 12:25 am, Petr Špaček wrote: On 20.6.2018 16:10, Paul Wouters wrote: > On Wed, 20 Jun

Re: [DNSOP] DNS cookies and multi-vendor anycast incompatibility

Hello Mark, On 06/20/2018 11:01 PM, Mark Andrews wrote: > >> On 21 Jun 2018, at 12:25 am, Petr Špaček wrote: >> >> On 20.6.2018 16:10, Paul Wouters wrote: >>> On Wed, 20 Jun 2018, Petr Špaček wrote: >>> it seems that current specification of DNS cookies in RFC 7873 is not detailed enou

Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex

On 19 Jun 2018, at 17:03, Ray Bellis wrote: > On 19/06/2018 17:44, Tony Finch wrote: > >> SRV should have been part of the fix (and it was invented early >> enough to be!) but it wasn't a complete fix without support from the >> application protocols. > > AIUI, a large part of the supposed issu

Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt

On 21.6.2018 22:31, Hugo Salgado-Hernández wrote: > On 22:09 21/06, Shane Kerr wrote: >>> Dne 1.6.2018 v 12:51 Shane Kerr napsal(a): >>> >>> Hmm, can you share some details about your experience? >>> Did you find out when the data corruption took place? >>> a) network transfer >>> b) implementation

Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt

On 21.6.2018 18:46, Shumon Huque wrote: > On Thu, Jun 21, 2018 at 2:19 AM Petr Špaček > wrote: > > > HTTPS over TLS is what we did for root zone import into Knot Resolver's > cache (from version 2.3 onwards but beware, there are little bugs which > were fix