Dear colleagues,
On the principle that I should work on something instead of talking
about it, I had a look at draft-vandergaast-edns-client-subnet-02. I
have a couple questions and remarks.
First, I'm a little uncomfortable with "optimized reply" as the name
for this. It seems to me that one could be getting this special
authoritative reply for lots of reasons, though "optimization" is the
usual one. I'd suggest a more neutral term; perhaps "origin-tailored
reply" or something. The point is that the response you got is
somehow scoped to some query originators and not others, and the
document needn't take a position on whether that's good or bad. (This
remark was mostly inspired by all the talk of "sub-optimal" later in
the draft. As we know, some of these "optimized" cases are themselves
sub-optimal. All the sub-optimal talk needs to be adjusted too.)
Section 5.3 says
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.
Now, imagine I'm querying for the NS for an in-baliwick DNS server,
and I get back the answer, and it is somehow an optimized reply (as
defined in the draft). (Note that I am not arguing this _should_ be
something the authoritative server does, but it's implied as possible
by the draft, so we better understand it.) In this case, the glue
records that I get will in fact be optimized too. One is not allowed
to cache them discriminately on the basis of client-subnet, however.
I _think_ this is ok, because the right answer for the cache is to use
additional section data for that query only, and throw it away,
querying next time for the A and AAAA records if need be. Is that
right?
I'm pretty sure STRONGLY RECOMMENDED isn't an RFC 2119 term! (See section 5.3.)
Also in 5.3,
Replies coming from servers not supporting edns-client-subnet or
otherwise not containing an edns-client-subnet 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.
I think the "or" in the parenthetical is properly "and". No?
Otherwise, this option implicitly divides all operations into
v4-operations and v6-operations. If so, it needs to be made explicit
somewhere.
I'm concerned about the consistency between section 5.4 and this text in 5.1:
The Stub Resolver may also add non-empty edns-
client-subnet options to its queries, but Recursive Resolvers are not
required to accept/use this information.
In general, there is no way for a resolver to tell whether the request
it just received is from a stub or from some other sort of resolver.
So I don't see how that "not required" part and the restrictions in
section 5.4 can all be true at the same time. Also, at the end of
5.4, there is, "Note again that an edns-client-subnet option with 0
address bits MUST NOT be refused." Surely that needs some scoping,
like "MUST NOT be refused on the grounds of edns-client-subnet
matching" or something. There are lots of reasons to REFUSE a query
(like, for instance, the originating IP isn't allowed to query via
you).
Why is there no advice in section 9.1 for IPv6? Pick a number. /56
perhaps. It seems that there is nascent practice anyway among ISPs,
and the draft ought to pick one.
I'm really very happy to see a description of what the experiment is
and what the conditions are to determine whether things have been
successful. Section 12 still says that the option code is tentative,
but perhaps that ought to be altered to indicate that, if the
experiment is successful it might continue in use. Also, since this
document is nearly a year old and the code point happened some time
ago, I'm wondering whether there are any updates to the experiment.
Maybe it's already yielded some results?
I still think this is a worthy draft, and I think it ought to go
ahead. It does alter the DNS protocol, so DNSOP is not the WG for it.
I have included the DNSEXT mailing list, which is supposed to be where
we discuss such changes, though I confess I have faint hope we'll
actually do that.
Best regards,
A
--
Andrew Sullivan
a...@anvilwalrusden.com
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
