Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
edns-client-subnet: FORMERR if not IPv[46] family
Previously, if the client's option had enough bytes for the IPv[46] source and scope masks, and the source mask field was zero with no address data, and the family was not IPv4 or IPv6, we ignored the data for lookup purposes, but returned (with fixed scope mask zero) a reflection of the sent arbitrary family value plus two bytes for the zero source and scope masks. RFC 7871 has some confusing language on this issue, and I'm switching interpretations here. Either way I don't think using non IPv[46] families is probably very useful in practice on the Internet, but our new interpretation is to FORMERR any family that isn't IPv4 or IPv6. --- The ambiguity stems from these bits of the standard: Section 7.1.2 Stub Resolvers says: > [...] This is for interoperability; at least one major > authoritative server will ignore the option if FAMILY is not 1 > or 2, even though it is irrelevant if there are no ADDRESS bits. The implication is the "one major authoritative server" is doing something standards-questionable in its described action, and I previously took this sentence to imply that authservers should accept the option and reflect an unknown family value so long as the source mask specified zero address bits. However, Section 7.2.1 Authoritative Nameserver says: > A query with a wrongly formatted option (e.g., an unknown > FAMILY) MUST be rejected and a FORMERR response MUST be returned > to the sender [...] Which, at least in its example, seems to state that an unknown family (which for us is anything but IPv4 or IPv6) requires a FORMERR response regardless of source mask or the rest of the contents. The clencher on this issue, IMHO, is that the description of the wire format in Section 6 explicitly says: > The format of the address part depends on the value of FAMILY. > This document only defines the format for FAMILY 1 (IPv4) and > FAMILY 2 (IPv6), which are as follows: ... with the fields up through FAMILY described above that language, and the definition of the source mask, scope mask, and address fields below that language. Therefore, I believe the standards document is saying that in the case of other family values (not IPv[46]), there is no declared interpretation of what the rest of the data even means, and therefore it wouldn't be legitimate to even look at the source mask field to see that it's zero and decide to reflect the family value and/or send back zero source and scope mask fields that are only defined for IPv[46]. This is a little bit contradictary to some interpretations of 7.1.2's interop example, in my opinion. Perhaps 7.1.2 really meant "zero bytes of data beyond the family value" when it said "no ADDRESS bits", but then that interpretation wouldn't be very useful for interop with a future new RFC that did define data for a new family type, unless that RFC defined that the new address family sent no address data, but could be used to select a different response address based on family alone. Therefore, I think the sanest approach is probably to just FORMERR any unknown family for now, unless/until some future RFC clarifies this point and/or defines another family. If nothing else, it's the least-surprising interpretation of the language of the section that's acutally about authoritative server responses.
- Loading branch information