Re: [mif] [dnsext] [dhcwg] 2nd Last Call for MIF DNS server selection document

Brian Dickson <> Wed, 19 October 2011 18:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7BA9C11E80B2; Wed, 19 Oct 2011 11:34:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.496
X-Spam-Status: No, score=-3.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZF0XDnuqAUBL; Wed, 19 Oct 2011 11:34:20 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4514111E80B3; Wed, 19 Oct 2011 11:34:19 -0700 (PDT)
Received: by bkas6 with SMTP id s6so2854607bka.31 for <multiple recipients>; Wed, 19 Oct 2011 11:34:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=09eh2298okK5eqGD2ReXW6CQ0OT/2xe2GF9wWKGpgiA=; b=aGOi0PIsGKCvZ1ljy7ufP9lxs0sdzt7jRVYPqXssZ81PZN2PLVanXoVbG1XXFtECBU hTYZAD9g2SHX3/pATQSCG+NszXA08wXrsbUfD2tkHfdNycoRyFbLe6V//4YwaZfYfxyq 4dZSXkAemadgYB7Kp8jN9AHDOc5QrWo5OvvH4=
MIME-Version: 1.0
Received: by with SMTP id a11mr12752210fai.9.1319049256645; Wed, 19 Oct 2011 11:34:16 -0700 (PDT)
Received: by with HTTP; Wed, 19 Oct 2011 11:34:16 -0700 (PDT)
In-Reply-To: <>
References: <COL118-W55403198A984BAAE44BA47B1F70@phx.gbl> <> <> <>
Date: Wed, 19 Oct 2011 14:34:16 -0400
Message-ID: <>
From: Brian Dickson <>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Wed, 19 Oct 2011 16:47:35 -0700
Subject: Re: [mif] [dnsext] [dhcwg] 2nd Last Call for MIF DNS server selection document
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiple Interface Discussion List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 19 Oct 2011 18:34:21 -0000

I'm not sure where it would belong, exactly, but certainly between
"best practices" and DNSSEC security concerns, is the basic tenet:

The DNS is a unified namespace.

This leads to a number of potential issues, which can largely be
addressed by viewing the issues from the perspective of a unified
name-space's root. And by providing lots of literal and explicit

- It is recommended that use of private namespaces be restricted to
subdomains of legitimately-assigned domains by the domain owner
exclusively (e.g. "" and NOT ".private.")
- It is recommended that unofficial namespaces be avoided where
practical to do so (e.g. .local, .fake-domain, .TBD)
- It is recommended that any and all domain names be anchored with a
trailing "." when expressed in text form, regardless of scope
(global/private, bare TLD or otherwise) to remove any possible
ambiguity (e.g. "", NOT "" which might
suggest use of search lists)
- It is recommended that inconsistent or conflicting namespace or
contents be avoided (e.g. split DNS with same labels having different
RVALUEs) (possibly handled by non-anchored names and search lists,
which result in unambigous names upon expansion)
- It is recommended that handling of restricting access to "private"
namespaces be handled in a manner that does not induce look-up
failures if the "wrong" nameserver is consulted first (e.g. ISP/global
before VPN/private, have "" return something
OTHER than NXDOMAIN, e.g. servfail or whatever anyone smarter than me
- It is recommended that configured Trust Anchors (for private
namespaces) and "learned" Trust Anchors (KSK or ZSK of securely
delegated zones) be handled in a manner compatible with any usage of
split DNS (so that signature validation is deterministic)
- It is recommended that private namespaces underneath secure global
namespaces be DNSSEC-protected with either a global learned Trust
Anchor, or a configured Trust Anchor
- It is recommended that private namespaces be DNSSEC-protected where
practical to do so

The above is just off the top of my head as possible text that could
be used. Comments on style, content, etc., are more than welcome.


On Wed, Oct 19, 2011 at 1:58 PM,  <> wrote:
> Ted, thank you for comments.
> Please feel free to propose text - I love constructive text proposals:-)
> During following week would be nice, if possible, so that we can move
> forward with the draft before the next IETF.
> Now that you say it, we might state that not any VPN can be trusted by
> default (but VPN is an example here), but e.g. a VPN Configuration Profile
> could enable the setting for that particular VPN connection. If the trusted
> VPN then **cks you up, then, well, trusted parties sometimes do that..
> Best regards,
>        Teemu
>> -----Original Message-----
>> From: ext Ted Lemon []
>> Sent: 19. lokakuuta 2011 19:07
>> To: Savolainen Teemu (Nokia-CTO/Tampere)
>> Cc: Hui Deng; <>; dnsext List; WG; DHC WG;
>> Subject: Re: [dhcwg] [mif] 2nd Last Call for MIF DNS server selection
>> document
>> The DHCP changes look good.  You can get multiple selection tuples in
>> DHCPv4 if you want, but you seem to have decided its not important, which
>> is fine by me.   Let me know if you want me to explain how to do that.
>> However, I reread the text on server selection, and it still has a serious
> and
>> easily exploited security flaw.   In order for DNSSEC validation to save
> you
>> from an attack, it has to be the case that you look the name up on every
>> possible name server to see if any claim it's in a signed zone.   If one
> does, it
>> has to be validated.   Right now it looks like if the "trusted" server
> doesn't
>> sign the zone, the DNSSEC validation will never happen.   We dealt with
> this
>> by trusting some networks more than others, and that eliminates a lot of
> the
>> risk.
>> For example, in the case of a hotel net we're okay, because it will be
> less
>> trusted than the 3G network.   The case I am most concerned with is when
>> you VPN to a site that is not trusted: the default behavior will be to
> prefer
>> the VPN link, because we presume it is more trustworthy.  A consultant who
>> VPNs to multiple corporate sites could be spoofed here though, as could a
>> user of a firewall bypass VPN.
>> Unfortunately, I don't know of a way to fix this that doesn't fire up both
>> radios for every query.   Leaving this off by default is probably the best
> we
>> can do, but it might be good to add more text to the security
> considerations
>> section describing specific exploit scenarios.   The text in 10.1 and 10.2
>> doesn't address this particular attack vector.
>> I would propose adding a requirement that there be a mode, off by default,
>> enabled by UI, in which the resolver just fires up both radios, battery be
>> damned, but I am not sure anyone would use it, because it would be
> difficult
>> to explain why and when they should.
>> So practically speaking, I am just proposing a tweak to the security
>> considerations.   I will send text if you don't object.   Sorry for the
> late
>> review.
> _______________________________________________
> dnsext mailing list