Re: [DNSOP] Dnsdir early review of draft-ietf-dnsop-qdcount-is-one-01
Really, cancel culture. It’s a couple of lines of code in a nameserver to support QCOUNT=0. It will take more time debating this than it took to implement support for QCOUNT=0. > On 19 Jan 2024, at 00:22, Joe Abley wrote: > > On 18 Jan 2024, at 13:42, Petr Špaček wrote: > >> The only piece missing to make it *perfect* is "MUST use QDCOUNT=1", or in >> other words, banning QDCOUNT=0 usage with DNS COOKIES. It's unnecessary >> complexity. > > I think these are two different suggestions: > > (1) Update the cookies spec to require QDCOUNT = 1 too > > (2) Apply a definitive restriction on QDCOUNT for all future opcodes, > imagined or otherwise. > > I would prefer (1) to happen in a different document if is to be done, since > there are cookies-specific conservations to be discussed and I don't think it > would make the current document clearer to go through them all here. There > are also different operational considerations based on what currently does or > doesn't happen in the wild. > > I'm not sure what I think about (2), at least partly because I'm always wary > about predicting the future. > > > Joe > ___ > 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] Resolver behaviour in the presence of unrequested answer records
As a what-one-stub-resolver-does data point... The resolver I'm most familiar with validates that all the CNAME records form a single chain from the query name, and that all answer records of the query type match the final name at the end of the CNAME chain. If that is not true, as in the case of this example, the entire DNS response is rejected. If there are any answer records with a type other than CNAME or the query type, they are simply ignored. On Thu, Jan 11, 2024 at 12:36 PM Bellebaum, Thomas < thomas.belleb...@aisec.fraunhofer.de> wrote: > Hello, > > We have been looking at some DNS resolvers and encountered a question: > > When a DNS response contains (in the answer section) records which were > not requested, how should the resolver react to those and what should > it return to the requesting client? > > For example: > > QUESTION: > example.com IN A > ANSWER: > example.com IN CNAME www.example.com > www.example.com IN A 3600 1.2.3.4 > google.comIN A 3600 5.6.7.8 > > We have noticed that even with DNSSEC enabled and all records in the > response being valid and signed, some resolvers return all records in > the answer section to the client. Note that recursive resolvers (as > well as network attackers on connections without integrity protection) > can combine records from different requests to synthesize such an > answer. > > Is the client responsible for identifying the requested RRSet or should > the resolver only return the records matching the request? > E.g. in the example above, should the client return all records in the > answer section or just the 1.2.3.4 A record? > > Some clues: > > - It is mentioned in RFC 1034 that the resolver should > communicate aliases (e.g. CNAMEs) to the client. > - Even when records not belonging to a chain of CNAME records are > removed from the answer section, simply filtering for the record type > may not be sufficient for the client (E.g. consider a QTYPE of CNAME > where during the resolution other CNAMEs are synthesized from DNAME > records.) > - DNSSEC would in some cases require checking NSEC/NSEC3 records while > following a chain of CNAME records. This can only happen in a resolver. > > Thanks in advance for any responses, > > Thomas Bellebaum > > -- > M.Sc. Thomas Bellebaum > Applied Privacy Technologies > Fraunhofer Institute for Applied and Integrated Security AISEC > > Lichtenbergstraße 11, 85748 Garching near Munich (Germany) > Tel. +49 89 32299 86 1039 <+49%2089%2032299861039> > thomas.belleb...@aisec.fraunhofer.de > https://www.aisec.fraunhofer.de > > ___ > 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] Dnsdir early review of draft-ietf-dnsop-qdcount-is-one-01
On 18 Jan 2024, at 13:42, Petr Špaček wrote: > The only piece missing to make it *perfect* is "MUST use QDCOUNT=1", or in > other words, banning QDCOUNT=0 usage with DNS COOKIES. It's unnecessary > complexity. I think these are two different suggestions: (1) Update the cookies spec to require QDCOUNT = 1 too (2) Apply a definitive restriction on QDCOUNT for all future opcodes, imagined or otherwise. I would prefer (1) to happen in a different document if is to be done, since there are cookies-specific conservations to be discussed and I don't think it would make the current document clearer to go through them all here. There are also different operational considerations based on what currently does or doesn't happen in the wild. I'm not sure what I think about (2), at least partly because I'm always wary about predicting the future. Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Dnsdir early review of draft-ietf-dnsop-qdcount-is-one-01
On 17. 01. 24 21:42, Matt Brown via Datatracker wrote: 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. I can attest that it _is_ seen in the wild every day in several customer's networks, but only in form of garbage queries and/or answers. To the best of my knowledge nothing depends on it. I wholeheartedly support the draft. The only piece missing to make it *perfect* is "MUST use QDCOUNT=1", or in other words, banning QDCOUNT=0 usage with DNS COOKIES. It's unnecessary complexity. -- Petr Špaček Internet Systems Consortium ___ 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 11. 01. 24 18:34, Bellebaum, Thomas wrote: Hello, We have been looking at some DNS resolvers and encountered a question: When a DNS response contains (in the answer section) records which were not requested, how should the resolver react to those and what should it return to the requesting client? For example: QUESTION: example.com IN A ANSWER: example.com IN CNAME www.example.com www.example.com IN A 3600 1.2.3.4 google.comIN A 3600 5.6.7.8 Tangentially related is very recent (two weeks old!) experiment which looked at handling unsolicited RRs in the AUTHORITY section. See https://chat.dns-oarc.net/community/pl/iyw9znj4wbgdfbbwwz1jjezt6o and the discussion following it. In case you don't have DNS-OARC chat login yet see https://www.dns-oarc.net/oarc/services/chat HTH. -- Petr Špaček Internet Systems Consortium ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
