Re: [DNSOP] [dnsdir] Dnsdir early review of draft-ietf-dnsop-qdcount-is-one-01
> On 17 Jan 2024, at 20:42, Matt Brown via Datatracker via dnsdir > wrote: > > Reviewer: Matt Brown > Review result: Ready > > I have been selected as the DNS Directorate reviewer for this draft. > The draft itself is clear and understandable. Both the language and the > substance of the proposal make sense to me. > > Given this previous discussion and clarity of proposal I see no blockers or > issues for the ADs to consider and recommend this draft is ready to be > progressed further. Excellent! Many thanks for your review Matt. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Dnsdir early review of draft-ietf-dnsop-qdcount-is-one-01
Reviewer: Matt Brown Review result: Ready I have been selected as the DNS Directorate reviewer for this draft. The DNS Directorate seeks to review all DNS or DNS-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the ADs. For more information about the DNS Directorate, please see https://wiki.ietf.org/en/group/dnsdir This draft proposes addition of normative language updating RFC1035 to specify that QDCOUNT must not be > 1 for OPCODE=0 (QUERY) DNS requests. The intent is to eliminate present ambiguity in the specification where QDCOUNT is not required to be <= 1, but (as described by section A.1 and A.5 of the draft) in practical terms given the meaning of other fields (AA) and the surrounding language in RFC1035 it is undefined how such a question should or even could be interpreted and usefully responded to. The proposal has been discussed in the dnsop group and previous meetings and my observation of the discussion is that there is both broad agreement that QDCOUNT > 1 is not used in practice and at least some supporting evidence presented that it is not observed in the wild either. The draft itself is clear and understandable. Both the language and the substance of the proposal make sense to me. Given this previous discussion and clarity of proposal I see no blockers or issues for the ADs to consider and recommend this draft is ready to be progressed further. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Resolver behaviour in the presence of unrequested answer records
On Jan 17, 2024, at 05:15, Bellebaum, Thomas wrote: > > 1. Caching of unrequested RRs would actually be fine, if they are > properly signed. At worst, a resolver would cache irrelevant records. This is not entirely true. By tailoring someone’s cache you might be able to track them. There is definitely a privacy aspect here. > 2. It is the usage of irrelevant records by the application which is > causing the problem. You could reproduce this problem without any > caches involved. They could become relevant later on when they are already in the cache ? Eg the google.con example ? The user later on browses google.com. This is not an application using “irrelevant records” Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Poll to select DNSOP Interim meeting last week January
Dear DNSOP WG, I closed the doodle poll to select a suitable day and time. The selected day and time is *January 30, 2024, 17:00-18:00 UTC*. I will schedule the interim in the datatracker and more information about the interim meeting will appear on the mailing list. Best regards, -- Benno On 12/01/2024 13:34, Benno Overeinder wrote: Dear DNSOP WG, The authors and contributors of the DELEG document have made good progress since the IETF 118 meeting, where they initially presented their ideas. During the IETF 118 DNSOP meeting, Petr Spacek shared the outcomes of the two-day Hackathon session and introduced the initial concepts related to DELEG. For presentation slides, please refer to: https://datatracker.ietf.org/meeting/118/materials/slides-118-dnsop-hackaton-118-deleg-rr-proposal-00. The chairs have engaged with the document's authors and contributors, and it appears that the end of January is an opportune time to share the progress, current status, and future plans to the DNSOP WG participants. In early February, some of the contributors will meet in person to address various issues, and feedback from the DNSOP WG prior to this gathering would be highly beneficial. This timeframe also allows for ongoing work on a number of topics that can be presented at the IETF 119 meeting in March 2024. To coordinate the interim meeting, we have created a doodle to determine a suitable day and time. Kindly complete the doodle before Tuesday, January 16 (end of business day): * https://doodle.com/meeting/participate/id/b2G7kMJd The authors and contributors are actively working on drafts available in the following GitHub repository: https://github.com/fl1ger/deleg. Best regards, Suzanne, Tim and Benno ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- Benno J. Overeinder NLnet Labs https://www.nlnetlabs.nl/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Resolver behaviour in the presence of unrequested answer records
> That's cache poisoning. Search for "Eugene Kashpureff" to learn all > about it. There is a relation in the sense that checking RRs for relevance to the query is mentioned as a partial defense against cache poisoning in RFC 3833, section 2.3. Note however some differences: 1. Caching of unrequested RRs would actually be fine, if they are properly signed. At worst, a resolver would cache irrelevant records. 2. It is the usage of irrelevant records by the application which is causing the problem. You could reproduce this problem without any caches involved. The confusion seems to arise in RFC 1034, section 5.3.3, which states: > a. if the response answers the question or contains a name >error, cache the data as well as returning it back to >the client. But what exactly "the data" is (or, going with RFC 3833, how "relevance" is determined), does not seem to be specified anywhere, at least not in rigorous algorithmical form. Best regards, - Thomas smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
