Re: [DNSOP] draft-ietf-dnsop-serve-stale: returning stale answers when faced with SERVFAIL responses

On Thu, Jul 4, 2019 at 12:12 PM Dave Lawrence wrote: > > Paul Hoffman writes: > >However, implementations MUST NOT send stale data if they have received > >any answer from an authoritative server. > > I personally strongly disagree with this. > > ServFail is a signal from the authoritative

Re: [DNSOP] draft-ietf-dnsop-serve-stale: lightly-suggested ranges

On Thu, Jul 4, 2019 at 1:08 PM Warren Kumari wrote: > > On Thu, Jul 4, 2019 at 12:22 PM Dave Lawrence wrote: > > > > Paul Hoffman writes: > > > Greetings again. draft-ietf-dnsop-serve-stale has a few places where > > > it suggest ranges for values, but these suggestions are vague. > > > > "Vague"

Re: [DNSOP] draft-ietf-dnsop-serve-stale: lightly-suggested ranges

On Thu, Jul 4, 2019 at 12:22 PM Dave Lawrence wrote: > > Paul Hoffman writes: > > Greetings again. draft-ietf-dnsop-serve-stale has a few places where > > it suggest ranges for values, but these suggestions are vague. > > "Vague"? They give hard numbers with the intended flexibility for the > con

Re: [DNSOP] draft-ietf-dnsop-serve-stale: lightly-suggested ranges

Paul Hoffman writes: > Greetings again. draft-ietf-dnsop-serve-stale has a few places where > it suggest ranges for values, but these suggestions are vague. "Vague"? They give hard numbers with the intended flexibility for the considerations that might go into them. > Could be: > Values SH

Re: [DNSOP] draft-ietf-dnsop-serve-stale: returning stale answers when faced with SERVFAIL responses

Paul Hoffman writes: >However, implementations MUST NOT send stale data if they have received >any answer from an authoritative server. I personally strongly disagree with this. ServFail is a signal from the authoritative operator that something is amiss, and is in practical terms is not

Re: [DNSOP] ANAME loop detection

On 7/4/19 5:39 PM, Matthew Pounsett wrote: > > > On Thu, 4 Jul 2019 at 10:54, Matthijs Mekking > wrote: > > Matthew, > > > I would say they should rely on that.  Why shouldn't they?  Isn't our > > goal to get downstream servers to adopt the extensio

Re: [DNSOP] ANAME loop detection

On Thu, 4 Jul 2019 at 10:54, Matthijs Mekking wrote: > Matthew, > > > I would say they should rely on that. Why shouldn't they? Isn't our > > goal to get downstream servers to adopt the extension and do their own > > lookup? The server-side lookups and sibling records are bolt-ons to > > handl

Re: [DNSOP] ANAME loop detection

Jan Včelák wrote: > > 2. QTYPE=ANAME: According to the current version of the draft, server > answering to ANAME must include the ANAME and should include the > sibling records. Let's modify the behavior and say the server should > not (must not) include the sibling records. Then the server perfor

Re: [DNSOP] ANAME loop detection

Matthew, On 7/4/19 2:32 PM, Matthew Pounsett wrote: > > > On Thu, 4 Jul 2019 at 05:54, Matthijs Mekking > wrote: > > > > > 1. EDNS "do not follow ANAME" option: The requester would indicate > > that it is capable of following ANAME and that the server

Re: [DNSOP] [Ext] Request for adoption: draft-sah-resolver-information

On Thu, 4 Jul 2019, Paul Hoffman wrote: Can you say more about what you mean? Is it a prediction, or a measurement, or a mixture, or something else? A prediction based on current measurements. Seriously, I'd love to be shown to be wrong in the future. We needed this for the freeswan project

Re: [DNSOP] [Ext] Request for adoption: draft-sah-resolver-information

On Jul 3, 2019, at 7:13 PM, Joe Abley wrote: > On Jul 3, 2019, at 20:40, Paul Hoffman wrote: > >> If we want DNSSEC signing, we have to use the DNS reverse tree for the >> names, even though only a tiny percent of that tree will be signed. > > Aside from those parts of the in-addr.arpa and ip6

Re: [DNSOP] ANAME loop detection

Shane, On 7/4/19 2:29 PM, Shane Kerr wrote: >>> 2. QTYPE=ANAME: According to the current version of the draft, server >>> answering to ANAME must include the ANAME and should include the >>> sibling records. Let's modify the behavior and say the server should >>> not (must not) include the sibling

Re: [DNSOP] [Ext] Request for adoption: draft-sah-resolver-information

Moin! On 4 Jul 2019, at 2:40, Paul Hoffman wrote: I don't see the parallel with RFC 8484. We cannot force resolver vendors to care enough about announcing information about themselves to use either protocol. And we certainly cannot tell applications how to search for information. We can, howev

Re: [DNSOP] ANAME loop detection

On Thu, 4 Jul 2019 at 05:54, Matthijs Mekking wrote: > > > > 1. EDNS "do not follow ANAME" option: The requester would indicate > > that it is capable of following ANAME and that the server receiving > > the query should not include the ANAME sibling address records. The > > loop detection would

Re: [DNSOP] ANAME loop detection

Matthijs, On 04/07/2019 11.54, Matthijs Mekking wrote: I like something like option 2 the best, I'll react to your options below. I like something like option 1. Details below as well. 😊 On 7/4/19 11:37 AM, Jan Včelák wrote: Hello. [ ... ] We had been thinking about how this could be f

Re: [DNSOP] ANAME loop detection

Jan, I like something like option 2 the best, I'll react to your options below. On 7/4/19 11:37 AM, Jan Včelák wrote: > Hello. > [ ... ] > We had been thinking about how this could be fixed and here is what we > have came with: > > 1. EDNS "do not follow ANAME" option: The requester would indi

[DNSOP] ANAME loop detection

Hello. I would like to resurrect the discussion about ANAME loops handling and detection. I attempted to write a discussion section on this topic for draft-ietf-dnsop-aname [https://github.com/each/draft-aname/pull/70] and we also talked about this a little off-list with Shane and Matthijs. If yo