Re: [DNSOP] DNSSEC in local networks

Warren Kumari <warren@kumari.net> Wed, 13 September 2017 00:04 UTC

Return-Path: <warren@kumari.net>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CED17133197 for <dnsop@ietfa.amsl.com>; Tue, 12 Sep 2017 17:04:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com
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 i-TIpK1hzGbE for <dnsop@ietfa.amsl.com>; Tue, 12 Sep 2017 17:04:14 -0700 (PDT)
Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68E7F13318A for <dnsop@ietf.org>; Tue, 12 Sep 2017 17:04:14 -0700 (PDT)
Received: by mail-wr0-x22c.google.com with SMTP id o42so25576550wrb.3 for <dnsop@ietf.org>; Tue, 12 Sep 2017 17:04:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hYgh0uWJlM/jbJOFAtjKH1r1DOtx/SiAJA5lGUh6bcE=; b=UNrv6wlizlHSsdcHKJKGJ0OnlSn+hgVmtRMxEIqbrwehb8xgHnuhaMfdzdL+BYTs8z TMw/v0XxMLHNiZ7gkkrVO0Z5t1TZfwuEv+pXX/SrLSSqUFQCzfLcAavL0e76ZfyOjrHZ cS1vnm7VDfwew3eC9GLArsYvG/rJCzjBPmeEEc3FM2k7sZaJlaEYoBrH7ETZgsHaGoar O/GDBKRRZSL7HWqFyz/oPhjUCQf/2gwpcZNcZwMsE1RrmGq1Dx6nzEJmFbKNe9nF3iBc awowz7tSVLA1et4jklqIKoTsI7gV3iDAtnbRLLUBLOGzbZqAIVaHRkv6NkGwVrWQ1mVM tzSw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hYgh0uWJlM/jbJOFAtjKH1r1DOtx/SiAJA5lGUh6bcE=; b=LWxKJakMWmvfG+wdKFkyc8vll76wT/AwZVmh0Wsc2iGIAhX8tlqivb81LV5u0u6YnP DnVfxIdZSeoF5dS8fyuJc0CJmLrOk7pTlx27ZJI1ht5GaVy9DxYQvNsYf65HDKitLIez A++8s+4pvxeDgkGLqmCUE2TvTRoWHg3p9n8HgMmQkdF1Wm7TsUxeq5gMJgzFZtTMGFVh 6jZBZA/zkGnyRX+m+KYD4qQEaLlpayG+IrsAHU8Sfw0UXfbegq5ubhw8eF0OyTfXaR+0 89BO2+2zrARn73/a9UdtOxcs3b5D/W+4lBXaDWRHohLwIaogOzWcS6LNA3aowuEkAm3O GWMQ==
X-Gm-Message-State: AHPjjUgg9Zx7YhlEi0zm9t4+XcyJ3MkBN17bR8e5TOSdF/aIxCnMTx5P 1bMDb0aRLhW/SHoQwQ/+ooq/ZNNPaaMLBIrLYtHLNS8V
X-Google-Smtp-Source: ADKCNb4yOXtDdQhctkyWg+fOcoyAv4KEtzrgIaf08LhzRDi8o6lpCPyqT/q03jpDLQ1M7u/5WlBEMukfR9RAMnkK8jk=
X-Received: by 10.223.156.199 with SMTP id h7mr10817342wre.170.1505261052569; Tue, 12 Sep 2017 17:04:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.164.141 with HTTP; Tue, 12 Sep 2017 17:03:31 -0700 (PDT)
In-Reply-To: <20170904204549.A05018415E35@rock.dv.isc.org>
References: <150428805872.6417.9525310755360551475@ietfa.amsl.com> <59A9B760.2060209@mathemainzel.info> <alpine.DEB.2.11.1709012044210.2676@grey.csi.cam.ac.uk> <59A9BCA2.6060008@mathemainzel.info> <20170903043202.GA18082@besserwisser.org> <59AC4E42.9080600@mathemainzel.info> <60304450-DFA3-4982-B01D-CC33C49BDCFC@isc.org> <59f8c88caaf82a5884aa87223d49e7e4.1504505559@squirrel.mail> <3B75D240-13B9-4A94-B56D-24E83B4A4A8F@rfc1035.com> <3fe7bc511a990b0288b645dc176e1ef3.1504515284@squirrel.mail> <20170904090455.4249F8411CFC@rock.dv.isc.org> <c0c73dab49c6452c616c86656704ecd0.1504518603@squirrel.mail> <20170904122222.C270F8413534@rock.dv.isc.org> <efe320cf9580d4c1bb2b26dd1c294306.1504529679@squirrel.mail> <20170904204549.A05018415E35@rock.dv.isc.org>
From: Warren Kumari <warren@kumari.net>
Date: Tue, 12 Sep 2017 20:03:31 -0400
Message-ID: <CAHw9_iLuAqRO=bQMyGeHmaeJZPdf2Q1BVaH3pg8NftJzpMSSSg@mail.gmail.com>
To: Mark Andrews <marka@isc.org>
Cc: "Walter H." <walter.h@mathemainzel.info>, dnsop WG <dnsop@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/pdRxfnGtGEJnJlbhaQgRUjnqyXA>
Subject: Re: [DNSOP] DNSSEC in local networks
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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: Wed, 13 Sep 2017 00:04:17 -0000

