[DNSOP] I-D Action: draft-ietf-dnsop-structured-dns-error-00.txt
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 : Structured Error Data for Filtered DNS Authors : Dan Wing Tirumaleswar Reddy Neil Cook Mohamed Boucadair Filename: draft-ietf-dnsop-structured-dns-error-00.txt Pages : 19 Date: 2023-02-13 Abstract: DNS filtering is widely deployed for network security, but filtered DNS responses lack information for the end user to understand the reason for the filtering. Existing mechanisms to provide detail to end users cause harm especially if the blocked DNS response is to an HTTPS website. This document updates RFC 8914 by 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. Other than that, this document does not change any thing written in RFC 8914. The IETF datatracker status page for this 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-00.html 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] QDCOUNT > 1 (a modest proposal)
Ted Lemon wrote: FWIW, I don't think it precludes doing queries with QDCOUNT > 1 to the cache 1034: 3.7.1. Standard queries A standard query specifies a target domain name (QNAME), query type (QTYPE), and query class (QCLASS) and asks for RRs which match. which *DID* not preclude inverse queries with QDCOUNT=0 and responses to them with QDCOUNT>1 as is stated in 1035: When the response to an inverse query contains one or more QNAMEs, Anyway, w.r.t. letency, it is meaningless to have standard queries with QDCOUNT>1. Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] QDCOUNT > 1 (a modest proposal)
Thanks. What you describe in the document certainly makes sense, but I think is sort of orthogonal to this. If I were to state the fundamental problem I am trying to address here, it is simply that the RFCs do not authoritatively say what QDCOUNT > 1 means, nor how to do it, nor do they authoritatively say that it is invalid. As a consequence of this, an implementation started using QDCOUNT > 1. So we should do something about that. I think what you propose in your draft is exactly what should have been done, but since we don't say "don't send multiple questions" anywhere, it wasn't done that way. :) On Mon, Feb 13, 2023 at 9:46 AM Kazunori Fujiwara wrote: > > From: Ted Lemon > > Ohta-san, thanks for pointing out that text about the motivation for MX > in > > RFC1035―I hadn't noticed that. > > "DNS SRV RR" [RFC 2782] also mentions adding SRV RR Target A/ to > the additional section. > > # draft-ietf-dnsop-svcb-https also mentions adding SVCB/HTTPS target A/ > # to the additional section. > > In 2017, 2018, QDCOUNT>1 or multiple qtypes were discussed in dnsop WG. > At the time, I proposed draft-fujiwara-dnsop-additional-answers-01 > and compared 5 proposals. > > At the time, all proposals avoided QDCOUNT>1. > > -- > Kazunori Fujiwara ( = fujiw...@jprs.co.jp ) > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] QDCOUNT > 1 (a modest proposal)
> From: Ted Lemon > Ohta-san, thanks for pointing out that text about the motivation for MX in > RFC1035―I hadn't noticed that. "DNS SRV RR" [RFC 2782] also mentions adding SRV RR Target A/ to the additional section. # draft-ietf-dnsop-svcb-https also mentions adding SVCB/HTTPS target A/ # to the additional section. In 2017, 2018, QDCOUNT>1 or multiple qtypes were discussed in dnsop WG. At the time, I proposed draft-fujiwara-dnsop-additional-answers-01 and compared 5 proposals. At the time, all proposals avoided QDCOUNT>1. -- Kazunori Fujiwara ( = fujiw...@jprs.co.jp ) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] QDCOUNT > 1 (a modest proposal)
Ohta-san, thanks for pointing out that text about the motivation for MX in RFC1035—I hadn't noticed that. It still doesn't exactly prohibit doing QDCOUNT > 1, but it's a helpful additional note about the history of the problem. FWIW, I don't think it precludes doing queries with QDCOUNT > 1 to the cache—it just suggests that the work involved in doing it successfully is different (more complex) than the simpler problem you have to solve if QDCOUNT == 1. Having just done an implementation of QDCOUNT > 1, I agree that it's more complicated! :) On Mon, Feb 13, 2023 at 4:27 AM Masataka Ohta < mo...@necom830.hpcl.titech.ac.jp> wrote: > On 2023/02/09 22:54, Ted Lemon wrote: > > > We've been talking elsewhere (Thread) about a small issue that comes > up in > > constrained networks that if we want to do service discovery, and we > get a > > PTR record for a service, then the next thing we need is the SRV and TXT > > records for the service instance, and that's two queries. > > Then, proper thing to do is to have a new unified RR type, > which was not the case with . > > See below why MX was introduced. > > > Now, in general although there is no RFC that expressly forbids QDCOUNT > > 1 > > (or if there is, I couldn't find it, please clue me in), we don't > generally > > support it (my code returns REFUSED, and so does BIND9). > > 1035 is clear about meaninglessness of the idea: > > For example, the original form of mail exchange binding used two RR > types one to represent a "closer" exchange (MD) and one to represent a > "less close" exchange (MF). The difficulty is that the presence of one > RR type in a cache doesn't convey any information about the other > because the query which acquired the cached information might have used > a QTYPE of MF, MD, or MAILA (which matched both). The redesigned > service used a single type (MX) with a "preference" value in the RDATA > section which can order different RRs. However, if any MX RRs are > found > in the cache, then all should be there. > > Masataka Ohta > > > ___ > 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] QDCOUNT > 1 (a modest proposal)
On 2023/02/09 22:54, Ted Lemon wrote: > We've been talking elsewhere (Thread) about a small issue that comes up in > constrained networks that if we want to do service discovery, and we get a > PTR record for a service, then the next thing we need is the SRV and TXT > records for the service instance, and that's two queries. Then, proper thing to do is to have a new unified RR type, which was not the case with . See below why MX was introduced. Now, in general although there is no RFC that expressly forbids QDCOUNT > 1 (or if there is, I couldn't find it, please clue me in), we don't generally support it (my code returns REFUSED, and so does BIND9). 1035 is clear about meaninglessness of the idea: For example, the original form of mail exchange binding used two RR types one to represent a "closer" exchange (MD) and one to represent a "less close" exchange (MF). The difficulty is that the presence of one RR type in a cache doesn't convey any information about the other because the query which acquired the cached information might have used a QTYPE of MF, MD, or MAILA (which matched both). The redesigned service used a single type (MX) with a "preference" value in the RDATA section which can order different RRs. However, if any MX RRs are found in the cache, then all should be there. Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
