Hello All, Some time ago (when there was a Verisign coauthor on this draft) I was asked to review it internally. I'm not sure if all of my comments were passed back, so I am sending them here. Hopefully I have correctly accounted and adjusted for changes between the current version and the one that I reviewed. If not please forgive me.
As a general comment, I found it a little bit loose with the terminology
and vague at times. As protocol to be implemented I think it should be
tightened up.
>
>
> Stub Resolver: A simple DNS protocol implementation on the client
> side as described in [RFC1034] section 5.3.1.
>
> Authoritative Nameserver: A nameserver that has authority over one
> or more DNS zones. These are normally not contacted by clients
> directly but by Recursive Resolvers. Described in [RFC1035]
> chapter 6.
>
> 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.
>
> Intermediate Nameserver: Any nameserver (possibly a Recursive
> Resolver) in between the Stub Resolver and the Authoritative
> Nameserver.
Another sort of general comment here: I have some trouble with the protocol
that says "if you are a Recursive Resolver, do this. Or if you're an
Intermediate Resolver, do that" because I think servers don't usually or
always know if they are recursive, or intermediate, or authoritative. (A
name server can be recursive for one zone and authoritative for another).
It is especially confusing to try to distinguish between recursive and
intermediate. So I wish the behavior could be expressed in terms of the
protocol elements. For example, rather than say "if you're a stub, do
this" you would say "if the outgoing query as the RD bit set, do this"
Maybe thats unrealistic though.
> Centralized Resolvers: Recursive Resolvers that serve a
> topologically diverse network address space.
I question whether it is really necessary to define a Centralized Resolver as
something different a Recursive Resolver. It seems to be used very few times in
the document, and nowhere in a way that would affect protocol implementation.
>
>
> The expectation, however, is that this option will only be used by
> Recursive Resolvers and Authoritative Nameservers that incur
> geolocation issues.
"The expectation" makes me cringe a little bit. I strongly believe that
the new feature is going to be used and abused in ways that haven't been
envisioned. I predict that a significant amount of name servers will
enable this either because they *think* it will give them more optimal
DNS responses and/or because it enables some other new feature.
Just look at how many people use 8.8.8.8 because somebody told them its
faster than their ISP.
slight diversion/rant/anecdote:
On the Squid project ("back in my day...") I was responsible for coming
up with the X-Forwarded-For HTTP header, which is very similar to
edns-client-subnet. X-Forwarded-For happened because people wanted their
apache access log files to reflect the individual end users IP, not the
proxy IP. Now there are numerous instances where you can use browser
plugins to insert a fake X-Forwarded-For header to bypass country-level
content restrictions, etc.
>
> Failure to support this option or its improper handling will, at
> worst, cause suboptimal identification of client location, which is a
> common occurrence in current content delivery network (CDN) setups
> and not a cause of concern.
If its not a cause of concern then why is client-edns-subnet being proposed?
> In this option, the server should include the IP address of the
"In this option" and "the server" is an example of how I think the language
needs to
be tightened. Which server? Are we still talking about Recursive Resolver
from the previous paragraph?
> The Stub Resolver may also add non-empty edns-client-subnet options
> to its queries, but Recursive Resolvers are not required to use this
> information.
Here is an example where I think there is a conflict because a server won't
necessarily know if it is "Recursive" or "Intermediate." In the text above
the Recursive can ignore the edns-client-subnet from the Stub. In the
Transitivity section it says if an Intermediate doesn't want to use the
query's edns-client-subnet information, it should drop the query and return
REFUSED.
>
> The FAMILY and SOURCE NETMASK in the response MUST match those in the
> request. The first SOURCE NETMASK bits of the ADDRESS in the
> response MUST match those in the request, even if fewer bits were
> used to form the response. Echoing back the address and netmask
> helps to mitigate certain attack vectors, as described in Section 10.
So we can also use edns-client-subnet as an entropy source to fight Kaminsky?
>
> 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, as detailed below. Note that the additional and authority
> sections from a DNS response message are specifically excluded here.
The different treatment for authority and additional data is interesting.
I wonder if it impacts the "ranking data" rules of RFC 2181 section 5.4.1?
An 'A' record could be in the cache because it came in via the additional
section, and it could also be in the cache with a different value because
someone queried for it directly with edns-client-subnet.
The document doesn't say anything about applying or not applying to specific
record types, but should it? Can NS/SOA/RRSIG/DNSKEY/etc rdata depend on
edns-client-subnet?
Late-breaking comment: A few days ago a coauthor of this very draft published
another draft document (draft-wkumari-dnsop-multiple-responses-00.txt)
which essentially says a server can put extra "answer" records in an
additional section (they must be signed) to preempt subsequent queries.
The two drafts would seem to be in conflict for how to handle additional
section records.
> 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.
Is there potential problem because RRs are cached with associated
FAMILY/ADDRESS/SCOPE and you might have multiple RRs in the Answer section,
but you only have one edns-client-subnet in the response? For example,
could you have a cached CNAME RR under 192.168.0.0/16 and an associated
cached A RR under 192.168.1.0/24? What does the edns-client-subnet option
response (especially SCOPE NETMASK) look like in this case,
>
> If the address of the client does not match any network in the cache,
> then the Recursive Resolver MUST behave as if no match was found and
This section started out talking about an Intermediate Resolver but
here switched to Recursive Resolver.
> When the request includes a longer SCOPE NETMASK, the reply returned
longer than what?
> o If the SCOPE NETMASK in the reply is longer than the SOURCE
> NETMASK, it means that the reply might be suboptimal. A Recursive
> Resolver 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..
I've tried to parse this about 10 times, and I still don't feel like
I've got it.
How does a "[query] ... not ... allow a longer SOURCE NETMASK to be forwarded"?
Only SOURCE NETMASK of 0 must be obeyed and anything else can be overridden,
right?
How does the cache know whether or not a cached RR is sub-otpimal (because
the cache doesn't save the SOURCE NETMASK, right?) Does it have to set
a this-response-is-sub-optimal bit when it goes into the cache?
Maybe you can walk me through this example:
First query: www.google.com/A ADDRESS=192.168 SOURCENM=16
Server response: x.x.x.x ADDRESS=192.168 SCOPENM=24
(so this is a possibly sub-optimal response because the server says
it has more specific info but the client wasn't willing to provide
more address bits)
Soon a second query comes in just like the first:
Second query: www.google.com/A ADDRESS=192.168 SOURCENM=16
Is this a cache hit? The document doesn't really detail how networks are
matched. It says "if the address of the client is within any of the
networks in the cache." Is 192.168/16 within 192.168.0/24? I wouldn't
think so, but otherwise you get nothing but cache misses from this situation.
Anyway, one of my concerns with handling sub-optimal responses was that
you keep forwarding the query rather than use the cached data but you keep
getting back the same response. The document doesn't say if the "same
response" should update the cache (extending its TTL) or be ignored.
>
> As another reply is received, the reply will be tied to a different
> network. The server SHOULD keep in cache both replies, 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.
being very pedantic here I guess, but that reply won't necessarily
be tied to a different network. Perhaps the document should simply
state what to do when it gets a response for a network not already
in the cache, and for a network already in the cache (update or drop)?
> If the original client request contained
> a valid edns-client-subnet option that was used during recursion,
What does "used during recursion" mean? used in cache lookups? forwarded?
Can a "0.0.0.0/0" edns-client-option be "used?"
>
> Intermediate Nameservers, including Recursive Resolvers, supporting
> edns-client-subnet MUST forward options with SOURCE NETMASK set to 0
"forward queries", perhaps?
> An Intermediate Nameserver MAY also forward edns-client-subnet
> options with actual address information.
Not exactly clear what the "actual address" is in this case. I guess you
mean the edns-client-subnet data received in the query?
> This information MAY match
> the source IP address of the incoming query, and MAY have more or
> less address bits than the Nameserver would normally include in a
> locally originated edns-client-subnet option.
Is the Intermediate allowed to change SOURCE NETMASK?
The document doesn't really say if the Intermediate is allowed to
overwrite the query-provided edns-client-subnet data with its own
choice of values, or did I miss that?
> Note again
> that an edns-client-subnet option with 0 address bits MUST NOT be
> refused.
queries are refused, not options. I suggest:
Note again that an Intermediate Nameserver MUST NOT refuse a query simply
because the edns-client-subnet SOURCE NETMASK is set to 0.
(i.e., it could refuse the query for other reasons).
>
> In other cases, Recursive Resolvers sited behind a NAT device SHOULD
> NOT originate edns-client-subnet options with their IP address, and
> instead rely on downstream Intermediate Nameservers doing so.
This is a configuration decision, right? How would a Recursive know
whether or not it is behind NAT?
> Users who wish their full IP address to be hidden can include an
> edns-client-subnet option specifying the wildcard address 0.0.0.0/0
> (i.e. FAMILY set to 1 (IPv4), SOURCE NETMASK to 0 and no ADDRESS).
Its not really a User's choice, is it? Guess it depends on your definition
of user.
> To counter this, every edns-client-subnet option in a response packet
every? There can be more than one?
> o Recursive Resolvers SHOULD limit the number of networks and
> answers they keep in the cache for a given query.
I wouldn't say these things "cache queries". I would say they "cache records"
or
maybe even RRsets. So maybe "... keep in the cache for a given RRset?"
> If
> the option is supported but not actually used for generating a
> response, its SCOPE NETMASK value SHOULD be set to 0.
I think this was a MUST before (section 6.2)
>
> 12. Example
I would like to see many more examples, not only of the normal/expected cases,
but
also of the abnormal and unexpected cases.
Throughout the document there seems to be an assumption that all of the
authoritative name servers for a zone would support edns-client-subnet.
What would happen if that is not the case?
DW
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
