> On Jun 21, 2018, at 12:19 AM, Vladimír Čunát <vladimir.cunat+i...@nic.cz> > wrote: > > On 06/20/2018 04:59 PM, Tom Pusateri wrote: >> DNSSEC will tell you the answer you get is correct but it could be a > to a >> different question or be incomplete. > Can you elaborate on that point. I believe in signed zones you are able > to verify almost everything, in particular existence of the queried-for > RRset and its exact value, except for details like current TTL. > > --Vladimir >
I’ve been thinking about the case when you are given a DNS recursive resolver over DHCP and you don’t necessarily trust it. If you send a query with the DO bit set to a recursive resolver for the A record for foo.example.com <http://foo.example.com/> and the recursive resolver modifies this query to foo.exampl.com <http://foo.exampl.com/>, you can get back a validated DNSSEC response with the A record answer, RRSIG, NSEC(3) records all for the wrong question. The resolver code in the OS or application would get back the matching DNS header identifier and if it lazily just grabbed the A record answer without comparing the RR name, it could be misled. You can detect this without SIG(0) so maybe that was a bad example. But if you always sent a SIG(0) signed question and got a signed answer, you could detect this and possibly other future attacks and drop it before even parsing the answers. In the case of missing answers, I was thinking that if there were multiple A records in the response and some were filtered, you could not detect this without a SIG(0) signed response from the authoritative server. This would be important if one server was compromised and the recursive resolver filtered the response to exclude the other A records pointing to servers that weren’t compromised directing you to the compromised server. If I’m wrong about the second case, then I concede. Thanks, Tom
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
