Re: [mif] New revision of DNS server selection

[Ted Lemon <[e-mail]>]

On Nov 11, 2010, at 5:53 PM, <[e-mail]> wrote:
> But then elsewhere people say network knows always better:) I'm confused of IETF:)
> The user can fallback to use single interface. 

How would the user know to fall back to a single interface?

> 
>> the other where an attacker tricks the client into sending messages for
>> a particular subdomain through it, while leaving the rest of the DNS
>> service untouched.
> 
> The latest draft now recommends using DNSSEC to validate responses.

I argued earlier that using DNSSEC without this draft was a better solution than this draft.   I still think that's the case.   The problem with recommendations of this sort is that they aren't enforceable, and aren't likely to be followed.  If, in order to get the behavior you want, you *have* to sign the zone, then that's more likely to happen.   So while I agree that a *requirement* to use DNSSEC here, if followed, would solve the problem, I don't think that the suggestion in the spec is going to help very much.

> Of course attacker can still *route* packets (and cause user to go to external side of www.corporation.com instead of internal?-)

This wouldn't work, because presumably they have different IP addresses.   If they have the same IP address, there's no need to have split DNS.

> In some scenarios the uplinks are always trusted (BBF). Sometimes you can administratively limit which interfaces to trust.

You are talking about the situation where the ISP controls the device that's doing the protocol then, right?   Traditionally the way we've done stuff like this is to put it in a cablelabs encapsulation; that way the people who need it for boxes they control have a clear specification, but it's not implemented on devices to which that specification doesn't apply (e.g., my iPad).