Re: [DNSOP] draft-mglt-dnsop-search-list-processing-00.txt

Paul Wouters <paul@nohats.ca> Tue, 15 April 2014 17:05 UTC

Return-Path: <paul@nohats.ca>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2EDC1A043D for <dnsop@ietfa.amsl.com>; Tue, 15 Apr 2014 10:05:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.373
X-Spam-Level:
X-Spam-Status: No, score=-0.373 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bpdoyNkAsvOi for <dnsop@ietfa.amsl.com>; Tue, 15 Apr 2014 10:05:46 -0700 (PDT)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 27A0A1A01BE for <dnsop@ietf.org>; Tue, 15 Apr 2014 10:05:45 -0700 (PDT)
Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 0C140800D1; Tue, 15 Apr 2014 13:05:42 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1397581542; bh=Xlch9nyf4id7hjYdLUVr0ZafmyIed79enEdWCoNmWC4=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=eeyJlveQKYirIwTogQPbYT5QtALjG6nh0aK1vU+D0G1LkkwnDfTx8Gt4b9dXC5os1 IPr0rWDHQBFEexw385NY/Wk3OR9qLqu11BMXLoOlPDaHIoJUmTzMvehuGmLpUYkL// RfKo5JH72TIJCHMbRSpP/xwXEhqf44SyCu0tZ7HE=
Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s3FH5fgB032704; Tue, 15 Apr 2014 13:05:41 -0400
X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs
Date: Tue, 15 Apr 2014 13:05:41 -0400
From: Paul Wouters <paul@nohats.ca>
To: Daniel Migault <mglt.ietf@gmail.com>
In-Reply-To: <CADZyTkn2Wau99zfQR+jjwHVr4Jnq3Eo=Ht+OEScbvKBLc=7e2w@mail.gmail.com>
Message-ID: <alpine.LFD.2.10.1404151301350.16509@bofh.nohats.ca>
References: <CADZyTkn2Wau99zfQR+jjwHVr4Jnq3Eo=Ht+OEScbvKBLc=7e2w@mail.gmail.com>
User-Agent: Alpine 2.10 (LFD 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/oVUITldDe4C73a456OvVs7zZQnA
Cc: dnsop <dnsop@ietf.org>
Subject: Re: [DNSOP] draft-mglt-dnsop-search-list-processing-00.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Apr 2014 17:05:50 -0000

On Mon, 14 Apr 2014, Daniel Migault wrote:

> Please find draft-mglt-dnsop-search-list-processing-00.txt

It states:

   In order to make systems end up with the same search list, here are
    our recommendations:

    - 1)  If the search list results from a manual configuration, then
       DHCP Options MUST NOT automatically affect the search list.  More
       specifically, Domain Name derived from DHCPv4 Domain Name Option
       [RFC2132] or DHCPv6 Client FQDN Option [RFC4704] and DHCP Domain
       Search Option [RFC3397], [RFC3646] are ignored for the concerned
       of search list generation.  This follows the recommendations of
       [RFC3397] and [RFC3646].

    - 2)  If the search list is not manually configured, then DHCP
       Options MAY be considered.  DHCP Domain Search Option [RFC3397],
       [RFC3646] are considered.  If considered, the search list is only
       defined by these options and only these options.

    - 3)  In the absence of DHCP Domain Search Options, the search list
       is derived from the Domain that is the DHCPv4 Domain Name Option
       [RFC2132] or DHCPv6 Client FQDN Option [RFC4704].  If so, the
       search list is only constituted of the Domain name of the host.

    - 4)  If none of these options are provided, then the search list is
       empty and resolution are directly performed over the public DNS.

While I don't disagree that this has been historically the case, with
DNSSEC on the stubs we have new issues to tackle. In the old days, we
could use the DHCP obtained DNS server for resolving, so local names
would just work. Now we don't, so that approach needs additional
configuration. So I do not believe we can keep the above listed old
behaviour intact.

If I hook into a LAN internal.nohats.ca in the office, people expect
that to become part of their search domain. And obviously at a
coffee shop with open wifi, we really do not want to add anything
to the search domain. This is all closely related to interaction with
forwarders, and what we decide to forward (local name to local
nameservers only or everything?).

For a long discussion, see:

https://lists.fedoraproject.org/pipermail/devel/2014-April/197755.html

Paul