Re: [DNSOP] comments on draft-ietf-dnsop-edns-client-subnet-00

[Warren Kumari <[e-mail]>]

[ Incorporating more of the the comments. Newer version with some of
these incorporated posted on github:
https://github.com/wkumari/draft-vandergaast-edns-client-subnet. ]

Responses inline.



On Wed, Jan 7, 2015 at 9:27 AM, John Dickinson <[e-mail]> wrote:
> 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.

Excellent, DONE!

>
> 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.

DONE, where appropriate (e.g: not for "We request the IANA... " :-)).

>
> 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.

I *think* we have it, but am checking with co-authors....

>
> 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.


DONE.
Good point, done.

>
> 5. Several more examples would be useful as well. (I did send one to the
> authors off list.)

[ Will incorporate later ]

>
> My attempt at text:
> 3.  Terminology
>
>       ECS: Edns Client Subnet.
>

DONE.

>       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.

The above two seem like they are as in the document (just noting so I
don't miss things).
>
>       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.

DONE.

>
>       Intermediate Nameserver: Any nameserver (either a Recursive
>       Resolver or a Forwarder) in between the Stub Resolver and the
>       Authoritative Nameserver.

DONE.
>
>       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.
>

DONE. I suspect we might need to do some more cleanup on these later,
especially after normalizing with PaulH's terminology draft.

>    ...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".
>

[ Checking with co-authors ]

[ Stopping here for now. Will resume later / after more coffee... ]

> 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
>
> ---
> [e-mail]
>
> http://sinodun.com
>
> Sinodun Internet Technologies
> Magdalen Centre
> The Oxford Science Park
> Oxford
> OX4 4GA
> U.K.
>
>
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf