Hm. What I think the ideal resolver to have on a homenet is as follows: (1) It can be configured to scatter queries randomly to a large number of resolvers all over the internet. (2) It can be configured to send certain queries to forwarders provided by one or more local ISPs (3) It can be configured to filter domain names based on a subscribed list (or a set of subscribed lists) of known-bad domains. (4) It can be configured to provide its own answers for some set of names, in order to break devices you own and have paid for out of provider-supplied walled gardens. (5) ...
However, this feels to me like it's a laundry list of features that are not _required_ by a homenet. Many of these features require a fair amount of understanding to configure. Doing (3) in the local resolver is actually hard, because the list can be quite large, or else it's privacy-violating, because you have to send your query stream to the thing that manages the list. Ideally (3) would be done on the same mass of resolvers that you are using for (1), so as to keep the query stream private. The point is that what I have specified in the architecture document is what is minimally required to allow a homenet to function given ordinary ISPs and ordinary users. I think trying to do some of the things on the above laundry list would be very interesting work; trying to get it to where end-users can use it without being experts and without being made vulnerable to scams would be very cool, but is out of scope for this document. Does that make sense? On Sun, Aug 13, 2017 at 6:52 AM, Toke Høiland-Jørgensen <t...@toke.dk> wrote: > Ted Lemon <mel...@fugue.com> writes: > > > What I find completely perplexing about this conversation is that you, > > Markus and Toke, all of whom I know to be smart people, think this is > > hard. What is hard about it? I think the reason you think it's > > hard is simply that you don't know how to do it. > > Ah no, this was not was I was trying to express. As you say, technically > implementing what's currently in your draft is doable, but adds a small > to moderate amount of complexity. This can be acceptable, *if* it > provides a corresponding benefit. However, I do not believe that it > does, for two main reasons: > > 1. In every encounter I've had with an ISP-provided DNS server, that > server is either (a) flaky, (b) censored or (c) both. So limiting > ourselves to getting replies from just one upstream for a given query > is going to give worse performance than using all available servers > (or just doing our own full recursing from the root). > > 2. Even if DNS queries are paired with source prefixes, the client still > has to pick which source prefix to send the DNS query from; how is it > going to do that? (This may just be me that is ignorant of the > details of the MPvD architecture; if so, please do enlighten me). > > Together, these points mean that as far as I'm concerned, what you're > proposing is adding complexity to achieve a behaviour that is going to > result in *worse* performance than doing the simple thing. Which is not > a good proposition, as I'm sure you'll agree. > > Now, as I said a few mails back, I am perfectly happy to be convinced > that there *is* a benefit worth paying the complexity cost for; but, > well, someone is going to have to do the convincing... :) > > -Toke >
_______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
