[DNSOP] Fwd: DNSSEC in local networks

william manning <chinese.apricot@gmail.com> Wed, 13 September 2017 01:54 UTC

Return-Path: <chinese.apricot@gmail.com>
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 9EAD7133209 for <dnsop@ietfa.amsl.com>; Tue, 12 Sep 2017 18:54:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 UyCyM6xVGo7A for <dnsop@ietfa.amsl.com>; Tue, 12 Sep 2017 18:54:38 -0700 (PDT)
Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (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 BCCB7132F2E for <dnsop@ietf.org>; Tue, 12 Sep 2017 18:54:37 -0700 (PDT)
Received: by mail-io0-x22d.google.com with SMTP id n69so55727182ioi.5 for <dnsop@ietf.org>; Tue, 12 Sep 2017 18:54:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=YprYatw2tHuKi+wSxASreVr1XLGFCovs77BgBBi+EQY=; b=eDa7imNpaM4cG1nwpp/qOrdgON+nV/PyZ95YS5gKCOswC47JcF7YL+FhzxUOFUhaB+ 56mo/CeQAmKZ5x9Wa4YMvGHUqrWAvninLaXtzKcGJY0knoGTVR9BzzW3AekJ22m3p4ci 7qQ2LMQzuUlojPS+KxLlmkxsJ0oZ7F1RJKAudzOh/2w+qUiyqi+Dfnabs4v9e9xedr3G dBWAumkKP+Sq8ffXyxIdYVpE3Ch3hpHPRKlxwkITPI/0ft3E4TSQPuiEjYv21p1gNrpQ X9Wnh0fBO9qSEOSg+uqfBqcL5SeMxfw5QhPF7PanZmAzGC/C9iOkj9eBqdlpXbz/uWzo 941Q==
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; bh=YprYatw2tHuKi+wSxASreVr1XLGFCovs77BgBBi+EQY=; b=UKxYzaGldNENEDpL4VQHSa9vP3UAjk5sWnGpYabNH9u/PE+kRtHsjUa3HPM0sy5GPm ztSEI1hnQ3nTfI3F88YxUXvI4GKA3nE6tSdz/ZXYHmY4gCGWR6GTGdqCQEw9xQHSPaop MY35FDmBssj0wB+GhTcH15aJ/ipyeFmx9EtOy3GRbChYuEn/uFy4CLRIMOTS0JTbQTkc jT0WX0+l9F4XrmXcwrh3WHVT1A5qrlgE9jSQbI3nXtoQZQhrBO4qIqth9njddok/MMv9 B5+r8LtVEpsXaTifltjH1fhaxZHp1714Ey8pHzE7mJvN1EHiEByfc6SnAup6zdfVGVm0 JJUA==
X-Gm-Message-State: AHPjjUgC3y2RioH/4ya8iJYFrssjy6ExHPsddJYHA3r2C+J0bSZ+JOn+ eKiuZr+yxxQfLE8DkUKm5Lrw1VVV5ZZ5GVd6nvQ=
X-Google-Smtp-Source: AOwi7QAQVlFCBYmihjQGY/tkw/3hv240HttQXctAU6Fep1INV1rWhbs5P3R7opTR4Ovc4jLX/IEmDabn8ZeB36JCQ8w=
X-Received: by 10.107.130.224 with SMTP id m93mr27547367ioi.82.1505267676732; Tue, 12 Sep 2017 18:54:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.22.67 with HTTP; Tue, 12 Sep 2017 18:54:36 -0700 (PDT)
In-Reply-To: <CACfw2hjMLXYqXg+6ea1G0aPntX2UnM_ufMZFqNmn4GKVDvcu8w@mail.gmail.com>
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> <CAHw9_iLuAqRO=bQMyGeHmaeJZPdf2Q1BVaH3pg8NftJzpMSSSg@mail.gmail.com> <CACfw2hjMLXYqXg+6ea1G0aPntX2UnM_ufMZFqNmn4GKVDvcu8w@mail.gmail.com>
From: william manning <chinese.apricot@gmail.com>
Date: Tue, 12 Sep 2017 18:54:36 -0700
Message-ID: <CACfw2hi-nVDi0yai7H0G2zkFJwXbkZALdpQuXpHc60QyiiQtzA@mail.gmail.com>
To: dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="001a113eee7c29e55f055908711b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/iWYoMeuikFcSG_h-m_AMjReooEI>
Subject: [DNSOP] Fwd: 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 01:54:41 -0000

'cause warren isn't special enough to warrant getting the only copy of this.

/Wm
---------- Forwarded message ----------
From: william manning <chinese.apricot@gmail.com>
Date: Tue, Sep 12, 2017 at 6:53 PM
Subject: Re: [DNSOP] DNSSEC in local networks
To: Warren Kumari <warren@kumari.net>


cry me a river.  in the face of conflicting strings, tie-break by using the
closest enclosing trust anchor. See the "Islands of Trust" RFCs.  Slavish
dependence on a single trust anchor is among the dumber things you can do,
operationally.

/Wm

On Tue, Sep 12, 2017 at 5:03 PM, Warren Kumari <warren@kumari.net> wrote:

> On Mon, Sep 4, 2017 at 4:45 PM, Mark Andrews <marka@isc.org> wrote:
> >
> > In message <efe320cf9580d4c1bb2b26dd1c294306.1504529679@squirrel.mail>,
> "Walter
> >  H." writes:
> >> On Mon, September 4, 2017 14:22, Mark Andrews wrote:
> >> >
> >> > In message <c0c73dab49c6452c616c86656704ecd0.1504518603@squirrel.mail
> >,
> >> > "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-n
> ame-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 <+61%202%209871%204742>
>  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
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>