On Mon, Sep 4, 2017 at 4:45 PM, Mark Andrews <marka@isc.org> wrote:
>
> In message <efe320cf9580d4c1bb2b26dd1c294306.1504529679@squirrel.mail>il>, "Walter
>  H." writes:
>> On Mon, September 4, 2017 14:22, Mark Andrews wrote:
>> >
>> > In message <c0c73dab49c6452c616c86656704ecd0.1504518603@squirrel.mail>il>,
>> > "Walter H." writes:
>> >> where there anyone who said: "don't use it", 15 years ago?
>> >
>> > Yes.  There were lots that discourage the use of .local, lan,
>> > .corp etc.  Just becaue you didn't hear from them doesn't mean
>> > they weren't out there.
>>
>> a discourage is not a "don't use" :-)
>
> We gave them fair warning that and domain they choose could be
> allocated in the future.  We told them to the advice you have been
> getting today.  Use a zone registered to them.  They, like you are
> today, are ignoring the advice.
>

Yup, but people continue to ignore the advice, and, as far as I can
see, will continue to do so - .internal is intended to give people a
place where they can go do whatever they want without just squatting
on something.
I personally believe they should just use something which they have
registered -- but, I also believe that abstinence is the only way to
prevent teen pregnancy. Seeing as my believing this doesn't actually
*stop* teenagers having sex, I'd like them to do so in the least risky
way possible -- .internal, a condom for the namespace.

>> >> > 'home.arpa' is in the process of being registered so that it
>> >> > can be used safely in the environment it is designed to be used in.
>> >>
>> >> yes, but commonly for residental networks, not company/enterprise
>> >> networks,
>> >> they want/need something shorter like ".corp", ".lan", ".local", ...
>> >

Perhaps corp.arpa, or internal.arpa, or home.arpa is the right answer
- unfortunately I think that they fail the "looks pretty" property.

>> > Want maybe, need absolutely not.
>> question: why isn't this the answer of a car dealer?
>
> Because the car dealer is trying to take as much money off you as
> they can.  We on the other hand are trying to save you money by
> stopping you and everyone else getting into situations that will
> cost you/them thousands of dollars to rectify in the future.
>
>> > Everyone was told to register the domain you want to use, there was
>> > no exception for active directory.

Sorry, nope. You might have said that, I might have said that, but
many people remained unaware -- also Microsoft suggested (
https://support.microsoft.com/en-us/help/296250/the-domain-name-system-name-recommendations-for-small-business-server
)

"Three practical methods to name the DNS domain are:

* Make the name a private domain name that is used for name resolution
on the internal Small Business Server network. This name is usually
configured with the first-level domain of .local. At the present time,
the .local domain name is not registered on the Internet.
* Make the name a sub-domain of a publicly registered domain name. For
example, if the publicly registered domain name is Contoso.com, a
sub-domain of Corp.contoso.com can be used.
* Make the name the same as a publicly registered domain name.

Most Small Business Server customers should use the first method. The
following list describes some of the advantages when you use a
separate and private domain name for the local Small Business Server
network:

The management of the local namespace is controlled by the Small
Business Server Server. When you use a private FQDN for local DNS name
resolution, the DNS server becomes the start of authority for the
local domain. This result means that a query to external DNS root
servers is not required for local resource name resolution.

The security may be increased for your DNS server by not enabling zone
transfers by means of the zone transfer properties of the forward
lookup zone. Because dynamic registration of internal hosts can occur
with the DNS server, if you disable the zone transfers from external
clients, you can limit the exposure of internal host names to the
Internet.

The natural separation of internal and external networks occurs
because of the use of a separate internal namespace. A client query
generated from the Internet for www.contoso.local does not return any
valid domain information because .local, at the present time, is not a
registered domain name. However, by using the Web Publishing rules in
Internet Security and Acceleration (ISA) Server, internal Web sites
can be hosted externally and viewed by using resolvable domain names.
This hosting still requires a registered domain name as well as the
appropriate public DNS records that resolve to the external IP address
of Small Business Server. Refer to "Configuring Publishing" in ISA
Server Help for more information about Web Publishing rules."


Microsoft now recommends that people put stuff under a registered
name, but a significant number of people heard (and followed) the
earlier advice.
Microsoft also used .corp (or contoso.corp) in a large number of
examples (e.g: https://blogs.technet.microsoft.com/networking/2009/04/16/dns-client-name-resolution-behavior-in-windows-vista-vs-windows-xp/:
, including (IIRC) the step by step walkthrough of how to setup Active
Directory - and many people followed this --
http://www.enyo.de/fw/notes/the-great-corp-renaming.html

So, yes, people shouldn't have just used .local, or .corp -- but I
entirely understand why they did.

Reserving a TLD for internal shenanigans certainly won't fix existing
deployments. It also won't stop people from sometimes squatting on
whatever-they-feel-like. However, it will give people who are going to
do this sort of thing a safe place to do it. As Andrew says, there are
an almost unlimited number of strings that can be made with 63 octets.
I think the benefit of giving people a sandbox for this outweighs the
costs (basically none). Yes, there will be collisions if e.g.
companies merge, VPNs, and other cases (just like there were with
RFC1918); I think we need to note that as a disclaimer in the
document. People choosing to use this should be consenting adults.

>>
>> not really, at those days only a few TLDs where possible, the many TLDs
>> came some years later ...
>
> People were wanting to deploy more TLDs from the moment the Internet
> was opened up to the public.
>
>> by the way: where is the problem with .home or .corp?
>> I ask this, because at my hoster I pre-reserved my "local domain" - a
>> .home, that I have used for many years several zears ago and nothing
>> happened ...
>>
>> > IPv6 would have been deployed a lot sooner. :-)
>>
>> not really, my ISP is still IPv4 only ..., my IPv6 connectivity is a
>> HE-tunnel ...
>> and the brand new OS from Microsoft still has the bugs inside: TEREDO, ...
>> which I had to deactivate first, before it is usable with IPv6 at all ...
>
> If you didn't have the relief valve of RFC 1918 addresses then yes
> IPv6 would have come a lot quicker and stuff like TEREDO wouldn't
> exist.
>
>> > Except such systems exist.  Go look at what a Mac does.  ping for
>> > test.local and look and port 5353 traffic and compare it to port 53
>> > traffic.
>>
>> I know, this RFC was written by Apple;
>>
>> no Apple no problem, I would say :-)
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf