dukhovni> A client using 8.8.8.8 as its iterative resolver and dukhovni> delegating all input validation to that upstream becomes dukhovni> vulnerable not only to data forgery, but also to validation dukhovni> bypass if an MiTM pretending to be 8.8.8.8 returns unvalidated dukhovni> data.
In a perfect world, sure. But the reality is that much of the world's devices use their ISP or google or their company resolver and accept whatever those resolvers say without doing validation in the OS. dukhovni> The only stub resolver one can expect to not be bypassed is dukhovni> the stub resolver in the OS libraries. These stub resolvers dukhovni> vary from OS to OS, and don't get a lot of maintainer dukhovni> attention. And that lack of love is why expecting the OS stub to be the good actor isn't a quick fix. dukhovni> So whether you like it or not, the burden is on the dukhovni> application, and any higher level libraries known to deliver dukhovni> syntactically validated results. Nothing to do with what I like. It's what the majority of the world does that we have to deal with. Asking the world to do better is worth trying but how many OS stub resolvers validate? How many in-browser stubs validate? On the other side, how many apps just take whatever the OS stub hands them and how many OS stubs just take whatever the upstream resolver hands them? We can't ignore reality and we must do what we can now. _______________________________________________ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
