Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

[Vladimír Čunát]

On 11/14/19 12:05 AM, Viktor Dukhovni wrote:
> It'd be a shame (though admittedly not frequent) to have a resolver
> retry over TCP just to get the same answer with additional information
> it does not need and perhaps does not even understand.

EDE codes themselves take very little space, so truncating just the
textual messages might be a good middle-ground but I certainly
haven't tried thinking of all implications on EDE truncation yet. 
Communicating these through bit(s) in EDE or EDNS flags might be nice,
and clients might even use them to set their preference.

Still, ATM I can't clearly see whether such TC details would be useful
in practice.  I think we're fortunate that most use cases for EDE are
failures... so the answer will probably be tiny.

--Vladimir

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

[Viktor Dukhovni]

> On Nov 13, 2019, at 5:50 PM, Wes Hardaker  wrote:
> 
>>> I added this text to the next version:
>>> 
>>> When the response grows beyond the requestor's UDP payload
>>> size , servers SHOULD truncate messages
>>> by dropping EDE options before dropping other data from
>>> packets.  Implementations SHOULD set the truncation bit when
>>> dropping EDE options.
>> 
>> Are you sure that setting TC=1 when EDE doesn't fit is the right
>> trade-off?  I'm somewhat skeptical...
> 
> Well, that's what the other specs say.  We could break from that, you're
> right, and it's a discussion I was going to mention in Singapore for
> that matter.

A colleague suggested that would could use another bit (from the EDNS
flags field, say bit 14 adjacent to DO) to signal that non-essential
diagnostic information was left out.  Resolvers can then choose to
retry over TCP only if they deem it important to retrieve and use
EDE information.

It'd be a shame (though admittedly not frequent) to have a resolver
retry over TCP just to get the same answer with additional information
it does not need and perhaps does not even understand.

Of course this only matters in the rare (when not specifically elicited
by carefully crafted queries) case that it is the EDE options that push
the packet over the UDP size limit, and the rest of the payload would
otherwise just fit.  Perhaps on that basis the extra bit is not warranted.
We could just say that EDE can be silently dropped, or could leave the
text as proposed, with EDE occasionally eliciting "avoidable" TCP retries.

-- 
Viktor.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

[Wes Hardaker]

Viktor Dukhovni  writes:

> > On Nov 13, 2019, at 12:56 PM, Wes Hardaker  wrote:
> > 
> > I added this text to the next version:
> > 
> >  When the response grows beyond the requestor's UDP payload
> >  size , servers SHOULD truncate messages
> >  by dropping EDE options before dropping other data from
> >  packets.  Implementations SHOULD set the truncation bit when
> >  dropping EDE options.
> 
> Are you sure that setting TC=1 when EDE doesn't fit is the right
> trade-off?  I'm somewhat skeptical...

Well, that's what the other specs say.  We could break from that, you're
right, and it's a discussion I was going to mention in Singapore for
that matter.
-- 
Wes Hardaker
USC/ISI

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

[Viktor Dukhovni]

> On Nov 13, 2019, at 12:56 PM, Wes Hardaker  wrote:
> 
> I added this text to the next version:
> 
>  When the response grows beyond the requestor's UDP payload
>  size , servers SHOULD truncate messages
>  by dropping EDE options before dropping other data from
>  packets.  Implementations SHOULD set the truncation bit when
>  dropping EDE options.

Are you sure that setting TC=1 when EDE doesn't fit is the right
trade-off?  I'm somewhat skeptical...

-- 
Viktor.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

[Wes Hardaker]

Puneet Sood  writes:

> Independent of the decision on EDE forwarding and caching, the I-D
> needs to have some guidance for it [truncation]. The EXTRA-TEXT field
> may be obtained from configuration and it is possible that the
> resulting DNS message will exceed UDP message size limit in the
> request.

I added this text to the next version:

  When the response grows beyond the requestor's UDP payload
  size , servers SHOULD truncate messages
  by dropping EDE options before dropping other data from
  packets.  Implementations SHOULD set the truncation bit when
  dropping EDE options.

