In the current state a host with multiple interfaces would roughly randomly send DNS query over one interface to primary DNS server of that interface. The order may be determined e.g. by the order in which the interfaces were opened (if e.g. the DNS server learn first or last is preferred over others).
Hence from DNS system point of view a current truly multi-homed host may already ask questions from any DNS server, and it will not ask from all. This option directs a host to ask question from some of the servers it could have anyway send its question to. How DNSSEC cannot manage to secure DNS queries in that case? Best regards, Teemu > -----Original Message----- > From: ext Ted Lemon [mailto:[email protected]] > Sent: 14. tammikuuta 2011 18:00 > To: Savolainen Teemu (Nokia-MS/Tampere) > Cc: [email protected]; [email protected]; [email protected] > Subject: Re: [DNSOP] draft-savolainen-mif-dns-server-selection-06.txt > > On Jan 14, 2011, at 10:53 AM, <[email protected]> wrote: > > If I now have e.g. multihomed Linux, often or usually the > /etc/resolv.conf points to the DNS server address learned most recently > via some mean (RA, DHCPv6). But people are not too worried what is the > content of that file? I.e. attacker could just send new RA with DNS > server address option and cause problems by drawing DNS traffic to that > server? > > The level of concern is that we are just getting to the point where we > have a DNSSEC infrastructure that can be used to detect fraudulent DNS > information. And this proposal puts that at risk by providing a > mechanism for subverting DNSSEC. It does this because the whole point > of the proposal is to prevent unnecessary duplication of effort: doing > DNS lookups against all proposed DNS servers. > > So the point is not that it makes things worse than the status quo, but > rather that it potentially prevents a solution to a problem in the > status quo that we thought we'd developed. > > > Shouldn't we work e.g. on securing all DHCPv6 signaling? > > Possibly, although it's not clear what the security model for such a > thing would be, nor even if there is a single security model that would > work. That's why we've never successfully solved this problem. We > have mechanisms for securing the transport, but that says nothing about > trustworthiness of information provided by the server. _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
