On 21 December 2016 at 10:53, Paul Wouters <p...@nohats.ca> wrote: > > And 1) should not need to break DNSSEC. IETF should come up with a > better solution for signaling a DNS lookup might be unhealthy for > the enduser. > > Other than returning an altered answer (pointing to an informational site) or no answer at all, what would this look like in practice?
The signal probably needs to be in-band in the DNS response, and downstream recursive/forwarding servers need to know to pass those data along with certain responses. So there's a change to the protocol. Libraries (glibc, etc.) need to be modified to receive and understand these new data and pass them on as part of a gethostbyname() call, so there's a change to all operating systems. Applications that use the DNS need to understand this new signal and know what to do with it, so there's a change to every application that uses the DNS. These are the things you need in place for an alternative to be effective. I think that would be a fantastic way for things to work, but we haven't even managed to get a majority of applications to implement DNSSEC yet. If you think the above sounds silly, then please propose some other alternative with a shorter path to deployment. Taking it out of band of the DNS probably makes things simpler, but then you still need to modify every recursive server and every application. In the intervening decades while that is being designed and deployed, operators are going to continue using RPZ or something like it, so why don't we document that, and how it should work?
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
