I'd be glad to have both. Yes the applications should do it either via better libraries or some other mechanism. But as there will always be badly written applications I'd quite like to be able to tell my local resolver "validate any response you get and reject anything that fails". It gives me better depth of protection and at a local level, be it home or business it would be good to have the choice especially if exceptions could be carved out.
If I had to bet on which would happen first/at all "resolver libraries/applications being fixed" or "A DNS resolver implementing validation" I know where my money would be. Rejecting "malformed" responses at the resolver wouldn't seem to be a good thing[tm]. -----Original Message----- From: dns-operations <[email protected]> On Behalf Of Viktor Dukhovni Sent: Wednesday, August 18, 2021 2:53 PM To: [email protected] Subject: Re: [dns-operations] Injection Attacks Reloaded: Tunnelling Malicious Payloads over DNS > On 18 Aug 2021, at 2:27 am, Paul Vixie <[email protected]> wrote: > > I urge you to reconsider your position. apps should be calling things > like > getnameinfo() and getaddrinfo(), and those should fail early and often > if their expectations are not met. that's what shared libraries are > for, and that's what a 64K codepoint space is for. I already mentioned that I am supportive of validation in the system libraries above the raw (qname, qtype) DNS lookup. Thus in particular getaddrinfo() and getnameinfo() or per my example, new APIs that return validated TLSA records. All such validation should be *on host*, and not delegated to remote servers. I believe it would be a mistake to enforce syntax in off-host iterative resolvers (whether public, home or enterprise). There's no way to know what they've validate and bypass opportunities for MiTM attacks. -- Viktor. _______________________________________________ dns-operations mailing list [email protected] https://secure-web.cisco.com/1H3ag5UH0LaTny6OObGWbJ7_xqR5OxlyOK6qZ8LPXR-mInZsahdKsyiDptJp8Sp8iqLaNLVK6BBgGcdY7YMI5j6fNLIBw8I-RuAuJsFav-BjHEl3LVmu350ibQOdZGM8Fg7Si875UOQURBPFJSzEdUqo6FfY5Xq_rZ4JokoLa9QXuCosaQ87zHbZ4nSsk_h6cY-vzPt8VUhPyNeON1Tad-pInhEXTH7WvUbuQmAlLU2w/https%3A%2F%2Flists.dns-oarc.net%2Fmailman%2Flistinfo%2Fdns-operations _______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations
