EDNS Client Subnet (ECS) in queries sent to Google Public DNS

[Alex Dupuy]

Please read if you send DNS queries with non-zero-length EDNS Client Subnet (ECS) to 8.8.8.8.

+ Who is and is not affected +

  The vast majority of Google Public DNS clients do not send ECS data, and more than half of ECS queries to Google Public DNS have a zero-length address, which stops Google Public DNS from using or sending client subnet data in the resolution of that query. Google Public DNS is not changing how it handles DNS queries with zero-length address ECS or without any ECS data.

  Some clients send ECS data with more of the client IP address than the 24 bits (IPv4) or 56 bits (IPv6) subnets than RFC 7871 recommends. Google Public DNS only uses /24 or /56 – and forwarders that send extra unused client IP bits reduce their clients’ privacy unnecessarily.

  Other clients send ECS data with private or non routable addresses that Google Public DNS cannot use at all. Google Public DNS currently ignores those ECS addresses and returns an ECS response with a /0 scope, but RFC 7871 recommends a REFUSED response.

+ What Google Public DNS is changing +

  Although Google Public DNS has not sent REFUSED responses before, we plan to start sending REFUSED responses to queries with non-zero address ECS that is not a prefix of the source address:

• in cleartext UDP or TCP DNS queries

  • with an ECS address longer than the 24 bit (IPv4) or 56 bit (IPv6) limits

• in encrypted DNS over HTTPS (DoH) or DNS over TLS (DoT) queries

  • when the ECS address is not routable (private or reserved address space)
    

  • for domain names where we are forbidden to forward client-provided ECS

  We are making these changes for greater RFC 7871 compliance, to improve privacy for all our users, and protect against potential abuse. These are potentially breaking changes for forwarding resolvers that do not implement the RFC 7871 section 7.1.3 requirement to retry without ECS address data when they get REFUSED responses to their ECS queries.

+ What clients need to do +

• Forwarding resolvers sending non-zero address ECS for clients should use encrypted DNS if possible – if not, they need to limit ECS address data to 24 or 56 bits.

• Forwarding resolvers should retry without ECS when they get REFUSED responses

• Clients that don’t need to send ECS should omit it, or send only zero-address ECS.

• If these changes would affect you, please open an issue on our tracker by January 31, providing client address ranges and AS number, describing your use case and support for encrypted DNS and retry on REFUSED.