Puneet Sood via dns-operations wrote: > RFC 1035 section 7.3 (https://tools.ietf.org/html/rfc1035) > Some name servers send their responses from different > addresses than the one used to receive the query. That is, a > resolver cannot rely that a response will come from the same > address which it sent the corresponding query to. This name > server bug is typically encountered in UNIX systems. > > RFC 2181 (https://tools.ietf.org/html/rfc2181#section-4) > Most, if not all, DNS clients, expect the address from which a reply > is received to be the same address as that to which the query > eliciting the reply was sent. This is true for servers acting as > clients for the purposes of recursive query resolution, as well as > simple resolver clients. The address, along with the identifier (ID) > in the reply is used for disambiguating replies, and filtering > spurious responses. This may, or may not, have been intended when > the DNS was designed, but is now a fact of life. > > Some multi-homed hosts running DNS servers generate a reply using a > source address that is not the same as the destination address from > the client's request packet. Such replies will be discarded by the > client because the source address of the reply does not match that of > a host to which the client sent the original request. That is, it > appears to be an unsolicited response.
See also RFC 5452 section 9.1 (https://tools.ietf.org/html/rfc5452#section-9.1) which puts the clarification in RFC 2181 into mandatory RFC 2119 language. 9.1. Query Matching Rules A resolver implementation MUST match responses to all of the following attributes of the query: o Source address against query destination address o Destination address against query source address o Destination port against query source port o Query ID o Query name o Query class and type before applying DNS trustworthiness rules (see Section 5.4.1 of [RFC2181]). A mismatch and the response MUST be considered invalid. -- Robert Edmonds _______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations
