Subject: Re: [DNSOP] draft-savolainen-mif-dns-server-selection-06.txt

From: <[email-masked]>
Date: Mon, 14 Mar 2011 13:26:39 +0000

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-masked] [mailto:[email-masked]] On Behalf Of
> Savolainen Teemu (Nokia-MS/Tampere)
> Sent: 19. tammikuuta 2011 11:12
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> 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-masked]
> https://www.ietf.org/mailman/listinfo/dnsop