Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-10.txt
> On Sep 30, 2019, at 7:06 PM, Wes Hardaker wrote: > >> Which raises another question: Can an OPT RR legitimately carry more >> than one EDE option, and thereby communicate multiple errors? Such as >> perhaps the above hypothetical with some RRSIGs expired, and some not >> yet vlid. > > Yes, the draft discusses including multiple EDE reports. I appears that text discussing the possibility of multiple EDE values present in earlier drafts may have been inadvertently removed in -07. I think such text should be restored, making it clear that the OPT record may contain multiple pertinent EDE values. -- Viktor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Re: Processing error codes in draft-ietf-dnsop-extended-error-10
On 9/30/19 7:09 PM, Wes Hardaker wrote: > Paul Hoffman writes: > >> Saying "SHOULD NOT" without helping the reading understand the >> implications is dangerous and will lead to lack of >> interoperability. Either this document specifies the exact places >> where an EDE can change the processing of the RCODE, or the current >> MUST NOT wording is correct. > > Did you read the new replacement sentence? > >Applications MUST continue to follow requirements from applicable >specs on how to process RCODEs no matter what EDE values is also >received. > > Is that sufficient? Yes, thank you. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] I-D Action: draft-ietf-dnsop-extended-error-11.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations WG of the IETF. Title : Extended DNS Errors Authors : Warren Kumari Evan Hunt Roy Arends Wes Hardaker David C Lawrence Filename: draft-ietf-dnsop-extended-error-11.txt Pages : 14 Date: 2019-09-30 Abstract: This document defines an extensible method to return additional information about the cause of DNS errors. Though created primarily to extend SERVFAIL to provide additional information about the cause of DNS and DNSSEC failures, the Extended DNS Errors option defined in this document allows all response types to contain extended error information. Extended DNS Error information does not change the processing of RCODEs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-extended-error/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnsop-extended-error-11 https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-extended-error-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-extended-error-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Re: Processing error codes in draft-ietf-dnsop-extended-error-10
Paul Hoffman writes: > Saying "SHOULD NOT" without helping the reading understand the > implications is dangerous and will lead to lack of > interoperability. Either this document specifies the exact places > where an EDE can change the processing of the RCODE, or the current > MUST NOT wording is correct. Did you read the new replacement sentence? Applications MUST continue to follow requirements from applicable specs on how to process RCODEs no matter what EDE values is also received. Is that sufficient? > Some folks (apparently including the document authors) want to be be > able to use the presence of an EDE to change the way resolvers act. Not sure why you think the authors think that. We've (I think all) been arguing "this is for debugging". I do push back on unnecessary MUSTs a lot of the time, but I think the above text is better and still uses strong language and indicates precedence goes to other specs. -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-10.txt
Viktor Dukhovni writes: > ... but no signatures are presently valid and some (often all) > are expired. > ... but no signatures are presently valid and some are not yet valid. Ok, changed to that text. > Which raises another question: Can an OPT RR legitimately carry more > than one EDE option, and thereby communicate multiple errors? Such as > perhaps the above hypothetical with some RRSIGs expired, and some not > yet vlid. Yes, the draft discusses including multiple EDE reports. -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-10.txt
> On Sep 27, 2019, at 7:32 PM, internet-dra...@ietf.org wrote: > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-extended-error-10 Perhaps at my instigation the descriptions for: 3.8. Extended DNS Error Code 7 - Signature Expired and 3.9. Extended DNS Error Code 8 - Signature Not Yet Valid were changed in version 10 to read, respectively: ... but all the signatures in an RRset in the validation chain were expired. ... but all the signatures received were not yet valid. But I guess it is also possible in pathological cases, that both might apply. Specifically, when none of the RRSIGs are extant, with at least one expired, and the rest (at least one) not yet valid. FWIW, the language could be amended to accommodate this possibility: ... but no signatures are presently valid and some (often all) are expired. ... but no signatures are presently valid and some are not yet valid. Which raises another question: Can an OPT RR legitimately carry more than one EDE option, and thereby communicate multiple errors? Such as perhaps the above hypothetical with some RRSIGs expired, and some not yet vlid. -- Viktor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-extended-error status
On Mon, Sep 30, 2019 at 7:54 AM Tony Finch wrote: > > Wes Hardaker wrote: > > > > 2) One outstanding topic of discussion that I think we need to decide to > > handle or table till a future document: how do we handle forwarding, > > chained resolvers, and caching. > > Difficult. In general there will be multiple upstream servers, even in > the simplest case of a stub talking to a recursive server talking directly > to authoritative servers. So there can be an arbitrary combination of > upstream errors, and they might not relate directly to the QNAME, (e.g. > problems with a parent zone, problems chasing down nameserver addresses). > RFC 6891 - Extension Mechanisms for DNS (EDNS(0)) speaketh thusly: "EDNS is a hop-by-hop extension to DNS. This means the use of EDNS is negotiated between each pair of hosts in a DNS resolution process, for instance, the stub resolver communicating with the recursive resolver or the recursive resolver communicating with an authoritative server." and also sayeth: "OPT RRs MUST NOT be cached, forwarded, or stored in or loaded from master files." I *think* that this covers the issue for many cases; EDE is not intended to be a silver bullet, more something which provides useful information for troubleshooting / debugging. We would not (and cannot :-)) preclude other work from further defining this, but I think that it's beyond the scope of this document / we will better be able to understand things once we've had some deployment experience. Thank you, W > Perhaps if the upstream problems are consistent with each other, the > resolver can return a single extended error code to its client; otherwise > fall back to a "multiple errors" catch-all? > > Tony. > -- > f.anthony.n.finchhttp://dotat.at/ > Malin: East backing northeast 5 to 7. Moderate or rough. Showers. 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] [Ext] Re: Processing error codes in draft-ietf-dnsop-extended-error-10
On 9/30/19 1:53 PM, Wes Hardaker wrote: > Eric Orth writes: > >> I object to the addition of "Receivers MUST NOT change the processing >> of RCODEs in messages based on extended error codes." > > Actually, I agree with you. That text was from suggestion and I put it > in unaltered. I thought about changing it to a SHOULD NOT. From RFC 2119: 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. Saying "SHOULD NOT" without helping the reading understand the implications is dangerous and will lead to lack of interoperability. Either this document specifies the exact places where an EDE can change the processing of the RCODE, or the current MUST NOT wording is correct. It is feeling like there is widespread confusion about the purpose of EDEs. Some folks (apparently including the document authors) want to be be able to use the presence of an EDE to change the way resolvers act. It would be really good if there was a list of which EDEs might be used to change specific RFCs so that the WG can understand this better. In specific, the core DNSSEC RFCs specify how to handle certain RCODEs in certain circumstances with MUST-level requirements. Does this document change those requirements? --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] RDBD draft updated
Hi all, As per discussion at IETF 105, Alex and I did some more work on the RDBD draft (lots of text edits and a bit of prototyping) and have posted a new version. [1] We'd be very interested in folks' opinions. Thanks, Stephen & Alex. [1] https://tools.ietf.org/html/draft-brotman-rdbd-03 0x5AB2FAF17B172BEA.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ 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 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] Comments on draft-ietf-dnsop-extended-error version 10
Mats Dufberg writes:
> Section 1 ends with "Receivers MUST NOT change the processing of
> RCODEs in messages based on extended error codes" but it is not fully
> clear what that statement means in the light of the description in the
> beginning of the same section where the motivation for extended error
> codes is that the resolver cannot know what specific error that is
> behind, e.g., REFUSED and there does not know what the best next step
> is.
See the discussion with Eric about new wording for that sentence. That
being said, I think your point is valid about misunderstanding the
purpose as well. So I've added this sentence to the end of the first
paragraph:
What error messages should be presented to the user or logged
under these conditions?
Seem ok?
> Both section 3.18 (filtered) and section 3.19 (prohibited) has code 17. In the
> registry table (4.2) it is code 17 and 18, respectively.
Fixed, thanks.
> Both 3.14 (Cached error) and 3.20 (Stale NXDOMAIN answer) reports that the
> RCODE returned was taken from cached. In 3.20 it is described in detail what
> the resolver has done before the answer is returned, whereas in 3.14 there are
> not details at all.
>
> 3.14 needs more specification of when to use cached SERVFAIL.
Hmm... What more would I put other than "the resolver is to include
this when it returns a SERVFAIL from the cache?" I've changed the text
to
The resolver is returning the SERVFAIL RCODE from its cache.
Which I think is clearer.
> I think that the last sentence in 3.20 ("This is typically caused [...] result
> of a DoS attack against another network") does not belong to a standard
> document.
I've changed it to this:
This is may be caused, for example, by problems
communicating with an authoritative server, possibly as
result of a DoS attack against another network.
Which removes "typically", which I think you're right is out of place.
I don't think removing the sentence is helpful to the reader, so I'd
rather fix it.
> In 3.22 it would be better to say that the operation or query is not supported
> ("Not supported"). As the text is now it is unclear by whom it is deprecated.
Ok, I'm fine with that. Changed.
> I suggest that the sentence "This may occur because its most recent
> zone is too old, or has expired, for example" is removed from 3.25
> since there could be multiple reasons and it is not needed to give an
> example in a standard document.
I'm not sure why you think examples aren't useful in standards
documents? IMHO, they're used all the time (the IMAP RFC is one of my
favorites that is full of example usages). In the previous example you
brought up above, I agree that we shouldn't be determining commonality
of possibilities. But I think examples in generally greatly help the
reader determine how to more accurately interpret a specification.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Processing error codes in draft-ietf-dnsop-extended-error-10
Eric Orth writes: > I object to the addition of "Receivers MUST NOT change the processing > of RCODEs in messages based on extended error codes." Actually, I agree with you. That text was from suggestion and I put it in unaltered. I thought about changing it to a SHOULD NOT. But, I like some of your suggestions: > *Something like "applications MUST continue to follow requirements from > applicable specs on how to process rcodes no matter what EDE is also > received" also seems reasonable. Clarifies that those cases where > requirements do exist on how an application acts on errors still apply but > doesn't pretend that the EDE spec now tells the application what to do in > all cases. I think your point is valid and follows the intent: EDE is *not* supposed to supersede other specifications that specify how to process a DNS response. > *Something like "applications SHOULD interpret EDE as supplemental to rcode > rather than as a replacement" also seems reasonable. Clarifies the > communicated meaning of the code without over prescribing how the > application acts on that meaning. Again, makes sense. I think it's covered by your other sentence though? (which I've just replaced the previous sentence with) -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Comments on draft-ietf-dnsop-extended-error version 10
Section 1 ends with "Receivers MUST NOT change the processing of RCODEs in
messages based on extended error codes" but it is not fully clear what that
statement means in the light of the description in the beginning of the same
section where the motivation for extended error codes is that the resolver
cannot know what specific error that is behind, e.g., REFUSED and there does
not know what the best next step is.
Both section 3.18 (filtered) and section 3.19 (prohibited) has code 17. In the
registry table (4.2) it is code 17 and 18, respectively.
Both 3.14 (Cached error) and 3.20 (Stale NXDOMAIN answer) reports that the
RCODE returned was taken from cached. In 3.20 it is described in detail what
the resolver has done before the answer is returned, whereas in 3.14 there are
not details at all.
3.14 needs more specification of when to use cached SERVFAIL.
I think that the last sentence in 3.20 ("This is typically caused [...] result
of a DoS attack against another network") does not belong to a standard
document.
In 3.22 it would be better to say that the operation or query is not supported
("Not supported"). As the text is now it is unclear by whom it is deprecated.
I suggest that the sentence "This may occur because its most recent zone is too
old, or has expired, for example" is removed from 3.25 since there could be
multiple reasons and it is not needed to give an example in a standard document.
---
Mats Dufberg
DNS Specialist
Internetstiftelsen (The Swedish Internet Foundation)
Mobile: +46 73 065 3899
https://internetstiftelsen.se/
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-extended-error status
Wes Hardaker wrote: > > 2) One outstanding topic of discussion that I think we need to decide to > handle or table till a future document: how do we handle forwarding, > chained resolvers, and caching. Difficult. In general there will be multiple upstream servers, even in the simplest case of a stub talking to a recursive server talking directly to authoritative servers. So there can be an arbitrary combination of upstream errors, and they might not relate directly to the QNAME, (e.g. problems with a parent zone, problems chasing down nameserver addresses). Perhaps if the upstream problems are consistent with each other, the resolver can return a single extended error code to its client; otherwise fall back to a "multiple errors" catch-all? Tony. -- f.anthony.n.finchhttp://dotat.at/ Malin: East backing northeast 5 to 7. Moderate or rough. Showers. Good. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Re: draft-ietf-dnsop-extended-error and combinations of EDEs and RCODEs
Wes Hardaker wrote: > > + 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? The filtering / blocking explanations are much more clear now, thanks! > 14.9.3 DONE 3.21. Extended DNS Error Code 20 - Lame > > > This needs to be split into two: server doesn't know about the zone > queried for (typically RCODE=REFUSED), and server knows about the zone > but it has expired (typically RCODE=SERVFAIL). > > Resolvers handling RD=0 queries typically answer from cache or would > answer REFUSED/Prohibited, I would have thought. > > + Response: I created an "Invalid Data" error code to handle this. > Does this work for you? Oh, funny, that sounds to me like an error from a primary server complaining about a malformed zone file. So that's a third kind of lameness! I like the 'not authoritative" explanation. Tony. -- f.anthony.n.finchhttp://dotat.at/ Hebrides, Bailey: Northeast backing north 5 or 6. Moderate occasionally rough. Showers. Good. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
