Hi,
I have been reading this draft with a view to designing an implementation.
In an attempt to understand section 6 I tried to pull it apart in to
more sections. I have attempted to describe the behaviour of each possible
type of name server (e.g., auth, recursive, caching, forwarding, stub, etc.)
in separate sections even if that requires repeating text. My re-write can
be found below (with questions inline and a summary of changes at the end).
I hope the authors find it useful. If I have mis-understood anything please
let me know.
In addition:
1. I also strongly agree with the comments made by JINMEI, Tatuya. Especially
those about changing NETMASK to PREFIX_LENGTH.
2. For clarity, I think edns-client-subnet should be changed to ECS and
consistent use made of the terms query and response and not terms like
question, request or reply.
3. I think that there might be places where Intermediate Nameserver and
Recursive Nameserver have been used interchangeably/inconsistently.
I am not sure I have it correct in the suggested text below.
4. There is no mention of DNS CLASS. Somewhere it should state this is only
for IN and that IN is assumed throughout. Especially when matching queries
with responses.
5. Several more examples would be useful as well. (I did send one to the
authors off list.)
My attempt at text:
3. Terminology
ECS: Edns Client Subnet.
Stub Resolver: A simple DNS protocol implementation on the client
side as described in [RFC1034] section 5.3.1. A client to a
Recursive Resolver or a Forwarder.
Recursive Resolver: A nameserver that is responsible for resolving
domain names for clients by following the domain's delegation
chain. Recursive Resolvers frequently use caches to be able to
respond to client queries quickly. Described in [RFC1035] chapter
7.
Forwarder: A nameserver that receives queries from a Stub Resolver
and forwards them on to a Recursive Resolver. A client to a
Recursive Resolver. It is possible to have a chain of Forwarders.
Forwarders frequently use caches to be able to respond to client
queries quickly.
Intermediate Nameserver: Any nameserver (either a Recursive
Resolver or a Forwarder) in between the Stub Resolver and the
Authoritative Nameserver.
Authoritative Nameserver: A nameserver that has authority over one
or more DNS zones. These are normally not contacted by Stub
Resolvers directly but by Recursive Resolvers. Described in
[RFC1035] chapter 6.
Client: A Stub Resolver, Forwarder or Recursive Resolver.
Server: A Forwarder, Recursive Resolver or Authoritative
Nameserver.
...The rest of section 3 as is...
5. Option Format
...as is...
Question: Clarify the meaning of significant in the last bullet
point: "Otherwise, the bits for ADDRESS will be significant through
the maximum of the SOURCE NETMASK or SCOPE NETMASK, and 0 filled to
the end of an octet" so that it cannot be misinterpreted as "set
additional significant bits to 1".
6. Protocol Description
6.1. Adding the ECS Option
The ECS option should generally be added by Recursive Resolvers when
querying other servers, as described in Section 11, but can be added
by a Stub Resolver.
6.1.1. Stub Resolvers
A Stub Resolver MAY generate DNS queries with an ECS option with
SOURCE NETMASK set to 0 (i.e. 0.0.0.0/0) to indicate that the
Recursive Resolvers MUST NOT add address information of the client to
its queries.
The Stub Resolver may add non-zero ECS options to its queries.
Question: Would be useful to clarify what should be used in the SCOPE
NETMASK here - since there is no discussion on this in section 5?
6.1.2. Recursive Resolver Receiving Queries
A Recursive Resolver supporting ECS MAY use client address
information in order to generate an optimized response. The
Recursive Resolver will look in its cache (see section 6.3.2) or send
queries to Authoritative Servers to get a response. The queries MAY
contain an ECS option.
Recursive Resolvers that have not implemented or enabled support for
the ECS option may safely ignore it within incoming queries. Per
[RFC6891] section 6.1.2, such a server MUST NOT include an ECS option
within replies, to indicate lack of support for the option.
Queries with wrongly formatted options (e.g., wrong size) MUST be
rejected and a FORMERR response MUST be returned to the sender, as
described by [RFC6891], Transport Considerations.
If no ECS option is present in a query received by a Recursive
Resolver which supports ECS then it SHOULD add an ECS option to its
queries including the IP address of the client that caused the query
to be generated.
For privacy reasons, and because the whole IP address is rarely
required to determine an optimized response, the ADDRESS field in the
option SHOULD be truncated to a certain number of bits, chosen by the
administrators of the Recursive Nameserver, as described in
Section 10
If the client query contains an ECS option with SOURCE NETMASK set to
0 then the Recursive Resolver MAY either not include an ECS option or
MAY optionally include its own address information, which is what an
ECS aware Authoritative Nameserver will use anyway to generate the
response in lieu of no option. This allows the answer to be handled
by the same caching mechanism as other queries, with an explicit
indicator of the applicable scope. Subsequent Stub Resolver queries
for /0 can then be answered from this cached response.
If the client query contains an ECS option with a non-zero SOURCE
NETMASK then the Recursive Resolver is not required to use this
information. The Recursive Resolver MAY act as if no ECS option was
specified (see above), or it may respect the ECS option in the query
and use this information to obtain an optimised response. In the
second case,
o the ECS information should be used when searching the cache for an
answer instead of the client address (see section 6.3.2.1)
o if recursion is required and if the client query contains a SOURCE
NETMASK that is shorter than the maximum cacheable SCOPE NETMASK
that the Recursive Resolver allows, the Recursive Resolver SHOULD
issue the upstream query with its longer SCOPE NETMASK
6.2. Authoritative Server
...as is until paragraph 7...
Question: Would it be better to convert P7 and P8 to be definitions
of optimal and suboptimal?
SUBOPTIMAL RESPONSES: A SCOPE NETMASK value longer than the SOURCE
NETMASK indicates that the address and netmask provided in the
query was not specific enough to select a single, best response,
and it means that the response might be suboptimal. The ADDRESS
in the response ECS option MUST be extended to SCOPE NETMASK
significant bits to indicate the network for which it is optimal.
Question: Refer to Question in section 5?
OPTIMAL RESPONSES: Conversely if the SCOPE NETMASK in the response
is shorter than or equal to the SOURCE NETMASK this indicates that
more bits than necessary were provided, and the answer is suitable
for a broader range of addresses. The response is optimal for the
network described by the SCOPE NETMASK.
...Rest of section 6.2 from paragraph 9 as is...
6.3. Intermediate Nameservers handling responses and caching
When an Intermediate Nameserver receives a response containing an ECS
option, it will return a response to its client and SHOULD cache the
result.
If the FAMILY, SOURCE NETMASK, and SOURCE NETMASK bits of ADDRESS in
the response don't match the fields in the corresponding query, the
full response MUST be dropped, as described in Section 10.
If the Authoritative Nameserver extended the ADDRESS in the response
to SCOPE NETMASK significant bits to indicate the network for which
it is optimal, The Recursive Resolver SHOULD still provide the
result as the answer to the triggering query even if the client is in
a different address range.
Any response containing an ECS option considered invalid should be
treated as if no ECS option was specified at all.
Responses coming from servers not supporting ECS or otherwise not
containing an ECS option SHOULD be considered as containing a SCOPE
NETMASK of 0 (e.g., cache the result for 0.0.0.0/0 or ::/0) for all
the supported families.
6.3.1. Caching responses
In the cache, any resource record in the answer section will be tied
to the network specified by the FAMILY, ADDRESS and SCOPE NETMASK
fields in the response, as detailed below, even if the address has
been extended. This includes negative responses. Note that the
additional and authority sections from a DNS response message are
specifically excluded here. Any information cached from these
sections MUST NOT be tied to a network.
Although omitting network-specific caching will significantly
simplify an implementation, the resulting drop in cache hits is very
likely to defeat most latency benefits provided by ECS. Therefore,
when implementing this option for latency purposes, implementing full
caching support as described in this section is STRONGLY RECOMMENDED.
Enabling support for ECS in an Intermediate Nameserver will
significantly increase the size of the cache, reduce the number of
results that can be served from cache, and increase the load on the
server. Implementing the mitigation techniques described in
Section 10 is strongly recommended.
6.3.2. Answering from the cache
6.3.2.1. No ECS option in client query
If a query is received matching the name and type of an entry in the
cache, the Intermediate Nameserver will check whether the IP version
and source address of the client matches one of the networks in the
cache for that entry.
6.3.2.2. ECS option in client query
If the original client query contained an ECS option the Intermediate
Nameserver MAY use either the client source address or the
information in the ECS option to perform the cache lookup.
Question: What is the recommended behaviour here?
6.3.2.3. Selecting the best response
If the address of the client is within any of the networks in the
cache, then the cached response MUST be returned as usual. If the
address of the client matches multiple networks in the cache, the
entry with the longest SCOPE NETMASK value MUST be returned, as with
most route-matching algorithms.
If the address of the client does not match any network in the cache,
then the Intermediate Nameserver MUST behave as if no match was found
and perform forwarding/resolution as usual. This is necessary to
avoid suboptimal replies in the cache from being returned to the
wrong clients, and to avoid a single query coming from a client on a
different network from polluting the cache with a suboptimal response
for all the users of that Intermediate Nameserver.
6.3.2.4. Sub-optimal responses
Suboptimal responses may be returned for several reasons e.g.,
o Every time a Recursive Resolver queries an Authoritative
Nameserver by forwarding the ECS option that it
received from another client, a short SOURCE NETMASK in the
original request could cause a suboptimal reply to be returned by
the Authoritative Nameserver.
o Question: This would be clearer if it specified what the SOURCE
NETMASK was shorter than.
o When the request includes a longer SCOPE NETMASK, the reply
returned may still be cached as optimal for the ADDRESS and SCOPE
NETMASK of the reply. This might still be suboptimal for the
original client.
o Question: Again longer then what?
To avoid a suboptimal response from being served from a cache for
clients for which a better response would be available, the
Intermediate Nameserver MUST check the SCOPE NETMASK that was
returned in the response.
o If the SCOPE NETMASK in the response is longer than the SOURCE
NETMASK, it means that the response might be suboptimal. A
Intermediate Nameserver MUST return this entry from cache only to
queries that do not contain or allow a longer SOURCE NETMASK to be
forwarded, or to queries originating from the network covered by
the ADDRESS and SCOPE NETMASK.
o If the SCOPE NETMASK in the response is shorter than or equal to
the SOURCE NETMASK, the response is optimal, and SHOULD be
returned from cache to any client within the network indicated by
ADDRESS and SCOPE NETMASK.
Question: I find the above very hard to parse. I think it needs
rewriting and some examples.
As another response is received, the response will be tied to a
different network. The Intermediate Nameserver SHOULD keep in cache
both reponses, and return the most appropriate one depending on the
address of the client. Per standard DNS caching behavior, all
records SHOULD be retained until their TTL expires. Subsequent
queries to refresh the data should always specify the longest SCOPE
NETMASK that the Intermediate Nameserver is willing to cache, even if
previous responses indicated that a shorter netmask was the optimal
response.
6.3.3. Responses to clients
The response from the Intermediate Nameserver to the client MUST NOT
contain the ECS option if none was present in the client's original
query.
If the original client query contained a valid ECS option that was
respected and the information used during recursion, the Recursive
Resolver MUST include the ECS option from the Authoritative
Nameserver response in the response to the client.
Question: What about the case of a valid ECS option that is received
but not used, and the Recursive Resolver uses its own ECS option
instead? How about adding this text "In the case of a valid ECS
option that is received but not used, and when the Recursive Resolver
uses its own ECS option instead, the Recursive Resolver SHOULD
include the ECS option it received from the Authoritative Nameserver
in the response to the client".
6.4. Transitivity
Question: would this section be better earlier in the text?
.. as is until paragraph 3...
Options received with a SOURCE_NETMASK set to 0 (completely
anonymized) MUST be forwarded unchanged by all Intermediate
Nameservers supporting ECS, including Recursive Resolvers. Such an
option MUST NOT be replaced with an option with more accurate address
information.
...rest of section 6.4 as is...
Summary of changes...
New sections:
Added new section 6.1.1 Stub Resolvers
Added new section 6.1.2 Recursive Resolver Receiving Queries
Added new section 6.3.1 Caching responses
Added new section 6.3.2 Answering from the cache
Added new section 6.3.2.1 no ECS option in client query
Added new section 6.3.2.2 ECS option in client query
Added new section 6.3.2.3 Selecting the best response
Added new section 6.3.2.4 Sub-optimal responses
Added new section 6.3.3 Responses to clients
Changes:
section 3 Modified and added additional terminology
section 5 Question about last bullet point
section 6.1 Section title changed and question added to text
section 6.1.P1 Modified
section 6.1.P2 Modified and moved to section 6.1.2
section 6.1.P3 Modified and split between sections 6.1.1 and 6.1.2
section 6.1.P4 Modified and split between sections 6.1.1 and 6.1.2
section 6.1.P5 Modified and moved to section 6.1.2
section 6.1.P6 Modified and moved to section 6.1.2
section 6.2 Section title changed
section 6.2.P7 Modified and questions
section 6.2.P8 Modified and questions
section 6.3 Section title changed
section 6.3.P1 Modified
section 6.3.P2 Modified
section 6.3.P3 Modified and moved to section 6.3.1
section 6.3.P4 Modified and moved to section 6.3.2.1
section 6.3.P5 Moved to section 6.3.2.3
section 6.3.P6 Modified and moved to section 6.3.2.3
section 6.3.P7 Now bullet points in section 6.3.2.4
section 6.3.P8 Now bullet points in section 6.3.2.4
section 6.3.P9 (and bullet points) Modified, questions and
moved to section 6.3.2.4
section 6.3.P10 Moved to 6.3.2.4
section 6.3.P11 Moved to 6.3.1
section 6.3.P14 Modified and moved to section 6.3.3
section 6.3.P15 Modified and moved to section 6.3.1
section 6.4.P3 Modified
regards,
John
---
j...@sinodun.com
http://sinodun.com
Sinodun Internet Technologies
Magdalen Centre
The Oxford Science Park
Oxford
OX4 4GA
U.K.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
