Re: [DNSOP] [Ext] Re: Processing error codes in draft-ietf-dnsop-extended-error-10
On Mon, Sep 30, 2019 at 8:55 PM Paul Hoffman wrote: > 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 > Just a note. The original draft had a 'retry' code that was intended to change how the client reacted. That has been removed, but there are still some that would like to 'act on' the EDE. One reason given for not doing that is that is can be spoofed or changed by attackers, so it cannot be trusted. I was hoping that this could improve some cases where the client is not acting in an optimal way, but I can understand why that would be discouraged. Should we warn implementers of the issues, but still not forbid acting on them? -- Bob Harold ___ 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: > > 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. Good catch. That notion did get removed by accident. How does this sound: Senders MAY include more than one EDE option and receivers MUST be able to accept (but not necessarily process or act on) multiple EDE options in a DNS message. -- Wes Hardaker USC/ISI ___ 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
Bob Harold writes: > > 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 > > Just a note. The original draft had a 'retry' code that was intended > to change how the client reacted. That has been removed, but there > are still some that would like to 'act on' the EDE. One reason given > for not doing that is that is can be spoofed or changed by attackers, > so it cannot be trusted. I was hoping that this could improve some > cases where the client is not acting in an optimal way, but I can > understand why that would be discouraged. Should we warn implementers > of the issues, but still not forbid acting on them? Well, I think the new text tries to do this, no? Specifically, we're now saying "follow other specs", but we don't specifically prohibit not-acting if there are no other specs that intervene. -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] I-D Action: draft-ietf-dnsop-extended-error-12.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-12.txt Pages : 14 Date: 2019-10-01 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-12 https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-extended-error-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-extended-error-12 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] I-D Action: draft-ietf-dnsop-extended-error-12.txt
internet-dra...@ietf.org writes: > 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. This version addresses, I believe, all comments from the WG LC. -- 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 Tue, Oct 01, 2019 at 04:36:02PM -0700, Wes Hardaker wrote: > > 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. > > Good catch. That notion did get removed by accident. > > How does this sound: > > Senders MAY include more than one EDE option and receivers MUST be > able to accept (but not necessarily process or act on) multiple > EDE options in a DNS message. No objections from me. -- Viktor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] SVCB and HTTPSSVC records: draft-nygren-dnsop-svcb-httpssvc-00
Subject: [DNSOP] SVCB and HTTPSSVC records: draft-nygren-dnsop-svcb-httpssvc-00 Date: Tue, Sep 24, 2019 at 09:17:59AM -0400 Quoting Erik Nygren (erik+i...@nygren.org): > Following discussions around the "HTTPSSVC" record proposal in Montreal > with the DNSOP, HTTP and TLS WGs, we've updated what was previously > "draft-nygren-httpbis-httpssvc-03". > We'd like to see this adopted by the DNSOP WG. I have read the draft and support its adaption by the wg. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE SA0XLR+46 705 989668 Now I'm having INSIPID THOUGHTS about the beatiful, round wives of HOLLYWOOD MOVIE MOGULS encased in PLEXIGLASS CARS and being approached by SMALL BOYS selling FRUIT ... signature.asc Description: PGP signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-extended-error status
On 9/30/19 11:47 PM, Warren Kumari wrote: > On Mon, Sep 30, 2019 at 7:54 AM Tony Finch wrote: >> 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. My understanding is that the hop-by-hop condition is just the default and as suggested we could define/allow e.g. that if all upstreams return "filtered", we send the same downstream. I expect we could first publish RFC without propagation of these errors in mind, but there's a risk that when we later want to add that, we'll need to make too big changes, e.g. we may miss something like the near/far flag mentioned earlier. If we/you don't want to deal with the propagation now, reserving some bits for future use (MUST zero now) might be a nice compromise, assuming we at least have some vague idea that a few of them are likely to be useful in future. Another plan might be to do nothing now and later we might: (1) define another EDNS0 extension that will *separately* carry information in addition to this EDE or (2) define new flags within the current EDE and utilize the allowance of sending multiple EDEs. These options sound a bit messier to me, but they seem doable. --Vladimir ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
