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
