On 9/24/19 12:36 PM, Tony Finch wrote: > Petr Špaček <petr.spa...@nic.cz> wrote: >> IMHO the most useful information is dichotomy: >> >> a) the problem is local (= call network admin/ISP/telco) >> >> b) the problem is remote (= call your bank because their internetbanking >> broke and _do not your bother ISP_). > I think that's helpful. > > There's an interesting case wrt blocking / censorship, e.g. "near block" > => ISP is responsible; "far block" => required by force of law.
And when *forwarder* returns that the domain was blocked (via this RFC)? If we go this near/far way (and I would like that), I'd suggest that we additionally try to polish the semantics for forwarding and caching, i.e. how the errors might best bubble through these layers. When a resolver only talks to other resolvers, it currently can't often determine whether the problem is in them or in authoritative servers - it gets the same SERVFAIL, but perhaps if all layers support extended codes and we design them well, it might be possible to "reliably" assign blame to authoritative side in more cases. Example: the authoritative servers don't reply at all (to the forwarder), so possibly after trying a second forwarder with the same result, we probably want to assign blame to the authoritative servers and not to the forwarder. Well, I'm a little sorry for suggesting such a scope creep, but still... --Vladimir _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
