Google should definitely drop them as the rest of us then don’t have to deal with “but it works with Google’s servers”.
We (ISC) drop them. They are basically the result of servers listening on *.53 and failing to ensure the replies originate from the correct address. In IPv4 you need to listen explicitly on each address to force the reply to come from the correct address. For IPv6 you need to use struct in6_pktinfo to get and set the destination / source addresses. They also don’t make it through stateful firewalls. Mark > On 29 Aug 2020, at 08:24, Puneet Sood via dns-operations > <[email protected]> wrote: > > > From: Puneet Sood <[email protected]> > Subject: Nameserver responses from different IP than destination of request > Date: 29 August 2020 at 08:24:40 AEST > To: dns-operations <[email protected]> > Cc: Lu Zhao <[email protected]> > > > Hello, > > We (Google Public DNS) have noticed some instances of nameserver > responses for a query coming from a different IP. Our initial plan was > to consider these responses invalid and discard them. However after > reading the text in RFC 1035 and the update in RFC 2181, we wanted to > check what other recursive resolvers are seeing and how they are > handling such responses. > > 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. > > Couple of observations: > 1. The difference between original and response nameserver IP happens > for a small percentage of total queries (< 0.1%). > 2. Where the original and response nameserver IPs are different, > manual analysis of the top few response IPs showed that both IPs are > on the same operator's network. So these are likely responses from the > operator's DNS servers. > > We would be interested in hearing other operator's experience here. > Are recursive servers seeing similar behavior from authoritative > servers? If yes, are you discarding these responses? > Are there authoritative server operators who still need the > flexibility afforded by RFC 1035? > > Thanks, > Puneet > > > _______________________________________________ > dns-operations mailing list > [email protected] > https://lists.dns-oarc.net/mailman/listinfo/dns-operations -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected] _______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations
