Hi Jinmei On Tue, Feb 02, 2016 at 11:31:34AM -0800, 神明達哉 wrote: > At Mon, 28 Dec 2015 07:59:14 +0530, > Mukund Sivaraman <[email protected]> wrote: > > > https://tools.ietf.org/html/draft-ietf-dnsop-edns-client-subnet-06 > > > > One of the main concerns while implementing EDNS client-subnet is about > > keeping the size of cache small and in check. It seems cache handling > > for EDNS client-subnet can be improved by changes to the option > > syntax. While the draft may be describing an existing scheme used in > > some existing implementations, it needs changes before this draft goes > > any further, otherwise it would lead to more duplication in the cache > > than necessary. > > I have to admit I've not closely looked at all of the text, but I have > a couple of high level comments: > > - Whether you like it or not, any protocol change will be out of scope > of this particular draft (although the result of IETF last call and > IESG decision might change that) - (in my understanding) that's the > decision the wg made quite a long time ago. If you want to > introduce any final change, that will have to be something that > doesn't involve a protocol change.
Nod. (I also understand this has progressed on; my feeling is that it
should not have been adopted by dnsop at all, if we couldn't influence
it. It could've taken a different path, but I suppose I'm complaining
too late.)
> - From a quick read, the concern you raised seems to be related to the
> case where more and less-specific prefixes are to be configured at
> the ECS-supporting authoritative server. In my understanding that
> was actually one of the unclear points, but the wg decided to defer
> any detailed discussions to a currently-imaginary successor of this
> document. You should be able to find some related discussions in
> the dnsop list archive.
The -06 draft is poor quality.
For a reasonable ECS implementation (especially cache behavior) with the
current protocol, I feel there are still some restrictions that should
be included in the draft, like blinkers on a horse so it doesn't get
distracted. The protocol leaves a lot of stuff unspecified, and it needs
to be more specific and restrictive to be functional. There is a list of
issues that can be addressed by specifying behavior. With the current
spec, implementations have to make assumptions about these and they
would lead to interoperability issues among different flavours of
implementations.
Examples of issues:
- REFUSED vs. FORMERR (FORMERR is underlying DNS protocol, so I don't
know how the draft is allowed to modify it, or how implementations
would not work with FORMERR).
- Underspecfication of when REFUSED must be returned in case of FORMERR
issues.
- Closely related behavior having different return codes (bad FAMILY
returning FORMERR, whereas bad ADDRESS field returning REFUSED
always) - section 6 vs. section 7.2.1
- Clear upfront description of FAMILY=0 behavior, including what goes in
PREFIX-LENGTH fields, ADDRESS field, etc. in section 6.
- No specification of what "deaggregation" is. This is required for
proper cache operation and is an interoperability concern. It should
be clearly specified how answers are deaggregated based on both the
zone data for different prefixes and also the SOURCE
PREFIX-LENGTH. This algorithm is non-obvious and an implementation
will not get it right by first-guessing. A mistake here would lead to
incorrect caching on the resolver side, so it is an interoperability
concern and is well within the scope of this document.
- The draft disagrees with itself on what happens if SCOPE > SOURCE
PREFIX-LENGTH. SCOPE > SOURCE only makes more sense if there are more
ADDRESS bits set in the reply message than in the query message. In
one place the draft says it should be processed (section 7.3 where
only up to SOURCE PREFIX-LENGTH bits of ADDRESS need to be checked in
the reply) whereas in another place it says that a reply with a
mismatching ADDRESS field should be dropped (section 6).
Also, the draft does not say what it *means* in the answer when it has
SCOPE > SOURCE. This is not a reply to the question sent in the query
message. A longer SCOPE may not be useful (even if the resolver finds
the client in that subnet) as it reduces privacy if the client
attempts to use that answer.
It would seem that in proper ECS operation, SCOPE need never be
greater than SOURCE. Why have this specified at all? The description
in the draft is short.
* Option forwarding behavior, as specified in the draft, can lead to
either ECS not be used for future queries when forwarding is REFUSED,
or redundant fetches. Option forwarding would interfere with caching
when the SOURCE PREFIX-LENGTH in the client query's option (to be
forwarded) is *shorter* than the locally configured policy SOURCE
PREFIX-LENGTH on an intermediate resolver. The draft makes no explict
mention of this or how to workaround this.
* DNSSEC behavior and negative answer handling are underspecified. The
draft contains 2 small paragraphs on DNSSEC (section 9). It is quite
possible that operators will use different data sources for each
subnet (e.g., different master files). In this case, how are negative
proofs handled? A name may be missing in a data source, or an answer
may be missing in the data source for a subnet whereas it exists in a
different subnet. Section 7.4 leaves the possibility of negative
answers being handled differently by implementations. It needs to be
more restrictive, and DNSSEC behavior should be specified
clearly. This is an interoperability concern for both implementations
and operators.
* A personal peeve - I dislike how the address prefix lengths are named
"SOURCE" and "SCOPE" instead of "QUERY" and "RESPONSE". Over all this
time playing with this draft, I've made the error of typing/saying one
instead of the other several times because they are so similar.
It's possibly still not too late for many of these issues to be
addressed by behavioral descriptions in the draft (without any protocol
changes).
Mukund
signature.asc
Description: PGP signature
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
