Hi, I noticed that Section 4 of the draft states:
Firewalls that process DNS messages in order to eliminate unwanted traffic SHOULD treat messages with OPCODE = 0 and QDCOUNT > 1 as malformed traffic. See Section 4 of [RFC8906] for further guidance. However, I couldn't find the guidance in Section 4 of RFC 8906 being referred to. Most of that section is actually about misbehavior in firewalls in response to well-formed traffic, not correct behavior in response to malformed traffic. The most relevant text seems to be: Firewalls and load balancers should not drop DNS packets that they don't understand. They should either pass the packets or generate an appropriate error response. […] However, there may be times when a nameserver mishandles messages with a particular flag, EDNS option, EDNS version field, opcode, type or class field, or combination thereof to the point where the integrity of the nameserver is compromised. Firewalls should offer the ability to selectively reject messages using an appropriately constructed response based on all these fields while awaiting a fix from the nameserver vendor. Returning FORMERR or REFUSED are two potential error codes to return. If I understand correctly, the QDCOUNT is a field, not a flag, so it would not be included in the list of "a particular flag, EDNS option, EDNS version field, opcode, type or class field, or combination thereof" described here. Even if QDCOUNT were included in this list, I can't think of an example where QDCOUNT > 1 would compromise the integrity of a nameserver. One could also imagine a *valid*, non-malformed combination of query parameters that could result in the integrity of a nameserver being compromised, so this paragraph isn't solely about malformed traffic. So I'm having difficulty understanding how exactly to apply this section when reading it alongside the draft. If the intention of Section 4 of this draft is to allow firewalls to meddle with OPCODE = 0, QDCOUNT > 1 as a general, ongoing deployment posture rather than as a temporary workaround "while awaiting a fix from the nameserver vendor", it would seem to go a bit beyond the narrow guidance in Section 4 of RFC 8906. Also, I think the phrase "to eliminate unwanted traffic" is vague. How would a firewall eliminate unwanted traffic? May it drop OPCODE = 0, QDCOUNT > 1? May it synthesize a FORMERR response? If it synthesizes a FORMERR response, should those responses be rate-limited in case the sender's source address is spoofed? Thanks! Joe Abley wrote: > Hi all, > > This version mainly incorporates feedback from the room at the last meeting > and relate to document clarity; the advice is unchanged. > > > Joe > > > On 28 Sep 2023, at 15:21, internet-dra...@ietf.org wrote: > > > > Internet-Draft draft-bellis-dnsop-qdcount-is-one-01.txt is now available. > > It > > is a work item of the Domain Name System Operations (DNSOP) WG of the IETF. > > > > Title: In the DNS, QDCOUNT is (usually) One > > Authors: Ray Bellis > > Joe Abley > > Name: draft-bellis-dnsop-qdcount-is-one-01.txt > > Pages: 7 > > Dates: 2023-09-28 > > > > Abstract: > > > > This document clarifies the allowable values of the QDCOUNT parameter > > in DNS messages with OPCODE = 0 (QUERY) and specifies the required > > behaviour when values that are not allowed are encountered. > > > > The IETF datatracker status page for this Internet-Draft is: > > https://datatracker.ietf.org/doc/draft-bellis-dnsop-qdcount-is-one/ > > > > There is also an HTMLized version available at: > > https://datatracker.ietf.org/doc/html/draft-bellis-dnsop-qdcount-is-one-01 > > > > A diff from the previous version is available at: > > https://author-tools.ietf.org/iddiff?url2=draft-bellis-dnsop-qdcount-is-one-01 > > > > 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 > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Robert Edmonds _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
