Re: [dnsext] Re: I-D ACTION:draft-vandergaast-edns-client-ip-00.txt

[Brian Dickson <[e-mail]>]

Leaving aside the questions on privacy, opt-in/opt-out, coherence, etc.,
here are some observations I have:

This proposes putting an incremental level of work onto the recursive
resolver, regardless of where it is.

This raises the question of how to scale the actual amount of work, versus
the benefit (real or perceived) by the resolver and the resolvers' clients.

If, in order to populate a cache with "all" of the relevant entries, for
each leaf on the DNS tree exploiting this option, it takes N
queries/answers, this scales poorly.

However, let's consider a slightly modified arrangement.

What if the answer included not only the "matching" prefix/length, but also
some (perhaps negotiated) additional entries of prefix/length, for which the
same answer would be provided?

This would reduce by at least an order of magnitude the time/bandwidth
needed to populate such a cache.

There would then be the question of the additional computational cost, vis a
vis sorting the answers and hashing them or otherwise putting them into a
meaningful data structure.

What if the standard for this, also specified the order of members of the
returned set of prefixes? This would reduce or eliminate the requirement to
process the results by sorting them, if the order were search-friendly.

This would also reduce the incremental CPU load by at least an order of
magnitude.

Lowering all of time/bandwidth/CPU would perhaps make this at least
palatable (or palletable for the upgrades needed :-))

(There would then be the question of how much data to return, and/or how to
signal/negotiate that, etc., and the potential for abuse, e.g. multiplier
attacks)

Comments?

Brian Dickson
(after a long absence ;-))