New revision is now available: http://tools.ietf.org/html/draft-ietf-mif-dns-server-selection-01
This revision contains a clean-up pass and also: - Clarification of deployment scenarios - Interaction with OPTION_DOMAIN_LIST - CNAME/DNAME record considerations - More DNSSEC considerations here and there - Conflict resolution improvements if same DNS server address is received multiple times but with different suffix/prefix list - Valid lifetime consideration (using DHCPv6 Information Refresh Time Option) Best regards, Teemu > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Savolainen Teemu (Nokia-MS/Tampere) > Sent: 19. tammikuuta 2011 11:12 > To: [email protected] > Cc: [email protected]; [email protected]; [email protected] > Subject: Re: [DNSOP] draft-savolainen-mif-dns-server-selection-06.txt > > Hi, > > > Your assertions about the state of the art in DNS resolver > > implementations is probably correct. However, essentially what you > > are proposing is to take this broken behavior as a standard, and then > > build new functionality on it. The problem is that the behavior is > > Well, if the only standard is de facto standard then I think one must build on > top of that:) > > > The way your proposal breaks DNSSEC is by allowing an attacker to > > convince your resolver to treat a pre-arranged server as the authority > > for certain named zones. > > No, this option is not intended to say a DNS server has any authority. This > essentially says if lacking better information the pointed DNS server might be > a good pick. And after your comments I have clarified to the draft that the > host should not stick only to this DNS server, but can try also others. > > > Hm. Okay, so the reason this is an issue is that I'm assuming the > > resolver doesn't do its own validation. And you're right that if it > > doesn't do its own validation, it's not much worse off using this > > option than not using it; the degree to which its worse off is that > > this option allows the attacker to deterministically attack certain > > domains, whereas without the use of this option the attacker would, in > > a best-case scenario, be relying on chance to succeed in its attack. > > Correct. > > > This actually makes me feel a lot better about the proposal. I'd like > > to see the proposal require that the resolver validate any query itself > > if it uses the option; otherwise we're going to see interoperability > > problems with this option once resolvers *do* start validating, because > > people will have set their internal zones up wrong. > > Sounds good, will include in -01. Actually I assumed host validation already, > but I didn't spell it out in the draft. > > Going off-topic a bit, maybe someone here could tell me in which case a host > *can* trust DNS server to do the validation, save the case where host talks to > DNS server over trusted access (e.g. VPN/IPsec or cellular)? > > > I think you also need to document the signing architectures that will > > work with this option: either don't sign the zone that contains > > referrals for the internal zone, or else sign two copies of the zone; > > one that's visible from outside and contains no referrals, and a second > > one that's visible from inside, and contains referrals. > > This makes me feel even more so that the draft should have co-author with deep > DNSSEC expertise.. > > > The validating resolver obviously must use the substitute server for > > the entire query, not just for the queries in that subdomain, or it > > will get the wrong information from its query for the referral to the > > internal zone. > > Let try to follow this. If resolver gets CNAME/DNAME reply, it must send > following queries to the same DNS server? > > > I realize this may not be agreeable to you, but if it is, I could > > attempt to write text for it. I am not an expert on DNSSEC, so > > someone who is probably ought to read the text and criticize it. > > I would very much welcome you, or someone with better DNSSEC knowledge than I > do, to co-author the document. By the time of IETF#80 deadline should be just > fine. > > Anyhow, it is MIF that will eventually decide what is agreeable, as this is > now MIF WG doc. However, for me personally it is easier to judge when we have > text in I-D rather than on hundred emails:) > > Teemu > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