(and we'll have a forwarding discussion in Singapore)

> > * 14.5.0.4 NOCHANGE 5. Security Considerations
> >
> >   Para 2: "This information is unauthenticated information, and an
> >  attacker (e.g a MITM or malicious recursive server) could insert an
> >  extended error response into already untrusted data ..."  Comment:
> >  Agree with some other comments that this is not relevant since no
> >  action is expected to be taken based on EDEs.  Comment: There are
> >  ideas in the thread to have links to info in the EXTRA-TEXT and
> >  possibly display it to users. I guess the usual warnings to not
> >  click on potentially unsafe links apply.
> >
> >   + Yeah, it really would be remiss to leave out that point.  There may
> > be nothing we can do, but the whole point of a security
> > consideration is to properly disclose any known threats/issues.
>
> I do not see text mentioning this.

I think we're miscommunicating.  Can you propose concrete text changes?
-- 
Wes Hardaker
USC/ISI

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

[Wes Hardaker]

"Jan Komissar (jkomissa)"  writes:
> In section 2, Extended DNS Error EDNS0 option format, it states that
> the OPTION-LENGTH should be “4 + the length of the EXTRA-TEXT section…
> .” This appears to be a remnant from when the option included a flag
> word. I think it should be changed to “2 + the length of the
> EXTRA-TEXT field… .” I also changed “EXTRA-TEXT section” to
> “EXTRA-TEXT field,” since the draft call these items “fields.”

Thanks.  Fixed!
-- 
Wes Hardaker
USC/ISI

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

[Petr Špaček]

On 31. 10. 19 20:08, Eric Orth wrote:
> On Fri, Oct 25, 2019 at 9:29 AM Petr Špaček  > wrote:
> 
> Would it be possible to get some time allocation of your UX design folks, 
> before we set the protocol in stone?
> 
> 
> Not likely, unfortunately.  Downside of not having specific plans yet.  Makes 
> it difficult to allocate UX experts.
> 
> - Is the current version with "no categorization" okay?
> - Will it be okay in future if dnsop starts adding new codes?
> - Or should we add some inherent categorization into the protocol to make 
> it future-proof?
> - If a categorization is needed, what form is best for UX? (please 
> suggest!)
> 
> 
> Speaking for myself from a non-UX perspective (and I am not a UX expert), 
> forward compatibility of error codes is a common pitfall in many similar 
> systems.  Once error receivers start relying on specific error codes to 
> produce specific essential behavior, expandability often gets locked out 
> because you can't replace those codes with new ones that receivers might not 
> immediately recognize.  And having a receiver only know "unknown" error is 
> usually pretty bad.  Attempts to solve these issues usually involve stuff 
> like categorization, user-visible messages, and multiple ordered errors, but 
> my anecdotal experience is that it's pretty rare for such mitigations to be 
> fully supported by all sides to the level where it actually helps and 
> expandability still ends up limited.
> 
> But specifically to EDE, I think the general circumstances make us fine 
> without taking any specific steps to mitigate forward compatibility.  It's 
> mostly been designed just for "supplemental" signalling.  And at least for 
> the general use cases, eg browsers, I doubt enough recursives will ever (or 
> be able to) support it for the stub to rely on receiving a recognized EDE.  
> It will always need to be a nice-to-have with the receiver able to provide 
> good behavior if no EDE (or an unrecognized new EDE) is received.
> 
> So no, I don't think categorization is necessary to make EDE useful.  In 
> fact, I think it would probably make things more complicated than necessary.

Thanks!

Based on this feedback I'm dropping my former request to build categorization 
into the protocol, so the "flags" field can rest in peace.

Thanks everyone for patience with me. Let's move to the forwarding question! :-)

-- 
Petr Špaček  @  CZ.NIC

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

[Petr Špaček]

On 24. 10. 19 19:56, Warren Kumari wrote:
> On Tue, Oct 22, 2019 at 6:49 AM Tony Finch  wrote:
>>
>> Petr Špaček  wrote:
>>>
>>> 2. Second problem is that it is uncelar if there is going to be a
>>> consumer: Did *anyone* from stub resolvers said a word about this draft?
>>> Is it useful as it is?
>>
>> I expect almost no-one can do anything with EDE without
>> getaddrinfo() EAI_ return code extensions.
>>
> 
> I would personally find this to useful if only dig (or drill or delve
> or...) supported this -- it's currently hard to actually debug weird
> DNS failures, and simply providing information to a human using
> diagnostic tools would be helpful.
> This and the "DNSSEC bogus -> ask another resolver" are to my mind the
> primary uses...

In my personal experience most of "hard to debug errors" involve forwarding 
(because lack of visibility into forwarding chain), so I do not see 
extended-errors being super useful in its current form.

As a result, from my perspective exposing EDE information only in dig (and 
other tools for geeks) *does not* justify the investment needed on resolver 
side.

On the other hand, *if the information is exposed to end-users* in a form which 
actually helps to direct complains from users to appropriate places, then the 
cost/benefit situation is completely different and I'm all for it!

-- 
Petr Špaček  @  CZ.NIC

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

[Petr Špaček]

On 24. 10. 19 19:24, Eric Orth wrote:
> On Tue, Oct 22, 2019 at 6:49 AM Tony Finch  > wrote:
> 
> I expect almost no-one can do anything with EDE without
> getaddrinfo() EAI_ return code extensions.
> 
>  
> In many cases, especially when DoH is in use, Chrome uses its own built-in 
> stub resolver.  So EDE is certainly a reasonable option for us without any 
> changes to getaddrinfo().
> 
> On Mon, Oct 21, 2019 at 1:48 PM Petr Špaček  > wrote:
> 
> 2. Second problem is that it is uncelar if there is going to be a 
> consumer: Did *anyone* from stub resolvers said a word about this draft? Is 
> it useful as it is? Is there an experimental implementation in stub to 
> consume this information?
> dnsop has history of tweaks which never get used by stubs, and this draft 
> in particular is very expensive to implement in resolver code.
> 
>  
> Chrome DNS has no specific plans decided for EDE yet.  But we do think it's 
> generally a good idea and are looking forward to it.  I don't have any 
> implementation-ability concerns with the current draft.

Excellent, I'm glad to hear that!

This draft creates a new registry with info-codes, and content of the registry 
is very geeky, so it seems necessary to somehow map error codes to categories 
which can be communnicated to users in terms of "a random web browser user".

Would it be possible to get some time allocation of your UX design folks, 
before we set the protocol in stone?


This draft evolved several times when it comes to error categorization, and I 
believe we will never know if we (= dnsop geeks) got the categorization right 
until someone attempts to design UX for it.

History of draft-ietf-dnsop-extended-error:
- version 00 - categorization by FLAG
- version 01 - categorization by FLAG + RCODE
- version 07 - no categorization at all

There were other proposals for categorization which did not appear in draft 
text:
- Shane Kerr - HTTP-like categorization like 1xx, 2xx, 3xx, ...
https://mailarchive.ietf.org/arch/msg/dnsop/DMtP4XuqN132Jxt8O0BTZPFsokg

- Petr Spacek (me) - dichotomy local (near) error vs. remote (far) end error
https://mailarchive.ietf.org/arch/msg/dnsop/b3wtVj_aWm24PXyHr1M9NMj3LJ0

It would be super helpful if an experienced UX designer can have look at give 
back feedback:

- Is the current version with "no categorization" okay?
- Will it be okay in future if dnsop starts adding new codes?
- Or should we add some inherent categorization into the protocol to make it 
future-proof?
- If a categorization is needed, what form is best for UX? (please suggest!)

Thank you very much for your time!

-- 
Petr Špaček  @  CZ.NIC

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

[Jan Komissar (jkomissa)]

Hi,

I realize I’m late to this, but this should probably be fixed:

In section 2, Extended DNS Error EDNS0 option format, it states that the 
OPTION-LENGTH should be “4 + the length of the EXTRA-TEXT section… .” This 
appears to be a remnant from when the option included a flag word. I think it 
should be changed to “2 + the length of the EXTRA-TEXT field… .” I also changed 
“EXTRA-TEXT section” to “EXTRA-TEXT field,” since the draft call these items 
“fields.”

Otherwise, I approve of draft.

Thanks,

Jan.

From: DNSOP  on behalf of Tim Wicinski 

Date: Thursday, September 12, 2019 at 9:52 AM
To: dnsop 
Subject: [DNSOP] Second Working Group Last Call for 
draft-ietf-dnsop-extended-error

All

We had such great comments the first time we did a Working Group
Last Call for draft-ietf-dnsop-extended-error, that the chairs decided
a second one would be even better.

Before we start, a few comments:

- Viktor's comments from 11 September will be rolled into the WGLC
  comments, which means I'll be tracking them with the authors.

- The chairs are not doing to add more codes to the IANA registry
  in the document.  However, the process is laid out in section 5.2,
  with three different ranges (Expert Review; First Come, First Serve;
  and Experimental).

- We're pretty sure all comments have been addressed one way or another,
  but we still may have missed some.  Please speak up if that is the case.


This starts a Working Group Last Call for draft-ietf-dnsop-extended-error

Current versions of the draft is available here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-extended-error/

The Current Intended Status of this document is: Standards Track

Please review the draft and offer relevant comments.
If this does not seem appropriate please speak out.
If someone feels the document is *not* ready for publication, please speak out 
with your reasons.

This starts a two week Working Group Last Call process, and ends on:  26 
September 2019.

thanks
tim
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

[Warren Kumari]

On Tue, Oct 22, 2019 at 6:49 AM Tony Finch  wrote:
>
> Petr Špaček  wrote:
> >
> > 2. Second problem is that it is uncelar if there is going to be a
> > consumer: Did *anyone* from stub resolvers said a word about this draft?
> > Is it useful as it is?
>
> I expect almost no-one can do anything with EDE without
> getaddrinfo() EAI_ return code extensions.
>

I would personally find this to useful if only dig (or drill or delve
or...) supported this -- it's currently hard to actually debug weird
DNS failures, and simply providing information to a human using
diagnostic tools would be helpful.
This and the "DNSSEC bogus -> ask another resolver" are to my mind the
primary uses...
W

> Tony.
> --
> f.anthony.n.finchhttp://dotat.at/
> Plymouth: Variable 4 or less. Smooth or slight, occasionally moderate later in
> west. Mainly fair. Good.___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

[Patrick McManus]

extended codes are pretty important in the DoH space - which doesn't
require library intermediaries. IIRC the very important use case was
disambiguating DNSSEC validation errors from other errors (as retry
behavior could very well be different). So this has been eagerly
anticipated.

On Tue, Oct 22, 2019 at 6:49 AM Tony Finch  wrote:

> Petr Špaček  wrote:
> >
> > 2. Second problem is that it is uncelar if there is going to be a
> > consumer: Did *anyone* from stub resolvers said a word about this draft?
> > Is it useful as it is?
>
> I expect almost no-one can do anything with EDE without
> getaddrinfo() EAI_ return code extensions.
>
> Tony.
> --
> f.anthony.n.finchhttp://dotat.at/
> Plymouth: Variable 4 or less. Smooth or slight, occasionally moderate
> later in
> west. Mainly fair. Good.___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

[Puneet Sood]

On Tue, Oct 22, 2019 at 6:49 AM Tony Finch  wrote:
>
> Petr Špaček  wrote:
> >
> > 2. Second problem is that it is uncelar if there is going to be a
> > consumer: Did *anyone* from stub resolvers said a word about this draft?
> > Is it useful as it is?
>
> I expect almost no-one can do anything with EDE without
> getaddrinfo() EAI_ return code extensions.

At a minimum dig should be able to support it. Does any of the dig
variants have support for EDE yet?

>
> Tony.
> --
> f.anthony.n.finchhttp://dotat.at/
> Plymouth: Variable 4 or less. Smooth or slight, occasionally moderate later in
> west. Mainly fair. Good.___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

[Tony Finch]

Petr Špaček  wrote:
>
> 2. Second problem is that it is uncelar if there is going to be a
> consumer: Did *anyone* from stub resolvers said a word about this draft?
> Is it useful as it is?

I expect almost no-one can do anything with EDE without
getaddrinfo() EAI_ return code extensions.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Plymouth: Variable 4 or less. Smooth or slight, occasionally moderate later in
west. Mainly fair. Good.___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

[Tim Wicinski]

Petr

Thanks for clarifying.  I was going through so many notes, and needed a
check.

1. Forwarding Semantics

Let me think on this one with the authors and chairs.

2. Stub Resolvers.

OK

3. Standards-Track vs Not

That's more than reasonable.

Tim


On Mon, Oct 21, 2019 at 1:48 PM Petr Špaček  wrote:

> On 21. 10. 19 19:18, Tim Wicinski wrote:
> >
> > All
> >
> > The second WGLC period ended, and I needed a bit of time to go over all
> the comments and make sure they were all addressed, and that appears to be
> true.
> >
> > The only thing I see are some comments were raised after the -12
> version.  They've been addressed and can be updated on its way to IETF LC..
> If someone thinks
> > I am incorrect please speak up.
>
> I hate to rain on this parade, but I think the draft in its current form
> has two major problems:
>
> 1. Forwarding semantics is unclear, as was pointed out in
> https://mailarchive.ietf.org/arch/msg/dnsop/PAiQOsYfYQHrL7SeGWZn-jtJrTs
> and elsewhere during WGLC.
>
> Personally I think that omiting forwaring is a major mistake because the
> EDE code is most useful for diagnostics when forwarding is taking place!
>
>
> 2. Second problem is that it is uncelar if there is going to be a
> consumer: Did *anyone* from stub resolvers said a word about this draft? Is
> it useful as it is? Is there an experimental implementation in stub to
> consume this information?
> dnsop has history of tweaks which never get used by stubs, and this draft
> in particular is very expensive to implement in resolver code.
>
>
> Besides technical points above I oppose publishing this as standards-track
> document before it is fully implementated at least once. Previous
> implementation excercise at IETF 104 hackaton uncovered nasty corner cases
> and significantly influenced the draft (removal of rcode field etc.). It
> would be mistake to publish it without re-implementing it again before
> publication, we might find other significant problems.
>
> Thank you.
> Petr Špaček  @  CZ.NIC
>
> >
> > I'll confirm with the authors and finish the shepherd write up
> >
> > Tim
> >
> > On Mon, Sep 30, 2019 at 5:07 PM Wes Hardaker  > wrote:
> >
> > Vittorio Bertola  vittorio.bert...@open-xchange.com>> writes:
> >
> > > > Il 28 settembre 2019 01:41 Wes Hardaker  > ha scritto:
> > > >
> > > >   + Response: Those three codes were supplied in a previous
> comment
> > > > round and they are supposed to indicate policies being
> applied from
> > > > different sources.  Can you check the new text of them to
> see if
> > > > they are more understandable now?
> > >
> > > I think there was an editorial glitch, so now you have two errors
> #17
> > > and no #18 - 3.19 should become #18 again.
> >
> > Yep, fixed.  Thanks.
> >
> > --
> > Wes Hardaker
> > USC/ISI
> >
> >
> > ___
> > DNSOP mailing list
> > DNSOP@ietf.org
> > https://www.ietf.org/mailman/listinfo/dnsop
> >
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

[Petr Špaček]

On 21. 10. 19 19:18, Tim Wicinski wrote:
> 
> All
> 
> The second WGLC period ended, and I needed a bit of time to go over all the 
> comments and make sure they were all addressed, and that appears to be true.
> 
> The only thing I see are some comments were raised after the -12 version.  
> They've been addressed and can be updated on its way to IETF LC.  If someone 
> thinks
> I am incorrect please speak up. 

I hate to rain on this parade, but I think the draft in its current form has 
two major problems:

1. Forwarding semantics is unclear, as was pointed out in
https://mailarchive.ietf.org/arch/msg/dnsop/PAiQOsYfYQHrL7SeGWZn-jtJrTs
and elsewhere during WGLC.

Personally I think that omiting forwaring is a major mistake because the EDE 
code is most useful for diagnostics when forwarding is taking place!


2. Second problem is that it is uncelar if there is going to be a consumer: Did 
*anyone* from stub resolvers said a word about this draft? Is it useful as it 
is? Is there an experimental implementation in stub to consume this information?
dnsop has history of tweaks which never get used by stubs, and this draft in 
particular is very expensive to implement in resolver code.


Besides technical points above I oppose publishing this as standards-track 
document before it is fully implementated at least once. Previous 
implementation excercise at IETF 104 hackaton uncovered nasty corner cases and 
significantly influenced the draft (removal of rcode field etc.). It would be 
mistake to publish it without re-implementing it again before publication, we 
might find other significant problems.

Thank you.
Petr Špaček  @  CZ.NIC

> 
> I'll confirm with the authors and finish the shepherd write up
> 
> Tim
> 
> On Mon, Sep 30, 2019 at 5:07 PM Wes Hardaker  > wrote:
> 
> Vittorio Bertola  > writes:
> 
> > > Il 28 settembre 2019 01:41 Wes Hardaker  > ha scritto:
> > >
> > >   + Response: Those three codes were supplied in a previous comment
> > >     round and they are supposed to indicate policies being applied 
> from
> > >     different sources.  Can you check the new text of them to see if
> > >     they are more understandable now?
> >
> > I think there was an editorial glitch, so now you have two errors #17
> > and no #18 - 3.19 should become #18 again.
> 
> Yep, fixed.  Thanks.
> 
> -- 
> Wes Hardaker
> USC/ISI
> 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

[Tim Wicinski]

All

The second WGLC period ended, and I needed a bit of time to go over all the
comments and make sure they were all addressed, and that appears to be true.

The only thing I see are some comments were raised after the -12 version.
They've been addressed and can be updated on its way to IETF LC.  If
someone thinks
I am incorrect please speak up.

I'll confirm with the authors and finish the shepherd write up

Tim

On Mon, Sep 30, 2019 at 5:07 PM Wes Hardaker  wrote:

> Vittorio Bertola  writes:
>
> > > Il 28 settembre 2019 01:41 Wes Hardaker  ha
> scritto:
> > >
> > >   + Response: Those three codes were supplied in a previous comment
> > > round and they are supposed to indicate policies being applied from
> > > different sources.  Can you check the new text of them to see if
> > > they are more understandable now?
> >
> > I think there was an editorial glitch, so now you have two errors #17
> > and no #18 - 3.19 should become #18 again.
>
> Yep, fixed.  Thanks.
>
> --
> Wes Hardaker
> USC/ISI
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

[Wes Hardaker]

Vittorio Bertola  writes:

> > Il 28 settembre 2019 01:41 Wes Hardaker  ha scritto:
> > 
> >   + Response: Those three codes were supplied in a previous comment
> > round and they are supposed to indicate policies being applied from
> > different sources.  Can you check the new text of them to see if
> > they are more understandable now?
> 
> I think there was an editorial glitch, so now you have two errors #17
> and no #18 - 3.19 should become #18 again.

Yep, fixed.  Thanks.

-- 
Wes Hardaker
USC/ISI

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

[Vittorio Bertola]

> Il 28 settembre 2019 01:41 Wes Hardaker  ha scritto:
> 
>   + Response: Those three codes were supplied in a previous comment
> round and they are supposed to indicate policies being applied from
> different sources.  Can you check the new text of them to see if
> they are more understandable now?

I think there was an editorial glitch, so now you have two errors #17 and no 
#18 - 3.19 should become #18 again. 

Regarding the substance, I think that the text is reasonably clear; especially 
the difference between #15 and #18-aka-3.19 (which was the subject of 
Stephane's comment) is that in #15 the resolver is blocking the specific 
queried name while in #18 the resolver is blocking the specific client, and I 
think that this is still a useful distinction to make.

-- 
 
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bert...@open-xchange.com 
Office @ Via Treviso 12, 10144 Torino, Italy

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

[Wes Hardaker]

"Michael J. Sheldon"  writes:

Thanks Michael,

Thanks for the comments.  Responses are inline below in my tracking
notes below.

14.4 DONE Michael J. Sheldon" 


14.4.1 DONE In section 3.21
---

  3.21.  Extended DNS Error Code 20 - Lame

  An authoritative server that receives a query (with the RD bit clear)
  for a domain for which it is not authoritative SHOULD include this EDE
  code in the SERVFAIL response.  A resolver that receives a query (with
  the RD bit clear) SHOULD include this EDE code in the REFUSED
  response.

  The above case is not consistent with current authoritative server
  behavior.

  The authoritative servers I have tested all return REFUSED, not
  SERVFAIL, regardless of the query RD bit, when the server does not
  allow recursion, and the server is not authoritative for the zone.

  I would change to:


  3.21.  Extended DNS Error Code 20 - Not Authoritative

  An authoritative server that receives a query (with the RD bit clear,
  or when not configured for recursion) for a domain for which it is not
  authoritative SHOULD include this EDE code in the REFUSED response.  A
  resolver that receives a query (with the RD bit clear) SHOULD include
  this EDE code in the REFUSED response.



  IMO, while "lame" is a valid term, quite frankly, it's not nearly as
  clear in meaning as just saying "not authoritative". To me, "lame" is
  at the delegation (referring server), not the targeted server.

  + Response: good catch and I like (and have put in) you replacements.
I've never liked the "lame" name either, as I don't think it's
descriptive to someone that isn't in the inner circle of DNS.

-- 
Wes Hardaker
USC/ISI

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

[Wes Hardaker]

Stephane Bortzmeyer  writes:

Thanks Stephane,

Thanks for the comments.  Responses are inline below in my tracking
notes below.

14.3 DONE Stephane Bortzmeyer
~

  IMHO, the document is good. I like the fact there is no longer a
  limitation of a given EDE to some RCODEs (it makes things simpler).

  Some details, all editorial:


14.3.1 DONE it could be a good idea to add more specific references for the
---

  EDE. For instance, 3 "Stale Answer" could have a reference to
  draft-ietf-dnsop-serve-stale.

  + Rseponse that seems popular; I'll try to do this where I can.


14.3.2 DONE I think that many people will be confused with 15, 16, 17 and 18.
-

  Suggestions:

  * remove 18, which is redundant with 15 (if the user chooses the
  resolver, and he should have the right to do so, 15 and 18 are the
  same). 18 is meaningful only if the user does have a simple way to
  change this behaviour.
  * Add to the definition of 15 "The policy was decided by the server
  administrators"
  * Add to the definition of 16 "This means that the policy was
  not decided by the server administrators, and it is probably useless
  to complain to them".

  + Response: Those three codes were supplied in a previous comment
round and they are supposed to indicate policies being applied from
different sources.  Can you check the new text of them to see if
they are more understandable now?


-- 
Wes Hardaker
USC/ISI

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

[Wes Hardaker]

Puneet Sood  writes:

Hi Puneet,

Thanks for the comments.  Responses are inline below in my tracking
notes below.

14.5 TODO Puneet Sood
~

  I got around to review the draft only recently and have made an
  attempt to avoid points of discussion that have been resolved since
  IETF Prague. Apologies in advance for any duplicates.


* 14.5.0.1 DONE 1. Introduction and background

  Para 2: "A good example of issues that would benefit ..."  Comment:
  The paragraph leads up to the conclusion that the EDE codes will be
  helpful to a client to decide between retry and stopping.  Since the
  consensus is that the EDEs are purely diagnostic, it would be good to
  reiterate that at the end of this paragraph.

  + Response from Viktor: For the record, while that was
  "diagnostic" was my take on the purpose of these codes, reading other
  responses, I am not sure that's yet the consensus view...  I could
  also live with these being actionable, provided the text is then more
  clear on how to do that correctly

  If the actions based on these codes are arbitrary choices for each
  implementation, with not even a clear correspondence with associated
  RCODEs, that feels like too much rope to me...

  Eric Orth's comment from Sept 17 is also relevant here (no one has
  responded to it yet). Quoting the last bullet from his response here
  for reference:
  [https://mailarchive.ietf.org/arch/msg/dnsop/GTg8wa7lQ-VoBFcp_P5tT4VuQhE]
  *Something like "applications MUST NOT act on EDE" or "applications
  MUST NOT change rcode processing" does not seem reasonable to me.  Way
  too unclear what "diagnostic" processing is reasonable and allowed or
  not.  And potentially limits applications from doing processing based
  on very reasonable or obvious interpretations of the received
  rcode/EDE combinations."

  + Response: Paul H. gave us language to put in both the abstract and
introduction to address this.  Let me know if you think it doesn't
address this issue.


* 14.5.0.2 TODO 2. Extended Error EDNS0 option format / forwarding /etc/

  Final para: "The Extended DNS Error (EDE) option can be included in
  any response (SERVFAIL, NXDOMAIN, REFUSED, and even NOERROR, etc) to a
  query that includes OPT Pseudo-RR [RFC6891]. ..."

  Comment: Given the level of discussion around behavior when
  sending/receiving the EDE option, there should be some more text
  giving guidance on behavior.

  a. For recursive resolvers, it may be worth pointing that it is not
  expected to copy/forward EDE values received from authoritative
  nameservers to their clients.  b. What is the expectation on caching
  for the EDE code generated by a recursive resolver in response to a
  query? My expectation is that it will be cached (if the answer itself
  is cached) so the next response has the same EDE code.  c. Truncation:
  In case a response including the EDE option with EXTRA-TEXT filled in
  exceeds the effective UDP payload size, what is the desired behavior
  for the EDE option? Should the EXTRA-TEXT field be left empty in favor
  of filling in other RR types? Should the response be marked truncated
  to require a re-query over TCP?

  This is unlikely for failures but could happen when DNSSEC validation
  could not be performed due to unsupported digest type.

  + Response: good questions, and I think the WG needs to think about
whether to add that much more data.


* 14.5.0.3 DONE 3.14 Extended DNS Error Code 13 - Cached Error

  The resolver has cached SERVFAIL for this query.

  Comment: To match the text the name should be "Cached SERVFAIL".


* 14.5.0.4 NOCHANGE 5. Security Considerations

  Para 2: "This information is unauthenticated information, and an
 attacker (e.g a MITM or malicious recursive server) could insert an
 extended error response into already untrusted data ..."  Comment:
 Agree with some other comments that this is not relevant since no
 action is expected to be taken based on EDEs.  Comment: There are
 ideas in the thread to have links to info in the EXTRA-TEXT and
 possibly display it to users. I guess the usual warnings to not
 click on potentially unsafe links apply.

  + Yeah, it really would be remiss to leave out that point.  There may
be nothing we can do, but the whole point of a security
consideration is to properly disclose any known threats/issues.

  Thanks, Puneet




-- 
Wes Hardaker
USC/ISI

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

[Wes Hardaker]

Loganaden Velvindron  writes:

> I'm ok with the latest revision.

Awesome, thanks!

> Just a small request: John Todd from quad9 sent his feedback, so it's
> fair to credit him in the next revision of the draft.

Yep, fixed.  Thanks for that.
-- 
Wes Hardaker
USC/ISI

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

[Viktor Dukhovni]

> On Sep 20, 2019, at 5:17 PM, Puneet Sood  wrote:
> 
> Since the consensus is that the EDEs are purely diagnostic, it would
> be good to reiterate that at the end of this paragraph.

For the record, while that was "diagnostic" was my take on the purpose
of these codes, reading other responses, I am not sure that's yet the
consensus view...  I could also live with these being actionable,
provided the text is then more clear on how to do that correctly.

If the actions based on these codes are arbitrary choices for each
implementation, with not even a clear correspondence with associated
RCODEs, that feels like too much rope to me...

-- 
Viktor.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

[Michael J. Sheldon]

In section 3.21

3.21.  Extended DNS Error Code 20 - Lame

   An authoritative server that receives a query (with the RD bit clear)
   for a domain for which it is not authoritative SHOULD include this
   EDE code in the SERVFAIL response.  A resolver that receives a query
   (with the RD bit clear) SHOULD include this EDE code in the REFUSED
   response.

The above case is not consistent with current authoritative server behavior.

The authoritative servers I have tested all return REFUSED, not
SERVFAIL, regardless of the query RD bit, when the server does not allow
recursion, and the server is not authoritative for the zone.

I would change to:

3.21.  Extended DNS Error Code 20 - Not Authoritative

   An authoritative server that receives a query (with the RD bit clear,
   or when not configured for recursion) for a domain for which it is
   not authoritative SHOULD include this EDE code in the REFUSED
   response.  A resolver that receives a query (with the RD bit clear)
   SHOULD include this EDE code in the REFUSED response.



IMO, while "lame" is a valid term, quite frankly, it's not nearly as
clear in meaning as just saying "not authoritative". To me, "lame" is at
the delegation (referring server), not the targeted server.


-- 
Michael Sheldon
Dev-DNS Services
GoDaddy.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

[Stephane Bortzmeyer]

On Thu, Sep 12, 2019 at 09:51:25AM -0400,
 Tim Wicinski  wrote 
 a message of 90 lines which said:

> We had such great comments the first time we did a Working Group
> Last Call for draft-ietf-dnsop-extended-error, that the chairs
> decided a second one would be even better.

IMHO, the document is good. I like the fact there is no longer a
limitation of a given EDE to some RCODEs (it makes things simpler).

Some details, all editorial:

* it could be a good idea to add more specific references for the
EDE. For instance, 3 "Stale Answer" could have a reference to
draft-ietf-dnsop-serve-stale.

* I think that many people will be confused with 15, 16, 17 and 18.
Suggestions:
  * remove 18, which is redundant with 15 (if the user chooses the
  resolver, and he should have the right to do so, 15 and 18 are the
  same). 18 is meaningful only if the user does have a simple way to
  change this behaviour.
  * Add to the definition of 15 "The policy was decided by the server 
administrators"
  * Add to the definition of 16 "This means that the policy was
  not decided by the server administrators, and it is probably useless
  to complain to them".


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

[Loganaden Velvindron]

On Thursday, September 12, 2019, Tim Wicinski  wrote:

> All
>
> We had such great comments the first time we did a Working Group
> Last Call for draft-ietf-dnsop-extended-error, that the chairs decided
> a second one would be even better.
>
> Before we start, a few comments:
>
> - Viktor's comments from 11 September will be rolled into the WGLC
>   comments, which means I'll be tracking them with the authors.
>
> - The chairs are not doing to add more codes to the IANA registry
>   in the document.  However, the process is laid out in section 5.2,
>   with three different ranges (Expert Review; First Come, First Serve;
>   and Experimental).
>
> - We're pretty sure all comments have been addressed one way or another,
>   but we still may have missed some.  Please speak up if that is the case.
>
> I'm ok with the latest revision. Just a small request: John Todd from
quad9 sent his feedback, so it's fair to credit him in the next revision of
the draft.



>
> This starts a Working Group Last Call for draft-ietf-dnsop-extended-error
>
> Current versions of the draft is available here:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-extended-error/
>
> The Current Intended Status of this document is: Standards Track
>
> Please review the draft and offer relevant comments.
> If this does not seem appropriate please speak out.
> If someone feels the document is *not* ready for publication, please speak
> out with your reasons.
>
> This starts a two week Working Group Last Call process, and ends on:  26
> September 2019.
>
> thanks
> tim
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

[Viktor Dukhovni]

On Thu, Sep 12, 2019 at 09:51:25AM -0400, Tim Wicinski wrote:

> - Viktor's comments from 11 September will be rolled into the WGLC
>   comments, which means I'll be tracking them with the authors.

Much appreciated, thanks!

FWIW, on the hot topic of conflict between RCODE and extended RCODE,
Paul Hoffman's latest comment:

Proposal: add the following sentence to the end of the abstract:
"Extended error information does not change the processing of
RCODEs."

Proposal: add to the end of the Introduction: Applications MUST
NOT change the processing of RCODEs in messages based on extended
error codes.

seems to align with my take on the interaction of EDEs as a (to
coin a phrase) diagnostic refinement rather than "replacement" of
the RCODE.

>From a related nomenclature perspective, I wonder whether there
might be any confusion between the existing high 8 bits of RCODE
in the EDNS OPT pseudo-header (MSB octet of the TTL) and the proposed
new "Extended DNS Error Code".  Perhaps "Extended RCODE" and "Extended
DNS Error Code" are sufficiently similar terms to warrant a brief
comment to the effect that the proposed EDEs are diagnostic refinements
of the existing "Extended RCODE", which is distinct from EDEs and
remains the definitive status of the response...

-- 
Viktor.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

[Tim Wicinski]

All

We had such great comments the first time we did a Working Group
Last Call for draft-ietf-dnsop-extended-error, that the chairs decided
a second one would be even better.

Before we start, a few comments:

- Viktor's comments from 11 September will be rolled into the WGLC
  comments, which means I'll be tracking them with the authors.

- The chairs are not doing to add more codes to the IANA registry
  in the document.  However, the process is laid out in section 5.2,
  with three different ranges (Expert Review; First Come, First Serve;
  and Experimental).

- We're pretty sure all comments have been addressed one way or another,
  but we still may have missed some.  Please speak up if that is the case.


This starts a Working Group Last Call for draft-ietf-dnsop-extended-error

Current versions of the draft is available here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-extended-error/

The Current Intended Status of this document is: Standards Track

Please review the draft and offer relevant comments.
If this does not seem appropriate please speak out.
If someone feels the document is *not* ready for publication, please speak
out with your reasons.

This starts a two week Working Group Last Call process, and ends on:  26
September 2019.

thanks
tim
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop