Re: [DNSOP] draft-ietf-dnsop-rfc7816bis: hopefully ready for WG Last Call
Sorry for not thinking of these earlier, not sure if they would add anything or clarify anything or potentially protect resolvers from DOS attacks: - Maybe some text warning about queries with excessive numbers of labels, and suggestions for limiting their impact? E.g. "If NUM_LABELS is more than 6, follow the algorithm for the first N labels (TBD for N), then do a binary search on the remaining labels at each zone cut discovered." - Would it make sense to address ENTs (empty non-terminals), or use one of those in an example? Also, in zones signed with NSEC, is there any potential advantage to using NSEC records to "skip ahead" through the list of labels, if ENTs exist with no non-ENT siblings between the CHILD query and the actual zone cut? Either of these might reduce the work, while still preserving the benefits of QNAME minimization, I believe. Brian On Mon, Sep 28, 2020 at 12:17 PM Paul Hoffman wrote: > Greetings again. We have not heard much recent input on the draft other > than "remove the parts about it being experimental". We have done that, > reorganized it to make it clear that QNAME minimisation is already > well-deployed, and a few other cleanups. > > We think the document is read for WG Last Call, if the chairs do as well. > > --Paul Hoffman___ > 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] draft-ietf-dnsop-rfc7816bis: hopefully ready for WG Last Call
Dave Lawrence wrote: > > Could you please clarify explicitly what should happen in the case of > encountering CNAMEs? Or DNAMEs? I guess when I originally sketched a qname minimization algorithm https://mailarchive.ietf.org/arch/msg/dns-privacy/gAgGx9Zz6W0OfyRdJ0Rx7xxmHDg/ I intended that it would slot into the RFC 1034 resolver algorithm https://tools.ietf.org/html/rfc1034#section-4.3.2 which treats QNAME as a variable name rather than a protocol field, so the QNAME changes when the resolver chases a CNAME. That was probably a bad idea: on balance I think it's better to make a clear distinction between protocol fields and variables in algorithms. Elsewhere RFC 1034 uses SNAME for the variable containing the name we are searching for https://tools.ietf.org/html/rfc1034#section-5.3.3 which would be better if it hadn't used QNAME for the same thing elsewhere :-) Tony. -- f.anthony.n.finchhttp://dotat.at/ Fitzroy: Easterly 6 to gale 8, becoming cyclonic 5 to 7. Rough or very rough, becoming moderate or rough later. Thundery showers. Good, occasionally poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-rfc7816bis: hopefully ready for WG Last Call
Thanks for the work on this, Stephane, Ralph, and Paul. Could you please clarify explicitly what should happen in the case of encountering CNAMEs? Or DNAMEs? The way I read it, at least for CNAMEs, is that you just keep prepending labels to the ANCESTOR name so encountering the CNAME is in practice no different from encountering any rrtype other than NS. This would also be consistent with the existing DNS not having any prohibition of data beneath a CNAME, such that we can fetch data for foo.bar.example.com even in the presence of a bar.example.com CNAME. Ralph's original presentation for OARC 24 though had a different implication on slide 11 that, in the absence of speaker explaining it to me, implies that encountering a CNAME ... well, I'm not sure. https://www.nlnetlabs.nl/downloads/presentations/unbound_qnamemin_oarc24.pdf#page=11 With the word "change" there and the arrows it says to me that it's doing a query restart on the CNAME and continuing onward with the minimisation algorithm from there. And it's mentioned right there with referrals as something parenthetically noteworthy. How do BIND andc Unbo,und currently handle this? I'm guessing both like the way described by the algorithm. It'd help future implementers to have explicit guidance. Perhaps something like: (6b) All other NOERROR answers (either positive or negative). Cache this answer. Regardless of the answered RRset type, including CNAMEs, continue with the algorithm from step 3 by building on the original QNAME. I changed it to "All other" because 6a is also a NOERROR answer. I orthogonally think you should make that change, even if my other text is rejected. I'm not feeling great about my wordsmithing, but I made an effort under the "please send text" maxim. Or maybe this should just be an unnumbered note at the end of the section, saying something like: Note that in this algorithm, encountering a CNAME is no different from encountering other non-referral positive answers. They are not followed when discovered for intermediate labels. Always use the labels of the original QNAME. Then have an example cover this case in section 4, maybe just by using NOTE to observe it could be "any positive answer, even CNAME". Doesn't fit on the line well though. Oh and for DNAME ... maybe in 6a describe that it's also a referral, one that should set CHILD to the target and resume the algorithm at step 5? That seems maybe insufficient, but it's a starting point for thinking about. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-rfc7816bis: hopefully ready for WG Last Call
On 23-10-2020 00:12, Tony Finch wrote: > Ralph Dolmans wrote: >> >> Thanks for your feedback, appreciated! > > Thanks for the response! > > I thought of another thing: > > Some of the points in section 5 (on limiting the number of queries and the > performance downsides) should be discussed in section 7 (security > considerations). In particular QNAME minimization can amplify query volume > so it can be abused to make random subdomain attacks worse, though that > can be mitigated by RFC 8020 NXDOMAIN. Mentioning it in the security considerations makes sense. Note that RFC8020 won't help you here when the answer is synthesized using a wildcard, which is also why the example in section 5 has a wildcard record. Happy to make this more explicit in the text. Thanks, Ralph ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-rfc7816bis: hopefully ready for WG Last Call
Ralph Dolmans wrote: > > Thanks for your feedback, appreciated! Thanks for the response! I thought of another thing: Some of the points in section 5 (on limiting the number of queries and the performance downsides) should be discussed in section 7 (security considerations). In particular QNAME minimization can amplify query volume so it can be abused to make random subdomain attacks worse, though that can be mitigated by RFC 8020 NXDOMAIN. Tony. -- f.anthony.n.finchhttp://dotat.at/ the quest for freedom and justice can never end ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-rfc7816bis: hopefully ready for WG Last Call
Stephane Bortzmeyer wrote:
> Tony Finch wrote:
>
> > Section 3, algorithm step 5: what is a "hidden QTYPE"?
>
> The original QTYPE, which may be "hidden" by a substitution to another
> QTYPE (see section 2 "a QTYPE selected by the resolver to hide the
> original QTYPE"). This was not in RFC 7816. Would you prefer we settle
> on "original QTYPE"?
I don't have a preference for any particular term, just that terminology
should be defined and used in a consistent way throughout the spec, so
that if you grep the draft for "hidden" (or whatever) you can find out
what what it means, and you can easily find every place where it is
relevant. ("elegant variation" is a bad thing in technical writing.)
> > Step 6, what is the "minimised QTYPE"?
>
> The opposite of "hidden QTYPE", it is the QTYPE choosen by the
> resolver (NS was recommended in RFC 7816, but it is A in 7816-bis).
Tony.
--
f.anthony.n.finchhttp://dotat.at/
Great Orme Head to the Mull of Galloway: West 4, backing southwest 5 to 7,
veering west 4 to 6 later. Slight or moderate. Rain for a time, showers later.
Good, occasionally moderate.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-rfc7816bis: hopefully ready for WG Last Call
Hi Tony, Thanks for your feedback, appreciated! On 14-10-2020 20:15, Tony Finch wrote: > A few questions and suggestions: > > Section 3, algorithm step 5: what is a "hidden QTYPE"? The QTYPE in the incoming query. We made the text more consistent and now always use "original QTYPE". > > Also step 5, a NOERROR answer can be positive or negative, so I think it > should be made clear that this is about a non-NXDOMAIN negative cache > entry. (RFC 2308 calls these "NODATA".) NOERROR can indeed be positive and negative, which is intentional. Also when you have a positive cache result in this step you know that there is no delegation at this level and therefore can add an extra label. I'm ok with making it more clear by explicitly saying that it can be both positive and negative. > > Step 6, what is the "minimised QTYPE"? The term is defined by implication > in section 2, but a reader can't find the definition by searching for the > term. The QTYPE selected by the resolver to do QNAME minimisation. We now changed it to "selected QTYPE" to hopefully make it easier to understand. > > Step 6b, again NOERROR can be positive or negative. I think either this > needs to be more specific, or it should explicitly say it covers both > cases. Both cases indeed. Made that more explicit in the text. > > Step 6c, CHILD might not be the full original QNAME at this point, so it's > only correct to stop on NXDOMAIN here if the resolver is doing RFC 8020 > strict NXDOMAIN. Agree. And without RFC8020 support you should go back to step 3. Added to the text. > > Editorial suggestion: the wall of text in section 2 could do with some > subheadings or bullet points. It would be helpful to make a more clear > separation between rationale/discussion and normative text. I don't have a strong opinion on separating between rationale and normative text. Adding subheadings is a good suggestion. > > I'm not a fan of the term "aggressive" since it sounds unpleasantly > fighty. And I'm not sure how it helps a reader to understand this draft: > AIUI angry vs friendly is supposed to be about the QTYPE used for > truncated query names; the algorithm in section 3 does not depend on this > choice, so I don't know why it is specifically the nasty algorithm. And > section 2 seems to imply the existence of a nice algorithm but there isn't > a specification of it. And why is the choice of QTYPE emotional, but the > number of labels to add is not? This is a leftover from an older version. There now is only one way to do QNAME minimisation, so no need to name it. We removed the "aggressive" references. > > Both section 5 and section 6 seem to be about performance, the problems > and possible benefits, but only the possible benefits count as performance > considerations. I think the question of how many labels to add on each > iteration should be a core part of QNAME minimization, described in > section 2. I'm ok with moving the text from section 5 to a subsection of 2. Thanks! -- Ralph ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-rfc7816bis: hopefully ready for WG Last Call
On Wed, Oct 14, 2020 at 07:15:10PM +0100, Tony Finch wrote a message of 53 lines which said: > Section 3, algorithm step 5: what is a "hidden QTYPE"? The original QTYPE, which may be "hidden" by a substitution to another QTYPE (see section 2 "a QTYPE selected by the resolver to hide the original QTYPE"). This was not in RFC 7816. Would you prefer we settle on "original QTYPE"? > Step 6, what is the "minimised QTYPE"? The opposite of "hidden QTYPE", it is the QTYPE choosen by the resolver (NS was recommended in RFC 7816, but it is A in 7816-bis). ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-rfc7816bis: hopefully ready for WG Last Call
A few questions and suggestions: Section 3, algorithm step 5: what is a "hidden QTYPE"? Also step 5, a NOERROR answer can be positive or negative, so I think it should be made clear that this is about a non-NXDOMAIN negative cache entry. (RFC 2308 calls these "NODATA".) Step 6, what is the "minimised QTYPE"? The term is defined by implication in section 2, but a reader can't find the definition by searching for the term. Step 6b, again NOERROR can be positive or negative. I think either this needs to be more specific, or it should explicitly say it covers both cases. Step 6c, CHILD might not be the full original QNAME at this point, so it's only correct to stop on NXDOMAIN here if the resolver is doing RFC 8020 strict NXDOMAIN. Editorial suggestion: the wall of text in section 2 could do with some subheadings or bullet points. It would be helpful to make a more clear separation between rationale/discussion and normative text. I'm not a fan of the term "aggressive" since it sounds unpleasantly fighty. And I'm not sure how it helps a reader to understand this draft: AIUI angry vs friendly is supposed to be about the QTYPE used for truncated query names; the algorithm in section 3 does not depend on this choice, so I don't know why it is specifically the nasty algorithm. And section 2 seems to imply the existence of a nice algorithm but there isn't a specification of it. And why is the choice of QTYPE emotional, but the number of labels to add is not? Both section 5 and section 6 seem to be about performance, the problems and possible benefits, but only the possible benefits count as performance considerations. I think the question of how many labels to add on each iteration should be a core part of QNAME minimization, described in section 2. (I keep expecting the Oxford spelling "minimize"...) Tony. -- f.anthony.n.finchhttp://dotat.at/ Fitzroy: Northerly or northeasterly 3 to 5, becoming variable 4 or less in west, then southerly 5 or 6 in northwest. Moderate, occasionally rough at first in northeast. Showers. Good. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] draft-ietf-dnsop-rfc7816bis: hopefully ready for WG Last Call
Greetings again. We have not heard much recent input on the draft other than "remove the parts about it being experimental". We have done that, reorganized it to make it clear that QNAME minimisation is already well-deployed, and a few other cleanups. We think the document is read for WG Last Call, if the chairs do as well. --Paul Hoffman smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
