> On Jun 21, 2018, at 1:40 PM, Shumon Huque <shu...@gmail.com> wrote: > > On Thu, Jun 21, 2018 at 8:05 AM Tom Pusateri <pusat...@bangj.com > <mailto:pusat...@bangj.com>> wrote: >> On Jun 21, 2018, at 12:19 AM, Vladimír Čunát <vladimir.cunat+i...@nic.cz >> <mailto: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. > > SIG(0) can't really protect you from an untrustworthy resolver. It can ensure > that the question you sent and the answer you got back from the recursive > server was not tampered with in-flight. But it can't detect whether the > recursive server modified any data in its response before it signed it with > SIG(0). If the response contained DNSSEC signed data and the stub was > validating, then those pieces of the response could be authenticated. But not > anything in the header, question etc - all of that could have been modified > by the recursive server without detection. > > 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. > > Most competent resolvers will check that the response that they got back was > for the question they asked. So I don't think they would "lazily just grab > the A record answer without comparing the RR name". > > I don't think SIG(0) really helps much here. The response signature has to > include the entire query message, but the actual response can contain > anything the recursive server puts in there. > > 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. > > DNSSEC is really the solution to this problem. DNSSEC signatures cover the > entire RRset, so authoritative (or recursive) servers cannot strip away some > of the RRs without detection by a downstream validator. > > Shumon. >
Thanks. In the case where a zone isn’t signed but the authoritative server supports SIG(0), the response could be verified that it includes exactly what the server sent. But the KEY would need to be DNSSEC validated or it probably can’t be trusted to verify the SIG(0) response. Tom
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
