Re: [DNSOP] [Ext] Compact DoE sentinel choice
On 7/24/23, 1:55 PM, "DNSOP on behalf of Viktor Dukhovni" wrote: >2. That said, there are multiple ways to *distinguish* ENT vs. NXDOMAIN >responses: > >a. Sentinel RTYPE for NXDOMAIN with just NSEC + RRSIG for ENT. >b. Sentinel RTYPE for ENT with just NSEC + RRSIG for NXDOMAIN. >c. Distinct sentinel RTYPEs for both ENTs and NXDOMAIN. > >Presently, the draft is proposing option "a". My point is that with "a" >we get a response that is promising the existence of an RRset for a name >that does not exist: Launching off this observation (and realizing there's a whole thread following it), I wanted to register some discomfort with this approach. The definition of DNSSEC in RFC 4035 contains this paragraph: # An NSEC record (and its associated RRSIG RRset) MUST NOT be the only # RRset at any particular owner name. That is, the signing process # MUST NOT create NSEC or RRSIG RRs for owner name nodes that were not # the owner name of any RRset before the zone was signed. The main # reasons for this are a desire for namespace consistency between # signed and unsigned versions of the same zone and a desire to reduce # the risk of response inconsistency in security oblivious recursive # name servers. What is most significant in that text is the "desire for namespace consistency between signed and unsigned versions of the same zone". With this proposal providing an answer that says "yes the name exists but it doesn't have what you want" contradicts the unsigned response that would indicate NXDOMAIN, there is an inconsistency in what is seen in the signed and unsigned zone. Note: I'm not trying to say "we have to stick to the old rules", I'm trying to look at the environment in which the DNSSEC was born and how we went from concept to reality (then). In some sense, this proposal is establishing a (set of) wildcard(s) (source[s] of synthesis) that owns just an NSEC record when it applies to otherwise NXDOMAIN responses. Mulling this over, it becomes apparent that the next name field in the NSEC record is a problem - wildcards allow for the inclusion of an owner name pulled from the query (and DNSSEC accommodates that via the label count) but there is no process for modifying the RDATA in a synthesized record. The lack of a process for modifying the RDATA means that "this is something entirely new". I think that signing on the fly is a great idea. But when DNSSEC was defined, and specifically here the NSEC record, it was assumed that DNSSEC records would be generated on machines air-gapped from the network because the state of the art in host security was simply poor. This forced the design to take on an approach of showing the querier "here's what I do have, you can deduce that your request has no answer (NXDOMAIN)". With signing on the fly, that approach makes no sense - you should be able to send a tailored response. A tailored response, i.e., "there's no name matching the QNAME", means there's no need to mention the next name. This would be great - no need to sort the zone, no need to assist zone walking, etc. The NSEC record is just not built for that though, it's an entirely ill-fit. We have the NSEC record, it's implemented and deployed. (I'm just not considering NSEC3 as it's similar in approach despite it working on hashes and not names.) Rolling out a new approach (say "NSEC17") would be an uphill battle (although we did roll out NSEC3...), assumed to be more work that force-fitting on-the-fly signing into NSEC. But I'm not so sure - because of the potential problems with inconsistencies introduced. I'm not saying "this can't work" - I'm raising a concern...and hoping some thought/work is done to come up with a new approach that is built to support the modern world. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] what could we do with 15 unused bits of QDCOUNT?
On Thu, Jul 27, 2023 at 09:11:33AM +1000, George Michaelson wrote: > if QDCOUNT is defined as [0|1] then we have 15 new bits of freedom in > the header. We don't actually have that freedom. There's no mechanism to make those bits mean something other than a larger (invalid QDCOUNT) for a normal query. > maybe the truth is, we've got 15 bits of zero in the header forever, amen. This. There's nothing we can do with the "extra bits" (and even if we could, that wouldn't better be done with a suitable EDNS(0) extension). The meaning of the message of course depends on the OPCODE. A new OPCODE can bring in new semantics for the rest of the packet. -- Viktor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] what could we do with 15 unused bits of QDCOUNT?
On Wed, Jul 26, 2023 at 5:09 PM Robert Edmonds wrote: > George Michaelson wrote: > > if QDCOUNT is defined as [0|1] then we have 15 new bits of freedom in > > the header. > > > > What would be interesting uses of the flow-label? Oh wait.. that's > > right, nobody really knows at scale how to use flow-label either. > > > > I tend to "use it for 15 bits of signalling" because there are a lot > > of things I wish were signalled from client to server. > > > > "I am new code" > > "I am at least not ancient code" > > "I'm the same as that other guy you saw over " > > "I like TCP and want to do a persisting session" > > "tell me if you are doing a|b|c|d" > > "I like chocolate and want a pony" > > > > maybe the truth is, we've got 15 bits of zero in the header forever, > amen. > > > > (I deliberately didn't put this in the draft- post from Ray so as not > > to pollute an objective discussion of what it is or is not the value > > proposition) > > > > clue-stick hits welcome. Avoid the stomach. > > > > -G > > With a maximum length QNAME inside a UDP query packet there are slightly > under a couple thousand bits available for EDNS. Those bits at the end > of the packet are easier to get to, ecosystem-wise, so if those use > cases are worthwhile they should probably be done with EDNS. > > It depends. E.g. one variable in the mix is UDP fragmentation, which can put the EDNS component outside the first fragment. Header bits are always in the first fragment, so depending on the specific attack scenario and deployment state of things (like avoid-fragmentation), entropy in the first packet is still valuable. Brian ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] what could we do with 15 unused bits of QDCOUNT?
I don't agree. My reasoning is that signals in the first 576 bytes are more likely to pass through non-conforming systems based on length alone. There is also John Scudder's observations on fast-path and slow-path processing: if its inside the state you latch EARLY when you see the packet, its far more likely to avoid CPU stalls and get done in firmware or hardware. (probably not strictly applicable, but I go to "flag early, flag often") But, for other reasons raised by other people, I concur that these bits are excluded from use because we don't have time travel and middleboxes make false assumptions. -G On Thu, Jul 27, 2023 at 10:08 AM Robert Edmonds wrote: > > George Michaelson wrote: > > if QDCOUNT is defined as [0|1] then we have 15 new bits of freedom in > > the header. > > > > What would be interesting uses of the flow-label? Oh wait.. that's > > right, nobody really knows at scale how to use flow-label either. > > > > I tend to "use it for 15 bits of signalling" because there are a lot > > of things I wish were signalled from client to server. > > > > "I am new code" > > "I am at least not ancient code" > > "I'm the same as that other guy you saw over " > > "I like TCP and want to do a persisting session" > > "tell me if you are doing a|b|c|d" > > "I like chocolate and want a pony" > > > > maybe the truth is, we've got 15 bits of zero in the header forever, amen. > > > > (I deliberately didn't put this in the draft- post from Ray so as not > > to pollute an objective discussion of what it is or is not the value > > proposition) > > > > clue-stick hits welcome. Avoid the stomach. > > > > -G > > With a maximum length QNAME inside a UDP query packet there are slightly > under a couple thousand bits available for EDNS. Those bits at the end > of the packet are easier to get to, ecosystem-wise, so if those use > cases are worthwhile they should probably be done with EDNS. > > -- > Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] what could we do with 15 unused bits of QDCOUNT?
George Michaelson wrote: > if QDCOUNT is defined as [0|1] then we have 15 new bits of freedom in > the header. > > What would be interesting uses of the flow-label? Oh wait.. that's > right, nobody really knows at scale how to use flow-label either. > > I tend to "use it for 15 bits of signalling" because there are a lot > of things I wish were signalled from client to server. > > "I am new code" > "I am at least not ancient code" > "I'm the same as that other guy you saw over " > "I like TCP and want to do a persisting session" > "tell me if you are doing a|b|c|d" > "I like chocolate and want a pony" > > maybe the truth is, we've got 15 bits of zero in the header forever, amen. > > (I deliberately didn't put this in the draft- post from Ray so as not > to pollute an objective discussion of what it is or is not the value > proposition) > > clue-stick hits welcome. Avoid the stomach. > > -G With a maximum length QNAME inside a UDP query packet there are slightly under a couple thousand bits available for EDNS. Those bits at the end of the packet are easier to get to, ecosystem-wise, so if those use cases are worthwhile they should probably be done with EDNS. -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] what could we do with 15 unused bits of QDCOUNT?
George Michaelson wrote on 2023-07-26 16:11: ... maybe the truth is, we've got 15 bits of zero in the header forever, amen. that's how i treated it when i crafted EDNS0. we'd have to negotiate any new use, and we've since learned that billions of middleboxes will treat that as a 16-bit field which must always be 0 or 1, no matter what the endpoints may have agreed to. clue-stick hits welcome. Avoid the stomach. i think that some 30 years before there was an RFC called "pervasive monitoring is an attack" there should have been an RFC called "middle boxes are an attack". forget about killing hitler's grandparents or whatever -- this is what a time machine is needed for. -- P Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] what could we do with 15 unused bits of QDCOUNT?
In the general case, you can't do anything with those bits for the same practical reason why we can't decide to allow QDCOUNT > 1. Too many existing servers expect that those bits can never be validly non-zero and will have unpredictable behavior. It's already out-of-our-control ossified. If we could do something with those bits (but we unfortunately can't), my recommendation would be to use them to allow QDCOUNT > 1. :P On Wed, Jul 26, 2023 at 7:32 PM Mark Andrews wrote: > > > > On 27 Jul 2023, at 09:20, Brian Dickson > wrote: > > > > > > > > On Wed, Jul 26, 2023 at 4:12 PM George Michaelson > wrote: > > if QDCOUNT is defined as [0|1] then we have 15 new bits of freedom in > > the header. > > > > What would be interesting uses of the flow-label? Oh wait.. that's > > right, nobody really knows at scale how to use flow-label either. > > > > I tend to "use it for 15 bits of signalling" because there are a lot > > of things I wish were signalled from client to server. > > > > "I am new code" > > "I am at least not ancient code" > > "I'm the same as that other guy you saw over " > > "I like TCP and want to do a persisting session" > > "tell me if you are doing a|b|c|d" > > "I like chocolate and want a pony" > > > > maybe the truth is, we've got 15 bits of zero in the header forever, > amen. > > > > (I deliberately didn't put this in the draft- post from Ray so as not > > to pollute an objective discussion of what it is or is not the value > > proposition) > > > > clue-stick hits welcome. Avoid the stomach. > > > > 15 bits of entropy would maybe be a good use, particularly for short > QNAMEs (and with QNAME minimization, that definitely applies to root and > TLD queries). > > That would augment or compensate for fewer bits available for 0x20 > entropy. > > Or root and TLD servers could just deploy DNS COOKIE. There is no reason > for them not to deploy > DNS COOKIE today other than vendors not implementing it. Time for vendors > to pull their fingers > out. > > DNS COOKIE is standards track. It is a security fix. Deploy it. > > > > > Brian > > ___ > > DNSOP mailing list > > DNSOP@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsop > > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 <+61%202%209871%204742> INTERNET: > ma...@isc.org > > ___ > 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] what could we do with 15 unused bits of QDCOUNT?
> On 27 Jul 2023, at 09:20, Brian Dickson wrote: > > > > On Wed, Jul 26, 2023 at 4:12 PM George Michaelson wrote: > if QDCOUNT is defined as [0|1] then we have 15 new bits of freedom in > the header. > > What would be interesting uses of the flow-label? Oh wait.. that's > right, nobody really knows at scale how to use flow-label either. > > I tend to "use it for 15 bits of signalling" because there are a lot > of things I wish were signalled from client to server. > > "I am new code" > "I am at least not ancient code" > "I'm the same as that other guy you saw over " > "I like TCP and want to do a persisting session" > "tell me if you are doing a|b|c|d" > "I like chocolate and want a pony" > > maybe the truth is, we've got 15 bits of zero in the header forever, amen. > > (I deliberately didn't put this in the draft- post from Ray so as not > to pollute an objective discussion of what it is or is not the value > proposition) > > clue-stick hits welcome. Avoid the stomach. > > 15 bits of entropy would maybe be a good use, particularly for short QNAMEs > (and with QNAME minimization, that definitely applies to root and TLD > queries). > That would augment or compensate for fewer bits available for 0x20 entropy. Or root and TLD servers could just deploy DNS COOKIE. There is no reason for them not to deploy DNS COOKIE today other than vendors not implementing it. Time for vendors to pull their fingers out. DNS COOKIE is standards track. It is a security fix. Deploy it. > > Brian > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] what could we do with 15 unused bits of QDCOUNT?
I like your idea! Another one is to reserve n bits for the length of the resolver/forwarder chain to the answer. if you pass it on, increment the n bits. preserve it in the answer. would permit authorities, and clients to know how long the chain is behind the answers they see and questions made. I posit 3 bits would be plenty. -G ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] what could we do with 15 unused bits of QDCOUNT?
On Wed, Jul 26, 2023 at 4:12 PM George Michaelson wrote: > if QDCOUNT is defined as [0|1] then we have 15 new bits of freedom in > the header. > > What would be interesting uses of the flow-label? Oh wait.. that's > right, nobody really knows at scale how to use flow-label either. > > I tend to "use it for 15 bits of signalling" because there are a lot > of things I wish were signalled from client to server. > > "I am new code" > "I am at least not ancient code" > "I'm the same as that other guy you saw over " > "I like TCP and want to do a persisting session" > "tell me if you are doing a|b|c|d" > "I like chocolate and want a pony" > > maybe the truth is, we've got 15 bits of zero in the header forever, amen. > > (I deliberately didn't put this in the draft- post from Ray so as not > to pollute an objective discussion of what it is or is not the value > proposition) > > clue-stick hits welcome. Avoid the stomach. > 15 bits of entropy would maybe be a good use, particularly for short QNAMEs (and with QNAME minimization, that definitely applies to root and TLD queries). That would augment or compensate for fewer bits available for 0x20 entropy. Brian ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] what could we do with 15 unused bits of QDCOUNT?
if QDCOUNT is defined as [0|1] then we have 15 new bits of freedom in the header. What would be interesting uses of the flow-label? Oh wait.. that's right, nobody really knows at scale how to use flow-label either. I tend to "use it for 15 bits of signalling" because there are a lot of things I wish were signalled from client to server. "I am new code" "I am at least not ancient code" "I'm the same as that other guy you saw over " "I like TCP and want to do a persisting session" "tell me if you are doing a|b|c|d" "I like chocolate and want a pony" maybe the truth is, we've got 15 bits of zero in the header forever, amen. (I deliberately didn't put this in the draft- post from Ray so as not to pollute an objective discussion of what it is or is not the value proposition) clue-stick hits welcome. Avoid the stomach. -G ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] FW: [Maprg] Agenda for maprg at 117
Hi DNS community, please find below the maprg agenda with at least two talks related to DNS. Hope to see you all on Friday! Mirja On 26.07.23, 22:46, "Maprg on behalf of Mirja Kuehlewind" wrote: Hi all, just a quick announcement about our final agenda for our maprg session on Friday, 9:30-11:30 in Continental 6: https://datatracker.ietf.org/meeting/117/materials/agenda-117-maprg-05 We have some really nice talks! See you all on Friday (in-person or remote)! Mirja & Dave -- IRTF maprg agenda for IETF-116 (San Francisco) Date: Friday, 28 July 2023, Session I 0930-1130 Full client with Video: https://meetecho.ietf.org/conference/?group=maprg=maprg=1 Room: Continental 6 IRTF Note Well: https://irtf.org/policies/irtf-note-well-2019-11.pdf Agenda Overview and Status - Mirja/Dave (5 min) Internet Scale Reverse Traceroute - Kevin Vermeulen (remote) (15 mins) Web Privacy By Design: Evaluating Cross-layer Interactions of QUIC, DNS and H/3 - Jayasree Sengupta (remote) (15 mins) Exploring the Cookieverse: A Multi-Perspective Analysis of Web Cookies - Ali Rasaii (remote) (15 mins) User Awareness and Behaviors Concerning Encrypted DNS Settings in Web Browsers - Nick Feamster (remote) (15 mins) IPvSeeYou: Exploiting Leaked Identifiers in IPv6 for Street-Level Geolocation - Robert Beverly (15 mins) Measurement Lab: Supporting Open Internet Research - Lai Yi Ohlsen (remote) (15 mins) ___ Maprg mailing list ma...@irtf.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] WGLC rfc8499bis for revised lame delegation definition
Hi kc, On 17/07/2023 21:41, k claffy wrote: I agree it would greatly help to include the more precise terms. Note that Scott's current EPP draft is still using this term, citing the definition in 1912. Should the term be removed from Scott's draft, or acknowledged that it is now historic? If Scott replaces it with another more precise term, can we get that term in this document so that future uses can cite this document? Alternatively, instead of deprecating, the last sentence of that paragraph could be "Because...and now is not specific or clear as to the intended meaning, sufficient context may be required to remove undesired ambiguity." ( similar to 'validating resolver'? ) Thank you for your remarks. The chairs acknowledge that more precise terms are useful and desirable. For progress, we decided not to include newer terms of different types of broken delegation in the current rfc8499bis. More discussion on these terms is required, and the chairs and authors of the document feel that this should be written down in another draft. We would like to invite you or other DNSOP participants to put your thoughts in a new draft to discuss with the WG and to come to more precise definitions of various broken delegations. This new draft (RFC) can later be referenced by the DNS Terminology document. Best regards, -- Benno ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] The DNSOP WG has placed draft-bash-rfc7958bis in state "Candidate for WG Adoption"
The DNSOP WG has placed draft-bash-rfc7958bis in state Candidate for WG Adoption (entered by Tim Wicinski) The document is available at https://datatracker.ietf.org/doc/draft-bash-rfc7958bis/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] The DNSOP WG has placed draft-bellis-dnsop-qdcount-is-one in state "Candidate for WG Adoption"
The DNSOP WG has placed draft-bellis-dnsop-qdcount-is-one in state Candidate for WG Adoption (entered by Tim Wicinski) The document is available at https://datatracker.ietf.org/doc/draft-bellis-dnsop-qdcount-is-one/ Comment: Waiting for revision ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] The DNSOP WG has placed draft-thomassen-dnsop-generalized-dns-notify in state "Candidate for WG Adoption"
The DNSOP WG has placed draft-thomassen-dnsop-generalized-dns-notify in state Candidate for WG Adoption (entered by Tim Wicinski) The document is available at https://datatracker.ietf.org/doc/draft-thomassen-dnsop-generalized-dns-notify/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] WGLC rfc8499bis for revised lame delegation definition
Dear WG, Thank you for your thoughtful feedback during the WGLC for the revised lame delegation definition. With this email, we close the WGLC for rfc8499bis. With the discussion and feedback during the interim and with the WGLC on the mailing list, the chairs have determined there is rough consensus on the proposed wording on lame delegation, and as it is now included in the latest revision of rfc8499bis on datatracker. After the document shepherd write-up, the document is sent to the IESG as the next step. Best regards, -- Benno On 18/07/2023 08:17, Havard Eidnes wrote: Note that Scott's current EPP draft is still using this term, citing the definition in 1912. Should the term be removed from Scott's draft, or acknowledged that it is now historic? If Scott replaces it with another more precise term, can we get that term in this document so that future uses can cite this document? [SAH] My draft uses the term in only one place where it describes practices that can "introduce risks of lame delegation". I'm inclined to change that sentence to something like "introduce risks of invalid DNS delegation" to avoid the term completely if it eliminates the need for a normative reference that doesn't yet exist. Don't take this the wrong way -- I'm not picking on you presonally... But I think this illustrates one of the problems with coming up with "specific and clear" alternatives to the "lame delegation" characterization which is also brief, precise, and doesn't have too wide difference to normal-language usage. Because... Even though my first language is not English, I would have thought that it ought to be possible to distinguish between a "valid" and an "invalid" delegation without querying for the actual current operational state wrt. to the given zone, i.e. there has to be some evident "rule violation" involved. Quoting the Merriam-Webster dictionary: invalid : not valid: a : being without foundation or force in fact, truth, or law | an invalid assumption | declared the will invalid b : logically inconsequent The most relevant part here would be "without foundation in ... law", if we consider the RFCs "law" within this area, which isn't too far- fetched. E.g. it would IMHO be "invalid" to use an NS record with a name server name which contains "_" in its name, because there is at least a deep- seated convention (if not a rule from ... rfc 952?) that host names, i.e. names which resolve to A and/or records (and therefore, by extension, name server names), should not contain "_" in their owner name (by default enforced by BIND to this day, when loading an authoritative zone), i.e. "it explicitly goes against the rules". (And, yes, I know that not everyone agrees with this rule...) I would claim the flavour is distinctly different, and that "invalid delegation" is not a good substitute for "lame delegation". Regards, - Håvard ___ 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] A question on values in draft-dnsop-caching-resolution-failures
Duane/Evan/Mukund/All, What do feel is the consensus on lowering the value to 1 second ? >From the previous suggested text: Resolvers MUST cache resolution failures for at least 1 second. The initial duration SHOULD be configurable by the operator. A longer cache duration for resolution failures will reduce the processing burden from repeated queries, but will also lengthen the recovery period from transitory issues. It does sound like this paragraph works better. Resolvers SHOULD employ an exponential or linear backoff algorithm to increase the amount of time for subsequent resolution failures. For example, the initial time for negatively caching a resolution failure is set to 5 seconds. The time is increased after each retry that results in another resolution failure. Consistent with [RFC2308], resolution failures MUST NOT be cached for longer than 5 minutes. May we get some feedback on this? thanks tim On Mon, Jul 24, 2023 at 11:41 AM Evan Hunt wrote: > On Mon, Jul 24, 2023 at 06:26:46PM +, Wessels, Duane wrote: > > It was not our intention that “2” would be the only possible exponent in > > the backoff algorithm. Would this slightly revised text be more > > agreeable? > > > >Resolvers SHOULD employ an exponential or linear backoff algorithm to > >increase the amount of time for subsequent resolution failures. For > >example, the initial time for negatively caching a resolution failure > >is set to 5 seconds. The time is increased after each retry that > >results in another resolution failure. Consistent with [RFC2308], > >resolution failures MUST NOT be cached for longer than 5 minutes. > > That's definitely an improvement, yes. > > -- > Evan Hunt -- e...@isc.org > Internet Systems Consortium, Inc. > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] I-D Action: draft-ietf-dnsop-structured-dns-error-06.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This Internet-Draft is a work item of the Domain Name System Operations (DNSOP) WG of the IETF. Title : Structured Error Data for Filtered DNS Authors : Dan Wing Tirumaleswar Reddy Neil Cook Mohamed Boucadair Filename: draft-ietf-dnsop-structured-dns-error-06.txt Pages : 22 Date: 2023-07-26 Abstract: DNS filtering is widely deployed for various reasons, including network security. However, filtered DNS responses lack structured information for end users to understand the reason for the filtering. Existing mechanisms to provide explanatory details to end users cause harm especially if the blocked DNS response is for HTTPS resources. 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. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-structured-dns-error/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-dnsop-structured-dns-error-06.html A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-structured-dns-error-06 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Compact DoE sentinel choice
on "mollify". Viktor Dukhovni wrote on 2023-07-25 22:59: On Tue, Jul 25, 2023 at 08:19:21PM -0700, Brian Dickson wrote: At the name that does not exist, generate and sign (on the fly) a CNAME record with RDATA of something like "nxname.empty.as112.arpa" (or something functionally equivalent). Sadly, this reports that the CNAME *target* does not exist, but the name in question certainly does (it holds a CNAME). This also does not exclude the existence of subdomains of the name (which NXDOMAIN does, when one isn't bending over backwards to interoperate with servers that return NXDOMAIN for ENTs!). Also, with the target zone unsigned, the response is subject to forgery, returning real data for the target. Only one signature is required, since there is an answer, rather than just an NSEC(3) with bitmap. Does it mollify the folks who want an NXDOMAIN signal? I guess it is not obviosly worse than an apparent NODATA, and the target could even be a fixed non-existent name in a suitable zone under control of the signer, which would have a real (signed) NXDOMAIN proof, avoiding an unsigned target in as112. But I remain sceptical about the wisdom of such a design. as a pattern intended to replace signed nxdomain for those dnssec authorities with an allergy to responses larger than 512 octets, a bespoke cname would be a bad thing. however a validly signed cname to validly signed nonexistent name would be fine, because the rcode in that case would be 3 in the rdns->stub response. i'm not sure how this would solve the 512 octet allergy threshold though. olafur's original reasoning in the CF blog post was that since a client would take the same next step if it received noerror/nodata as it would if it received nxdomain, CF would be sending the shorter of these two apparently equivalent signals. i disagreed, partly because there would be a second query for A if a query for MX or for returned noerror/nodata but not if it returned nxdomain, but mostly because DGA botnets can be detected in formation by looking at nxdomain storms, but not by looking at noerror/nodata storms. any of the proposals that restore unambiguity to the name-doesn't-exist condition are fine by me. notably, i'd vastly prefer signed nxdomain, which most dnssec authorities don't have a 512 octet allergy threshold for, including dnssec authorities who send a _lot_ more nxdomain answers than any CDN send. however, if that won't be done, let there be an RFC for some new more complex signal pattern to describe the trifecta of "nxdomain, nonexistence proof, nonwildcard proof" condition. ENTs are distinguishable (they would get the current ENT response of NSEC/RRSIG bit map) Well current, by the book, ENT response is NOT NSEC/RRSIG (unless you mean current compact denial rule-bending behaviour). Rather for a standard ENT, we have: enszzz.example. IN aaa.ent.example. IN NSEC NSEC RRSIG A ... The ENT is just an ancestor of the "next" name in a covering NSEC record. very few of the lookups where noerror/nodata vs. nxdomain ambiguity is problematic are nonterminals. if that's making a solution elusive, feel free to note that ENTs aren't nonexistent, so Compact DoE doesn't apply. Am I incorrect in the asserted behavior of such a synthesized CNAME (and that it would match the requirements)? It would be a stretch. Mind you, with a target in globally shared zone, caching of its non-existence saves followup queries for all zone using the scheme. If the target is signed and has a long negative TTL, efficiency is retained, but it we don't get "nothing below" semantics, and with some auths mixing CNAME and other data, don't even necessarily conclude there's no other data at the name. it would be a hack. but not intolerable if the target wasn't bespoke. you can get the same caching efficiencies from a per-CDN "Negative Zone"(*) since it would be receiving CNAME chains from many millions of customer domains. (*) https://en.wikipedia.org/wiki/Negative_Zone So I am disinclined to go there, barring lots of evidence that it actually satisfies the various motivating use-cases and has broad support. be too, but if so it still deserves to be a Road Not Taken in the RFC, along with a pointer to the wikipedia page above. -- P Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
