Re: [DNSOP] I-D Action: draft-ietf-dnsop-avoid-fragmentation-11.txt
Mukund-san, Thanks very much. I updated my local version. http://member.wide.ad.jp/~fujiwara/avoid-fragmentation.html -- Kazunori Fujiwara, JPRS > From: Mukund Sivaraman > Fujiwara-san, Vixie-san, > > On Thu, Jan 19, 2023 at 12:13:02AM -0800, internet-dra...@ietf.org wrote: >> >> 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 : Fragmentation Avoidance in DNS >> Authors : Kazunori Fujiwara >> Paul Vixie >> Filename: draft-ietf-dnsop-avoid-fragmentation-11.txt >> Pages : 10 >> Date: 2023-01-19 >> >> Abstract: >>EDNS0 enables a DNS server to send large responses using UDP and is >>widely deployed. Large DNS/UDP responses are fragmented, and IP >>fragmentation has exposed weaknesses in application protocols. It is >>possible to avoid IP fragmentation in DNS by limiting response size >>where possible, and signaling the need to upgrade from UDP to TCP >>transport where necessary. This document proposes techniques to >>avoid IP fragmentation in DNS. > > Is there still time to mention some editorial nits? If so, please see > the following; I am sorry I did not review the recent revision earlier. > > >> 1. Introduction > >>DNS has an EDNS0 [RFC6891] mechanism. It enables a DNS server to >>send large responses using UDP. EDNS0 is now widely deployed, and >>DNS (over UDP) relies on on IP fragmentation when the EDNS buffer > > I suggest removing the brackets around "(over UDP)", and fix the typo of > two "on"s: > > i.e, write it as "... and DNS over UDP relies on IP fragmentation..." > >>This document proposes that implementations set the "Don't Fragment >>(DF) bit" [RFC0791] on IPv4 and not using the "Fragment header" > > "... and not use the \"Fragment header\"..." > >>[RFC8200] on IPv6 in DNS/UDP messages in order to avoid IP >>fragmentation, and describes how to avoid packet losses due to DF bit > > "... fragmentation. It also describes..." > >> 2. Terminology > >>"Requestor" refers to the side that sends a request. "Responder" >>refers to an authoritative, recursive resolver or other DNS component > > "... to an authoritative server, recursive resolver or..." > >> 3. Proposal to avoid IP fragmentation in DNS > >>These recommendations are intended for nodes with global IP addresses >>on the Internet. Private networks or local networks are out of the >>scope of this document. > >>The methods to avoid IP fragmentation in DNS are described below: > >> 3.1. Recommendations for UDP responders > >>* UDP responders SHOULD send DNS responses without "Fragment header" >> [RFC8200] on IPv6. > >>* UDP responders are RECOMMENDED to set IP "Don't Fragment flag (DF) >> bit" [RFC0791] on IPv4. > > I suggest using the RFC 2119 term SHOULD here as well (synonymous with > RECOMMENDED), so that when reading the text, the recommendation doesn't > appear of a different severity from the other items. > > "UDP responders SHOULD set the IP \"Don't Fragment flag (DF)..." > >>* UDP responders SHOULD compose response packets that fit in both > > "both" implies 2, whereas there are 3 things suggested. I suggest > deleting the word "both" and keeping the rest of the text. > >> the offered requestor's maximum UDP payload size [RFC6891], the >> interface MTU, and the RECOMMENDED maximum DNS/UDP payload size >> 1400. > >>* If the UDP responder detects an immediate error that the UDP > > "... immediate error indicating that the..." > >> packet cannot be sent beyond the path MTU size (EMSGSIZE), the UDP >> responder MAY recreate response packets fit in path MTU size, or >> TC bit set. > > "... recreate response packets to fit in the path MTU size, or with the > TC bit set." > >>* UDP responders SHOULD limit response size when UDP responders are > > "... SHOULD limit the response size..." > >> located on small MTU (<1500) networks. > >> 3.2. Recommendations for UDP requestors > >>* UDP requestors SHOULD limit the requestor's maximum UDP payload >> size to the RECOMMENDED size of 1400 or smaller size. > > "... or a smaller size." > >>* UDP requestors MAY drop fragmented DNS/UDP responses without IP >> reassembly to avoid cache poisoning attacks. > >>* DNS responses may be dropped by IP fragmentation. Upon a timeout, >> to avoid name resolution fails, UDP requestors MAY retry using TCP > > "... to avoid resolution failures, ..." > >> or UDP with a smaller requestor's maximum UDP payload size per > > "... smaller EDNS requestor's maximum UDP payload size..." > >> local policy. > > >> 4. Recommendations for zone operators and DNS server operators > >>Lar
Re: [DNSOP] Implementor's status on draft-ietf-dnsop-avoid-fragmentation: PowerDNS
Thanks very much. I updated my local version. http://member.wide.ad.jp/~fujiwara/avoid-fragmentation.html -- Kazunori Fujiwara, JPRS > From: Peter van Dijk > PowerDNS Authoritative Server, PowerDNS Recursor, PowerDNS dnsdist: > > * IP_PMTUDISC_OMIT with fallback to IP_PMTUDISC_DONT > * default EDNS buffer size of 1232, no probing for smaller sizes > * no handling of EMSGSIZE > * Recursor: UDP timeouts do not cause a switch to TCP. "Spoofing > nearmisses" do. > > PowerDNS Authoritative Server: > > * the default DNSSEC algorithm is 13 > * responses are minimal, this is not configurable > > Kind regards, > -- > Peter van Dijk > PowerDNS.COM BV - https://www.powerdns.com/ > > ___ > 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] With multi-algo DS, what to do if an RRSIG is missing?
On Mon, Jul 03, 2023 at 08:25:08PM +0200, Peter Thomassen wrote:
> Now, assume a multi-signer setup of, say, algorithms 7 and 13. This is
> not an uncommon transition (ietf.org did it last month, except that
> they went unsigned). In such a scenario, a resolver on Red Hat would
> only consider the algo 13 DS records.
Yes, the only way to move and stay signed in the case of ietf.org was to
complete a transition to algorithm 13 while still self-hosted, and only
then migrate to Cloudflare's hosting platform (based on the expectation
that Cloudflare don't support signing with algorithm 7).
This IIRC was more complexity than they were willing to take on.
> Under the relaxed RRSIG presence rule, it would be fine to serve
> signatures of *one* algorithm only (either 7 or 13). If only 7 is
> served, my understanding is that this would lead to SERVFAIL, because
> signatures are missing for the only supported algorithm. There is no
> valid path.
The relaxed RRSIG presence rule (for signers) is fundamentally
incompatible with the DNSSEC security model. So long as there exists a
non-negligible population of resolvers that support only one of the two
algorithms, queries for a zone where some or all servers return RRSIGs
for just one of the two algorithms will sporadically fail validation.
And since the whole point of multiple (dual) providers is to be able to
operate in the face of an outage of one of the providers, if the one
that fails is the only one with supported RRSIGs (for a given resolver)
the outage is then total, rather than sporadic.
So long as both providers are up, some queries will randomly find an
acceptable resolver, and caching might then keep the failure rate low,
but note also that not all resolvers try another server when a bogus
response is detected.
Some notable resolvers do "late" validation, where the query with all
necessary referral chasing and retransmissions is performed first, and
the response is validated at the end, with no opportunity to retry the
query at another server. So when the cache is cold, failures will
happen until some query eventually hits a compatible server.
> Here are the questions:
>
> 1.) Is SERVFAIL the correct behavior in the above scenario?
Yes, unless a better server happens to be found (see above). The
response is bogus.
> 2.) Does anyone think that "insecure" is the right behavior? ("I can
> see another signature of algorithm 7 which I can't validate; it might
> match, so I'll pass this.")
Absolutely not. DNSSEC without resistance to active attacks is mere
security theatre. You get all the failure modes, and none of the
protection.
> 3.) If anyone thinks that "insecure" is fine: Why should the resolver
> assume that things are fine, and that the lack of signature is not an
> indication of a downgrade-to-insecure attack?
The question is moot. Anyone who thinks that "insecure" is fine is
sadly quite mistaken.
> 4.) In fact, how would the resolver distinguish this from a
> downgrade-to-insecure attack?
Not possible.
> 5.) If the authoritative server can't know what the resolver supports,
> how could it ever be safe, by not sending RRSIGs for all algorithms,
> to introduce the confusion of question (4)?
The only scenario (difficult to know for sure) under which the RRSIGs
can be partitioned by provider is when both operators and the zone owner
are absolutely sure that effectively all resolvers support both
algorithms and only a negligible population they're willing to let break
do not.
This may be somewhat true at present if the two algorithms are 8 and 13,
which one expects every validating resolver to support. These two
algorithms account for roughly 55% and 45% of all signed zones, and
both are used by major TLDs, ...
So, it may **at this point in time** be possible to have one server
returning algorithm 8 RRSIGs, and another algorithm 13, while the DS
RRSet lists both.
This "happy point time" is a result of both MTI algorithms being widely
used and long established.
There are no other such algorithm pairs, and when, for example,
algorithm 15 finally sees non-trivial adoption, it may not be possible
to split 8/15 or 13/15 across providers for close to a decade.
> (Does the signer know enough about the validator to decide which
> algorithms can be advertised but then their signatures left off,
> because another advertised algorithm is surely supported?)
See above. Perhaps, with luck, at present, when the two algorithms are
8 and 13, but not otherwise.
> Also note that the algorithms in this example (7 and 13) are both
> "MUST implement" on the validator side, RFC 8624 Section 3.1. Some say
> that "MUST implement" is different from "MUST support".
MTI is not a time-invariant fundamental property of an algorithm, and
resolvers of various "vintages" freeze-in different notions of which
algorithms are or aren't MTI. Therefore, MTI does not enter the
equation. Only point-in-time knowledge of the current resolver
population might infor
Re: [DNSOP] With multi-algo DS, what to do if an RRSIG is missing?
> On 4 Jul 2023, at 04:25, Peter Thomassen wrote:
>
> Dear DNSOP,
>
> It's well-known that DNSSEC multi-signer setups are problematic when
> providers want to sign with different algorithms.
>
> In a hypothetical scenario where signing requirements would be relaxed, I
> have a very specific question about how resolvers should behave. Apologies
> for the length of the message, and thank you for reading it.
>
>
> To lay out the problem fully, here's an appetizer from the spec. RFC 6840
> Section 5.11 says (emphasizing a point from RFC 4035 Section 2.2):
>
>
> A signed zone MUST include a DNSKEY for each algorithm present in
> the zone's DS RRset and expected trust anchors for the zone. The
> zone MUST also be signed with each algorithm (though not each key)
> present in the DNSKEY RRset. [...]
>
> This requirement applies to servers, not validators. Validators
> SHOULD accept any single valid path. They SHOULD NOT insist that all
> algorithms signaled in the DS RRset work, [...]
>
>
>
> The second rule is not contentious. It basically says that validators SHOULD
> NOT apply a "logical AND" on algorithms offered by the DS record set;
> instead, "logical OR" is encouraged. There was an issue with this in Unbound,
> but that's been solved ages ago. (Well,* ...)
>
>
> However, the first rule is incompatible with certain use cases. In
> particular, it is not possible to have the same zone served by several
> operators, each signing with their own key and choice of algorithm.
>
> A special case of this is the glitch-free transfer of a domain name from one
> DNS provider to another, while retaining DNSSEC validation. During the
> transition, a multi-signer phase will be in effect, and if the old and new
> provider don't support overlapping sets of algorithms, you'll run into the
> aforementioned problem.
>
> For the sake of argument, let's replace the first rule by something like:
>
> Independent of the number of signing algorithms appearing in it, the
> DS RRset MUST reference at least one DNSKEY that signs theDNSKEY
> RRset. Other RRsets MUST be signed with at least one DNSKEY whose
> algorithm appears in the DS RRset.
>
> More casually, "it's sufficient to sign with one algorithm from DS, as long
> as it allows for authenticating along some valid path".
>
> (Note that from the resolver perspective, this is compatible with rule 2, as
> long as all announced algorithms are supported.)
>
>
> Next, consider that Red Hat turned off SHA-1-based signing algorithms in Red
> Hat Enterprise Linux 9 and related distributions. As this is a system-wide
> policy, it affects validation of DNSSEC algorithms 5 and 7 in resolvers. In
> response, Unbound [1], Knot Resolver [2] and PowerDNS Recursor [3] all have
> implemented ways to detect whether these algorithms work, and disable them if
> not supported.
>
> That works great for zones that use algorithm 5 or 7 *only*: corresponding DS
> records will be dropped from consideration, and as nothing is left, the zone
> is treated as insure.
>
>
> Now, assume a multi-signer setup of, say, algorithms 7 and 13. This is not an
> uncommon transition (ietf.org did it last month, except that they went
> unsigned). In such a scenario, a resolver on Red Hat would only consider the
> algo 13 DS records.
>
> Under the relaxed RRSIG presence rule, it would be fine to serve signatures
> of *one* algorithm only (either 7 or 13). If only 7 is served, my
> understanding is that this would lead to SERVFAIL, because signatures are
> missing for the only supported algorithm. There is no valid path.
>
> This situation looks exactly like a double-algorithm setup where an on-wire
> attacker stripped RRSIGs for algorithm 13 so they can mess with the response
> (knowing that 7 is not going to get validated). -- This removes all of the
> DNSSEC security guarantees, despite of algorithm 13 being advertised in the
> DS RRset.
>
>
> Here are the questions:
>
> 1.) Is SERVFAIL the correct behavior in the above scenario?
Sometimes. If the validator supports 7 and not 13 and only gets 13. The DS
RRset says that both 7 and 13 are present.
> 2.) Does anyone think that "insecure" is the right behavior? ("I can see
> another signature of algorithm 7 which I can't validate; it might match, so
> I'll pass this.")
If the validator doesn’t support both 7 and 13.
> 3.) If anyone thinks that "insecure" is fine: Why should the resolver assume
> that things are fine, and that the lack of signature is not an indication of
> a downgrade-to-insecure attack?
>
> 4.) In fact, how would the resolver distinguish this from a
> downgrade-to-insecure attack?
It can’t.
> 5.) If the authoritative server can't know what the resolver supports, how
> could it ever be safe, by not sending RRSIGs for all algorithms, to introduce
> the confusion of question (4)?
It isn’t.
> It is sometimes noted that Rule 1 above (signer requ
Re: [DNSOP] With multi-algo DS, what to do if an RRSIG is missing?
The rules are there to ensure that if the resolver see an algorithm it
supports then it can validate the response. If you fail to follow the rules
answers won’t ALWAYS validate. If there is one level of validation happening
the validator should recover by trying other servers. If you have chained
validators all bets are off as you can cache a set that the next validator in
the chain can’t validate successfully.
The resolver can check that the set of DNSKEY algorithms found in the DS set
safely. It was the DNSKEY algorithms that don’t work in a loosely coherent
database. There are timing constraints between DS and DNSKEY that allow
determination of what the zone is signed with that are impossible to achieve
with DNSKEY alone unless you pre publish signatures.
--
Mark Andrews
> On 4 Jul 2023, at 04:25, Peter Thomassen wrote:
>
> Dear DNSOP,
>
> It's well-known that DNSSEC multi-signer setups are problematic when
> providers want to sign with different algorithms.
>
> In a hypothetical scenario where signing requirements would be relaxed, I
> have a very specific question about how resolvers should behave. Apologies
> for the length of the message, and thank you for reading it.
>
>
> To lay out the problem fully, here's an appetizer from the spec. RFC 6840
> Section 5.11 says (emphasizing a point from RFC 4035 Section 2.2):
>
>
> A signed zone MUST include a DNSKEY for each algorithm present in
> the zone's DS RRset and expected trust anchors for the zone. The
> zone MUST also be signed with each algorithm (though not each key)
> present in the DNSKEY RRset. [...]
>
> This requirement applies to servers, not validators. Validators
> SHOULD accept any single valid path. They SHOULD NOT insist that all
> algorithms signaled in the DS RRset work, [...]
>
>
>
> The second rule is not contentious. It basically says that validators SHOULD
> NOT apply a "logical AND" on algorithms offered by the DS record set;
> instead, "logical OR" is encouraged. There was an issue with this in Unbound,
> but that's been solved ages ago. (Well,* ...)
>
>
> However, the first rule is incompatible with certain use cases. In
> particular, it is not possible to have the same zone served by several
> operators, each signing with their own key and choice of algorithm.
>
> A special case of this is the glitch-free transfer of a domain name from one
> DNS provider to another, while retaining DNSSEC validation. During the
> transition, a multi-signer phase will be in effect, and if the old and new
> provider don't support overlapping sets of algorithms, you'll run into the
> aforementioned problem.
>
> For the sake of argument, let's replace the first rule by something like:
>
> Independent of the number of signing algorithms appearing in it, the
> DS RRset MUST reference at least one DNSKEY that signs theDNSKEY
> RRset. Other RRsets MUST be signed with at least one DNSKEY whose
> algorithm appears in the DS RRset.
>
> More casually, "it's sufficient to sign with one algorithm from DS, as long
> as it allows for authenticating along some valid path".
>
> (Note that from the resolver perspective, this is compatible with rule 2, as
> long as all announced algorithms are supported.)
>
>
> Next, consider that Red Hat turned off SHA-1-based signing algorithms in Red
> Hat Enterprise Linux 9 and related distributions. As this is a system-wide
> policy, it affects validation of DNSSEC algorithms 5 and 7 in resolvers. In
> response, Unbound [1], Knot Resolver [2] and PowerDNS Recursor [3] all have
> implemented ways to detect whether these algorithms work, and disable them if
> not supported.
>
> That works great for zones that use algorithm 5 or 7 *only*: corresponding DS
> records will be dropped from consideration, and as nothing is left, the zone
> is treated as insure.
>
>
> Now, assume a multi-signer setup of, say, algorithms 7 and 13. This is not an
> uncommon transition (ietf.org did it last month, except that they went
> unsigned). In such a scenario, a resolver on Red Hat would only consider the
> algo 13 DS records.
>
> Under the relaxed RRSIG presence rule, it would be fine to serve signatures
> of *one* algorithm only (either 7 or 13). If only 7 is served, my
> understanding is that this would lead to SERVFAIL, because signatures are
> missing for the only supported algorithm. There is no valid path.
>
> This situation looks exactly like a double-algorithm setup where an on-wire
> attacker stripped RRSIGs for algorithm 13 so they can mess with the response
> (knowing that 7 is not going to get validated). -- This removes all of the
> DNSSEC security guarantees, despite of algorithm 13 being advertised in the
> DS RRset.
>
>
> Here are the questions:
>
> 1.) Is SERVFAIL the correct behavior in the above scenario?
>
> 2.) Does anyone think that "insecure" is the right behavior? ("I can see
> another signature of algorithm
[DNSOP] With multi-algo DS, what to do if an RRSIG is missing?
Dear DNSOP,
It's well-known that DNSSEC multi-signer setups are problematic when providers
want to sign with different algorithms.
In a hypothetical scenario where signing requirements would be relaxed, I have
a very specific question about how resolvers should behave. Apologies for the
length of the message, and thank you for reading it.
To lay out the problem fully, here's an appetizer from the spec. RFC 6840
Section 5.11 says (emphasizing a point from RFC 4035 Section 2.2):
A signed zone MUST include a DNSKEY for each algorithm present in
the zone's DS RRset and expected trust anchors for the zone. The
zone MUST also be signed with each algorithm (though not each key)
present in the DNSKEY RRset. [...]
This requirement applies to servers, not validators. Validators
SHOULD accept any single valid path. They SHOULD NOT insist that all
algorithms signaled in the DS RRset work, [...]
The second rule is not contentious. It basically says that validators SHOULD NOT apply a
"logical AND" on algorithms offered by the DS record set; instead, "logical OR"
is encouraged. There was an issue with this in Unbound, but that's been solved ages ago. (Well,*
...)
However, the first rule is incompatible with certain use cases. In particular,
it is not possible to have the same zone served by several operators, each
signing with their own key and choice of algorithm.
A special case of this is the glitch-free transfer of a domain name from one
DNS provider to another, while retaining DNSSEC validation. During the
transition, a multi-signer phase will be in effect, and if the old and new
provider don't support overlapping sets of algorithms, you'll run into the
aforementioned problem.
For the sake of argument, let's replace the first rule by something like:
Independent of the number of signing algorithms appearing in it, the
DS RRset MUST reference at least one DNSKEY that signs theDNSKEY
RRset. Other RRsets MUST be signed with at least one DNSKEY whose
algorithm appears in the DS RRset.
More casually, "it's sufficient to sign with one algorithm from DS, as long as it
allows for authenticating along some valid path".
(Note that from the resolver perspective, this is compatible with rule 2, as
long as all announced algorithms are supported.)
Next, consider that Red Hat turned off SHA-1-based signing algorithms in Red
Hat Enterprise Linux 9 and related distributions. As this is a system-wide
policy, it affects validation of DNSSEC algorithms 5 and 7 in resolvers. In
response, Unbound [1], Knot Resolver [2] and PowerDNS Recursor [3] all have
implemented ways to detect whether these algorithms work, and disable them if
not supported.
That works great for zones that use algorithm 5 or 7 *only*: corresponding DS
records will be dropped from consideration, and as nothing is left, the zone is
treated as insure.
Now, assume a multi-signer setup of, say, algorithms 7 and 13. This is not an
uncommon transition (ietf.org did it last month, except that they went
unsigned). In such a scenario, a resolver on Red Hat would only consider the
algo 13 DS records.
Under the relaxed RRSIG presence rule, it would be fine to serve signatures of
*one* algorithm only (either 7 or 13). If only 7 is served, my understanding is
that this would lead to SERVFAIL, because signatures are missing for the only
supported algorithm. There is no valid path.
This situation looks exactly like a double-algorithm setup where an on-wire
attacker stripped RRSIGs for algorithm 13 so they can mess with the response
(knowing that 7 is not going to get validated). -- This removes all of the
DNSSEC security guarantees, despite of algorithm 13 being advertised in the DS
RRset.
Here are the questions:
1.) Is SERVFAIL the correct behavior in the above scenario?
2.) Does anyone think that "insecure" is the right behavior? ("I can see another
signature of algorithm 7 which I can't validate; it might match, so I'll pass this.")
3.) If anyone thinks that "insecure" is fine: Why should the resolver assume
that things are fine, and that the lack of signature is not an indication of a
downgrade-to-insecure attack?
4.) In fact, how would the resolver distinguish this from a
downgrade-to-insecure attack?
5.) If the authoritative server can't know what the resolver supports, how
could it ever be safe, by not sending RRSIGs for all algorithms, to introduce
the confusion of question (4)?
It is sometimes noted that Rule 1 above (signer requirement) and Rule 2
(validator requirement) are contradictory. I'd like to point out that the
questions raised here have nothing to do with rule 2: Validators should accept
*any* valid path. This rule stands regardless of whether any signatures missing
or not.
The issue is whether there's a supported path, and a safe response when a valid
path is lacking although one could expect one based on DS. This is not about
compatibilit
Re: [DNSOP] Dnsdir last call review of draft-ietf-dnsop-caching-resolution-failures-03
Hello Duane & others, thank you for your response. Comments inline below. On Thu, 2023-06-29 at 23:58 +, Wessels, Duane wrote: > > > > > > ## 2.2 > > > > The first paragraph correctly mentions "policy reasons". The second > > paragraph > > correctly says "they are not authoritative". I am not sure not being > > authoritative can be considered a policy reason, so perhaps these two > > paragraphs can be connected with an "or"? > > I see your point. We propose this change to the introduction sentence: > > A name server returns a message with the RCODE field set to REFUSED > when it refuses to process the query, e.g., for policy or other reasons. Works for me. > > > > > ## 3.1 > > > > "A resolver MUST NOT retry a given query over a server's transport more > > than > > twice" - should this be clarified to say "in a short period of time" or > > something like that? Clearly a retry is allowed *eventually*. > > For reference, here’s the sentence in question at the start of 3.1: > > A resolver MUST NOT retry a given query over a server's transport more > than twice (i.e., three queries in total) before considering the > server's transport unresponsive for that query. > > We feel that “a given query” and “for that query” in the sentence > sufficiently limits the > scope here, and there is no need to qualify it by some amount of time. > > As an example, let’s say that a recursive has been asked to lookup > www.example.com (our “given” query). The example.com zone has two name > servers, each of which has two IP addresses, and (presumably) two transports. > It can send 3 queries to 199.43.135.53 over UDP (then that transport is > unresponsive), 3 queries to 199.43.133.53 over UDP, same over TCP, over IPv6, > and so on. In total the recursive can send 2x2x2x3 = 24 queries before it > has to give up if all servers and all transports are unresponsive. At this > point the resolver gives up on that query and returns SERVFAIL. > > Then, section 3.2 is about caching and says that the resolution failure MUST > be cached for at least 5 seconds, but otherwise gives implementations a lot > of freedom in how to do that. Could be by query tuple, by server/transport, > or some other way. Right! 3.2 solves this. > > Also, "MUST NOT" is pretty strong language. Given the various process > > models of > > resolver implementations, two subprocesses (threads) both retrying the same > > or > > a similar thing a few times can not always be avoided. Would you settle for > > SHOULD NOT? The "given" in "retry a given query" gives some leeway, but not > > enough, I feel. > > We feel that MUST NOT is appropriate but would like more input from working > group > members and implementors especially. Ok > > "may retry a given query over a different transport .. believe .. is > > available" > > - this ignores that some transports have better security properties than > > others. One currently active draft in this area is > > draft-ietf-dprive-unilateral-probing. Perhaps add some wording, without > > being > > too prescriptive, such as "available, and compatible with the resolver's > > security policies, ..". > > We think “compatible with the resolver’s security policies” goes without > saying, but don’t mind making it explicit. I am inclined to agree, and will leave this for others to judge. > > > > ## 3.2 > > > > A previous review > > (https://secure-web.cisco.com/1-uwEOxF71cZbW0W3ux-QNC1pO0bJjYJvc0KHnZ_wN4Xw3M1XWB_K8diPjdzzV1zzAfZ98vObLHcs-9USjQPtEzxOdqnjHtcYGPxv8yID-fDRYNW8i8BtGJL-qahSS-JHbS3LHL6Bfm0duG-nUUKdSZF_MOoDFhQymCFnu838N4-l8Ky7xjoVKijU3pbZHLVQFpxjYecSLm0hqLoc4GW9n2Ri-vYT-lKiSPl5qB72Q1kbSUp21qnHSMMrfCCEizICDfjVzCKrwtau5DkwfiR7PVxgh2wT1twgX8oVBhJIY-0QfTaJLnHg7itWRgwH3tcX/https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fdnsop%2FsJlbyhro-4bDhfGBnXhhD5Htcew%2F) > > suggested that the then-chosen tuple was not specific enough, and also said > > it > > was too prescriptive. I agree with both. The current draft prescribes > > nothing, > > which I'm generally a fan of! > > > > However, speaking to a coworker (the one likely responsible for implementing > > this draft, if it turns out our implementation deviates from its final form) > > told me "some guidance would be nice". After some discussion on > > prescriptiveness, here is our suggestion: do not prescribe, but mention > > (without wanting to be complete) a few tuple formats that might make sense, > > and > > suggest that implementations document what they choose here. > > The relevant text here currently says: > > The implementation might cache different resolution failure conditions > differently. For example, DNSSEC validation failures might be cached > according to the queried name, class, and type, whereas unresponsive > servers might be cached only according to the server's IP address. > > So we provide two examples, although not really phrased as “tuples”. I guess > you’re suggesting to see more op
Re: [DNSOP] Dnsdir early review of draft-ietf-dnsop-structured-dns-error-03
Hi Med, Thanks for the responses, further comments in-line. On Fri, Jun 30, 2023 at 9:24 PM wrote: > > Hi Matt, > > Thank you for the review. > > Please see inline. I let my co-author further comment as appropriate. > > Cheers, > Med > > > -Message d'origine- > > De : Matt Brown via Datatracker > > Envoyé : vendredi 30 juin 2023 00:01 > > À : dns...@ietf.org > > Cc : dnsop@ietf.org; draft-ietf-dnsop-structured-dns- > > error@ietf.org > > Objet : Dnsdir early review of draft-ietf-dnsop-structured-dns- > > error-03 > > > > Reviewer: Matt Brown > > Review result: Almost Ready > > > > I believe this draft has ambiguities that will present issues for > > implementing clients that require further discussion and > > clarification before proceeding. > > > > **Issue 1** > > RFC8914 is clear (section 2) regarding EXTRA-TEXT that “This > > information is intended for human consumption (not automated > > parsing).“. > > > > [Med] Sure. That is already called out in the spec: > > Abstract: >This document updates RFC 8914 by signaling client support for >structuring the EXTRA-TEXT field of the Extended DNS Error to provide >details on the DNS filtering. Such details can be parsed by the >client and displayed, logged, or used for other purposes. > > Introduction: > >This document describes a format for computer-parsable data in the >EXTRA-TEXT field of [RFC8914]. It updates Section 2 of [RFC8914] >which says the information in EXTRA-TEXT field is intended for human >consumption (not automated parsing). > > > Section 4 of this draft implicitly updates that requirement by > > stating that I-JSON can be sent in the field, but focuses on the > > technical aspects of the JSON structure, not on the implications > > of reversing that statement. > > > > Changing a field stated as for human consumption to a field > > intended to be machine-readable is a major change and the > > implications of this change should be discussed in the draft, > > including an explicit statement updating the intent of the EXTRA- > > TEXT field. > > > > In particular I would expect to see discussion and consideration > > of how backwards compatibility with RFC8914 compliant, but > > structured-dns-error ignorant clients would be achieved. > > [Med] Clients that are capable to consume the json format will behave as > follows: > >It SHOULD use an OPTION-LENGTH of 2, >the INFO-CODE field set to "0" (Other Error), and an empty EXTRA-TEXT >field. This signal indicates that the client desires that the server >responds in accordance with the present specification. > > The server will take that into account to elicit which format to use. Will > double check if we need to better clarify this in the text. For now, I > identified this change > https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-structured-dns-error/pull/35/files. OK! My apologies. I managed to completely overlook and miss this discrimination mechanism in my multiple readings of the draft, even when specifically trying to work out how the concerns I originally raised here would be avoided. It seems obvious to me now that you've pointed it out, but it definitely wasn't obvious to me in any of my earlier readings. I would suggest a few extra pointers to this mechanism elsewhere in the draft to help avoid my struggle in future, e.g.: * The first sentence of section 4 could change from "DNS servers that are compliant with this specification ..." to "DNS servers that are compliant with this specification AND have received an indication that the client also supports this specification as per s5.1 send I-JSON..." * In section 5.2, add some statement to cover the normal cases (e.g. "When responding to a query that did not indicate SDE support (per s5.1) the server MUST NOT return I-JSON in EXTRA-TEXT", "When responding to a query that did indicate SDE support (per s5.1) ... [existing content]". Two further clarifying questions on the mechanism itself: 1) The signaling mechanism (EDE OPT RR with OPTION-LENGTH=2, INFO-CODE=0) is the same as the default/null EDE OPT RR, yes? Is there a risk that EDE but not SDE supporting clients are already sending this default/NULL OPT RR in their queries as part of their existing EDE support? Would it make sense to require a more explicit signal? 2) Why is the client recommendation to trigger SDE behaviour on the server only a SHOULD, not a MUST? Is this just to reflect that SDE is optional in general, or are there circumstances envisaged where the client would received an SDE response even without using the mechanism specified in s5.1 ? Perhaps wording this along the lines of "A client wishing to receive structured DNS error information MUST signal its support of this specification to the server by ... " would make the intent here clearer? > > **Issue 2** > > The above ambiguity also appears to lead into conflicting > > instructions for clients in section 5.3 - specifically the first > > and third b
Re: [DNSOP] Review of draft-ietf-dnsop-dnssec-validator-requirements-06
On 6/30/23 22:15, Paul Wouters wrote: Section 13: [...] an attacker being able to provide a rogue trust anchor is potentially This is not a very realistic attack. The same section says: On the other hand, mishandling Trust Anchor is likely resulting in a validator unable to validate most of the traffic under the TA. I don't think this argument is particularly relevant, as an attacker with write access to the trust anchors would likely not replace any existing legitimate ones, but rather add the rogue one so that compromised traffic can be injected without causing validation errors otherwise. I don't think this document contains much valuable content for a DNSSEC operator. I think this document needs to have resolver vendors with their customer support experiences involved in evolving this document. Noting that only one of the people supporting adoption back in 2020 and offering reviews have contributed such reviews in the last three years (if I looked correctly), and considering that most feedback in the last 12 months has been in opposition to many of the recommendations given in the document (including several times due to serious inaccuracies about how DNSSEC works), I'm wondering if it is still on track. The draft was born almost 10 years ago and adopted more than three years ago; still, as Paul said, it's not clear that it contains much valuable content for a DNSSEC resolver operator. Perhaps the WG should consider abandoning it (although I'm not sure about the process). Best, Peter -- https://desec.io/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
