I would even rather see a recommendation that firewalls and middleboxes
don't do any kind of DNS packet handling. Why should they? DNS traffic
is for DNS servers and they are the most capable entity for handling
them, including FORMERR responses on wrongly formatted queries.
Libor
Dne 29. 09. 23 v 0:08 Robert Edmonds napsal(a):
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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
