[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[public-dns-discuss] Re: using 'dig @ +subnet', edns0-client-subnet not working

George wrote:
I tested it using another domain name hosted by another auth service provider, the result seems to be the same. seems to not take my explicit ECS options in the query.

Is it some network problem that navigate me only to a node that do not take clients' ECS option? Can you offer a little further explanation on that, Alex?

UDP queries to the and other anycast addresses land at Google Public DNS in a location that is close to the query source (this isn't a problem) but it does mean that for most users' locations their client-provided ECS data will be ignored (although it will still be used in the response, it won't be sent to authoritative name servers). DNS-over-HTTPS avoids this problem since the addresses used for this are unicast addresses (that are usually further away) but which will accept client-provided ECS for most domains.

Over the course of 2019, we expect to address the way we handle ECS, and in addition to accepting client-provided ECS at many more locations, we may also be able to switch to a more RFC compliant way of handling client-provided ECS, by sending REFUSED responses when we cannot use the client-provided ECS. In the following sections of the RFC, I have highlighted the SHOULD directives that we currently do not follow, but hope to do so in the future

RFC 7871 section 7.1.1:

   FAMILY and ADDRESS information MAY be used from the ECS option in the
   incoming query.  Passing the existing address data is supportive of
   the Recursive Resolver being used as the target of a Forwarding
   Resolver, but could possibly run into policy problems with regard to
   usage agreements between the Recursive Resolver and Authoritative
   Nameserver.  See Section 12.2 for more discussion on this point.  If
   the Recursive Resolver will not forward FAMILY and ADDRESS data from
   the incoming ECS option, it SHOULD return a REFUSED response.

RFC 7871 section 7.1.2:

   A Stub Resolver MUST set SCOPE PREFIX-LENGTH to 0.  It MAY include
   FAMILY and ADDRESS data, but should be prepared to handle a REFUSED
   response if the Intermediate Nameserver that it queries has a policy
   that denies forwarding of ADDRESS.

RFC 7871 section 7.3:

   ... a client of a Recursive Resolver SHOULD
   retry after receiving a REFUSED response because it is not
   sufficiently clear whether the REFUSED response was because of the
   ECS option or some other reason.

RFC 7871 section 7.3.2:

   o  If there was an ECS option with an ADDRESS, the ADDRESS from it
      MAY be used if the local policy allows.  The policy can vary
      depending on the agreements the operator of the Intermediate
      Nameserver has with Authoritative Nameserver operators; see
      Section 12.2.  If the policy does not allow it, a REFUSED response
      SHOULD be sent.  See Section 7.5 for more information.

RFC 7871 section 7.5:

   An Intermediate Nameserver MAY forward ECS options with address
   information.  This information MAY match the source IP address of the
   incoming query, and MAY have more or fewer address bits than the
   nameserver would normally include in a locally originated ECS option.
   If an Intermediate Nameserver receives a query with SOURCE PREFIX-
   LENGTH set to 0, it MUST NOT include client address information in
   queries made to resolve that client's request (see Section 7.1.2).

   If, for any reason, the Intermediate Nameserver does not want to use
   the information in an ECS option it receives (too little address
   information, network address from a range not authorized to use the
   server, private/unroutable address space, etc.), it SHOULD drop the
   query and return a REFUSED response.  Note again that a query MUST
   NOT be refused solely because it provides 0 address bits.

   Be aware that at least one major existing implementation does not
   return REFUSED and instead just processes the query as though the
   problematic information were not present.  This can lead to anomalous
   situations, such as a response from the Intermediate Nameserver that
   indicates it is tailored for one network (the one passed in the
   original query, since the ADDRESS must match) when actually it is for
   another network (the one which contains the address that the
   Intermediate Nameserver saw as making the query).

I will let the last paragraph pass without comment.

You received this message because you are subscribed to the Google Groups "public-dns-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to public-dns-discuss+unsubscribe AT googlegroups.com.
To post to this group, send email to public-dns-discuss AT googlegroups.com.
Visit this group at https://groups.google.com/group/public-dns-discuss.
To view this discussion on the web visit https://groups.google.com/d/msgid/public-dns-discuss/d4ec5e96-b055-45d8-8691-7a2178a800a2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.