Re: [DNSOP] DNSSEC in local networks

Petr Špaček <petr.spacek@nic.cz> Mon, 04 September 2017 12:57 UTC

Return-Path: <petr.spacek@nic.cz>
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 65FB1132960 for <dnsop@ietfa.amsl.com>; Mon, 4 Sep 2017 05:57:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7
X-Spam-Level:
X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 NZkdsXqQwkaB for <dnsop@ietfa.amsl.com>; Mon, 4 Sep 2017 05:57:00 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8092713217D for <dnsop@ietf.org>; Mon, 4 Sep 2017 05:57:00 -0700 (PDT)
Received: from [IPv6:2001:1488:fffe:6:dc5d:d8ff:fe1c:f6e3] (unknown [IPv6:2001:1488:fffe:6:dc5d:d8ff:fe1c:f6e3]) by mail.nic.cz (Postfix) with ESMTPSA id DA0CD617DF for <dnsop@ietf.org>; Mon, 4 Sep 2017 14:56:58 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1504529818; bh=QsmE3nkXS4tX1jbf4g0D222vRC+wi3Fvy3NfTEQg4w0=; h=To:From:Date; b=wJDQpa4pKWelU/7JGL9OUZIUYkoUF3kT3Qxotdzkz+DitxFbrdsvDaGHDn1gP75XM Q7LcsiGhDanjJlT1f9tf5+plywWqUDXuGWPOsrEQbDFAJsaSefIUMexyX9arGyZxEN mDM/z2WCRwqPXx5noT6eU9EsINHZ35wuxNv1vNuI=
To: dnsop@ietf.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>
From: Petr Špaček <petr.spacek@nic.cz>
Organization: CZ.NIC
Message-ID: <3ab6b4f3-e963-79e4-5f55-c87d450b23fd@nic.cz>
Date: Mon, 04 Sep 2017 14:56:58 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <c0c73dab49c6452c616c86656704ecd0.1504518603@squirrel.mail>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/75TDtyrWPDtLpgTEwqo3VIbaT2g>
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: Mon, 04 Sep 2017 12:57:03 -0000

On 4.9.2017 11:50, Walter H. wrote:
>> Except you misses the entire point of getting a registered name,
>> that is to be able to use it safely without anyone trampling on its
>> use.
> 
> where there anyone who said: "don't use it", 15 years ago?
> 
>> '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", ...

I would like to comment on
'vendor told us and we followed his instructions'.
Maybe it is time to follow the new docs, e.g.:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/ch-Configure_Host_Names.html#sec-Recommended_Naming_Practices

Software and its docs have bugs which get fixed over time and there is
not way around it. Configuration has to follow the suit.


Please keep in mind that reserving a new name will not magically solve
the issue.

1. Existing systems will stay broken *unless* the reservation is for the
same string as used by particular network. Certainly this will not be
the case for all the broken installations.

In other words, some networks will stay non-complaint whatever dnsop
will do, which means that the broken networks will either get fixed over
time or stay broken. I do not see dnsop having real influence over this
aspect of network operation, sorry.


2. Also, reserving a random string does not solve problem of VPNs
between companies (customer using VPN to supplier's network, for
example), company mergers, etc.

If we reserved string 'example.', how it helped to solve the problem
when your company X needs to establish VPN tunnel to company Y internal
network to access its systems? How does it help if company X merges with
company Y?

Really, unique strings are the way to go.

Petr Špaček  @  CZ.NIC


> 
>> Yes, 'home.arpa' will be registered.  It's a different type of
>> registration to the one that is normally done by talking to your
>> friendly DNS registrar but it is a registration.
> 
> exact such a name but a TLD is needed for companies/enterprises in order
> to prevent new ones doing the mistakes of old ones ..., and having the
> safety not having a conflict in the future ...
> 
>> Names are not addresses.  They have different properties.
> 
> that is not the point,
> the point is, that in those days where these companies decided to use
> .local, .corp, ... such a paper prevented these decisions and now it could
> have been expanded with DNSSEC features ...
> 
> just guess what would have happened when there was no RFC1918; by the way,
> I would not have any problem changing my internal IPv4 addresses from e.g.
> 10.x.x.x to let's say 52.x.x.x - it is only a thought;
> 
> companies that use .local as their internal domain name and/or Active
> Directory have no problem as long as there is no system that insists on
> using mDNS for .local as specified in RFC6762