El 16 ag 2017, a les 9:26, Toke Høiland-Jørgensen <t...@toke.dk> va escriure: > Ted Lemon <mel...@fugue.com <mailto:mel...@fugue.com>> writes: > >> El 15 ag 2017, a les 19:32, Toke Høiland-Jørgensen <t...@toke.dk> va >> escriure: >>>> In both of these cases, you are better off doing what we discussed >>>> earlier and setting up your own DNS cache, possibly with a whitelist >>>> for domains you want to send to the ISP forwarder. >>> >>> Sure, and that's what I usually do. But if we can't specify that >>> behaviour for homenet, at least trying all upstream DNS servers gives a >>> better chance of finding one that works. >> >> I'm really sorry, but I'm actually having trouble contextualizing the >> failure mode that you are talking about here. Didn't I agree with >> you in a previous message that we should try all the upstream DNS >> servers? > > Hmm, right, I guess you did. My point was more that an MPvD-aware client > that only uses on PvD may experience worse performance than one that > uses the in-home resolver. But I guess the client should be smart > enough to deal with that?
I think this is a real edge case. You have two connections, the DNS server on one of them is broken, the DNS server on the other is not, but the second connection performs so much worse than the first that you'd rather use an answer from the DNS server on the second to contact a service on the first. If you were in an engineering staff meeting trying to justify adding extra code to do this, what would you have to say to get the group to agree to do the work? What would that code look like? Sometimes things are just broken. Expecting a homenet router to solve every possible configuration screwup on the part of the ISP isn't realistic. As customers of these ISPs, we expect them to do a decent job, and if an ISP fails often enough to make this code worth writing, they probably need to be in a different business. >>> You may be right that hacking up a working prototype isn't that hard. >>> But the failure modes change from "the internet is down" or may "I >>> cannot access site A", to "site A is working every third attempt, except >>> it is entirely broken on device X" maybe even with an added "ah, but >>> it works on device X if I go into the kitchen". >> >> Didn't we agree that we aren't round-robining? > > Yeah, but I was referring to the failure mode for MPvD vs non-MPvD > clients. I.e. if one of the resolvers fails for whatever reason, only > MPvD-aware clients that happen to select that PvD will notice; whereas > if there's only one resolver it will be very obvious when it's not > working... That's not how PvDs work. You don't select one and only use that. You try both. >>> Hmm, while writing this is occurred to me that it might make sense to >>> just export the ISP DNS server(s) directly in the MPvD-only RAs? >> >> This would certainly work, but now you can't have your nice local >> resolver that does what you want. However, I think you are right >> that this is the right default behavior for MPvD-aware devices. > > I would keep the in-home resolver for clients that do not support MPvD; > and probably also announce it as a separate PvD for MPvD-aware clients? > > Also, I think I would prefer running a single resolver in the home, > rather than running one on every router. I think there's some text in the document that was put in before I did the dnssd discovery relay stuff and hasn't been updated since. There does need to be a dnssd discovery relay running on every router. And if the dnssd registration protocol is running over unicast, then we need some kind of relay on port 53 on every router, so that we can tell that the device that's doing the registration is on the local link. If we do the registration through the discovery relay, this isn't necessary. I don't remember how Stuart specified this, so I'm not sure. But the motivation for doing this is not that every router has to have a caching recursive resolver running on it.
_______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
