IETF Logo Mail Archive

Re: [mif] DNS selection with HE-MIF

Ted Lemon <Ted.Lemon@nominum.com> Sun, 03 February 2013 15:04 UTC

Return-Path: <Ted.Lemon@nominum.com>
X-Original-To: mif@ietfa.amsl.com
Delivered-To: mif@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78A7621F8488 for <mif@ietfa.amsl.com>; Sun, 3 Feb 2013 07:04:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.549
X-Spam-Level:
X-Spam-Status: No, score=-106.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z1szgXApthsV for <mif@ietfa.amsl.com>; Sun, 3 Feb 2013 07:04:44 -0800 (PST)
Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id CACBA21F8468 for <mif@ietf.org>; Sun, 3 Feb 2013 07:04:44 -0800 (PST)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKUQ58jJaxCF83YsUy+vcv3FPGFEOiIxcx@postini.com; Sun, 03 Feb 2013 07:04:44 PST
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id CB8AB10809F for <mif@ietf.org>; Sun, 3 Feb 2013 07:04:43 -0800 (PST)
Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 55310190052; Sun, 3 Feb 2013 07:04:43 -0800 (PST) (envelope-from Ted.Lemon@nominum.com)
Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Sun, 3 Feb 2013 07:04:37 -0800
From: Ted Lemon <Ted.Lemon@nominum.com>
To: GangChen <phdgang@gmail.com>
Thread-Topic: [mif] DNS selection with HE-MIF
Thread-Index: AQHOAhiC0CZRnojC20SeBNCskG9mTphowXmA
Date: Sun, 03 Feb 2013 15:04:36 +0000
Message-ID: <8D23D4052ABE7A4490E77B1A012B63074747BB1E@mbx-01.win.nominum.com>
References: <CAM+vMERak2vAoYFeSLRep2xjpm480qPjutyv4-tV=KtU0XO=fw@mail.gmail.com> <8D23D4052ABE7A4490E77B1A012B630747479BA9@mbx-01.win.nominum.com> <CAM+vMETvE==qUZO2_rhyUB+=ChUR4a9CoTCF+q=gBL2cRA+0UA@mail.gmail.com>
In-Reply-To: <CAM+vMETvE==qUZO2_rhyUB+=ChUR4a9CoTCF+q=gBL2cRA+0UA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [192.168.1.10]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <8B1A4007C092B44F8787E7CC70E6B98F@nominum.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: mif <mif@ietf.org>, draft-ietf-mif-happy-eyeballs-extension <draft-ietf-mif-happy-eyeballs-extension@tools.ietf.org>
Subject: Re: [mif] DNS selection with HE-MIF
X-BeenThere: mif@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiple Interface Discussion List <mif.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mif>, <mailto:mif-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mif>
List-Post: <mailto:mif@ietf.org>
List-Help: <mailto:mif-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mif>, <mailto:mif-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 03 Feb 2013 15:04:45 -0000

On Feb 3, 2013, at 9:12 AM, GangChen <phdgang@gmail.com> wrote:
> I would like to learn more about the problems.

There are quite a few separate issues.   We generally treat DNS results as if they are essentially stateless—regardless of who asks the question, they should get the same answer.   However, there are a lot of situations where this simply isn't true.   Some of them are covered by RFC6731, but most are not.

The most obvious cases are situations where there is in fact a split dns architecture, but RFC6731 isn't applicable.   This is probably most split dns situations.

The second set of cases are cases where DNS is used to operate a captive portal.   In these cases, the DNS server on the captive portal will give different answers than a DNS server on a working 3G link, for instance.   So if HE treats DNS responses as if they were generally equivalent, either we will be unable to ever see the captive portal web page, or we will be unable to use the 3G network without logging in to the captive portal.   Neither situation is desirable.

A third, less obvious, set of cases are where DNS is used to optimize CDN delivery.   In this case, suppose I have a 3G interface that doesn't have CDN-optimized DNS, and a connection through my ISP on the wireless LAN that does have CDN-optimized DNS.   In this situation, if I treat the two DNS servers as equivalent, then I may use the 3G DNS server to look up information I will then use to connect to the CDN over the wireless LAN interface.   This will likely result in suboptimal routing, and unacceptable performance.

This is why when I've discussed this issue in the past, I've always argued that each provisioning domain needs to be treated separately.   We should not look up names in one provisioning domain and use them in another; if we want to try connecting across multiple provisioning domains, we should do DNS lookups on each such provisioning domain, and use the results we get only for connecting within that provisioning domain.

v2.23.0 | Report a Bug | By Email