I tested it using another domain name hosted by another auth service provider, the result seems to be the same.
220.127.116.11 seems to not take my explicit ECS options in the query.
Is it some network problem that navigate me only to a 18.104.22.168 node that do not take clients' ECS option? Can you offer a little further explanation on that, Alex?
UDP queries to the 22.214.171.124 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
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.
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.
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.