IETF Logo Mail Archive

Re: [DNSOP] howto "internal"

Grant Taylor <gtaylor@tnetconsulting.net> Wed, 25 July 2018 19:14 UTC

Return-Path: <gtaylor@tnetconsulting.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 0168E130E3F for <dnsop@ietfa.amsl.com>; Wed, 25 Jul 2018 12:14:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tnetconsulting.net
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 gqF8fTzcjPQh for <dnsop@ietfa.amsl.com>; Wed, 25 Jul 2018 12:14:47 -0700 (PDT)
Received: from tncsrv06.tnetconsulting.net (tncsrv06.tnetconsulting.net [IPv6:2600:3c00::f03c:91ff:fe26:8849]) (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 143FE129385 for <dnsop@ietf.org>; Wed, 25 Jul 2018 12:14:47 -0700 (PDT)
Received: from REDACTED (hal9000.thn.corp.google.com [IPv6:2620:0:102a:11:fe50:e322:5780:92c6]) (authenticated bits=0) by tncsrv06.tnetconsulting.net (8.15.2/8.15.2/Debian-3) with ESMTPSA id w6PJEj5b006477 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for <dnsop@ietf.org>; Wed, 25 Jul 2018 14:14:46 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=tnetconsulting.net; s=2015; t=1532546086; bh=1ScZYeYR8FbDU1GmtziIKVh/pNnmqMJZeD7fHjJ3rN0=; h=Subject:To:References:From:Message-ID:Date:User-Agent: MIME-Version:In-Reply-To:Content-Type:Cc:Content-Disposition: Content-Language:Content-Transfer-Encoding:Content-Type:Date:From: In-Reply-To:Message-ID:MIME-Version:References:Reply-To: Resent-Date:Resent-From:Resent-To:Resent-Cc:Sender:Subject:To: User-Agent; b=6jEIpnUl/1uoHxakO7mkwvFPi9MfB3eB/R5dVMI/V9UGkIZ3aLtdlhBi162G8SvaB UkDc9E09cUxTL0JFpcmYwSo2IFQm3gTet14LBYPHeqwvREVgBLfdR7ysE/jCfdvO5L lMpFKa1c4pX6iU3Pjlxfs1LO1A5OudK5kGHGkEmU=
To: dnsop@ietf.org
References: <1cb82914-0bc3-9ea7-7f69-9dc826d19e48@andreasschulze.de> <2264d840-33cc-736c-668a-a537c4da4a30@nic.cz> <alpine.DEB.2.20.1807241623300.5965@grey.csi.cam.ac.uk> <CADyWQ+HZ4i2P9qK03xK_EvZYakdduKigH87QgZ4zfUwjHjL25Q@mail.gmail.com> <5B574F67.1090806@redbarn.org> <993209cf-01b5-c6c2-cc64-74b42c398e26@spamtrap.tnetconsulting.net> <alpine.DEB.2.20.1807251209520.3596@grey.csi.cam.ac.uk>
From: Grant Taylor <gtaylor@tnetconsulting.net>
Organization: TNet Consulting
Message-ID: <5ee9c290-39c0-83d7-e182-9a34d139583a@spamtrap.tnetconsulting.net>
Date: Wed, 25 Jul 2018 13:14:45 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.20.1807251209520.3596@grey.csi.cam.ac.uk>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms080106090607040203040306"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/iJklmKhwydOzqqB1mH6QbOPzYko>
Subject: Re: [DNSOP] howto "internal"
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.27
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, 25 Jul 2018 19:14:50 -0000

On 07/25/2018 05:18 AM, Tony Finch wrote:
> I recommend having an empty public view of your private zone, so that 
> external queries succeed with NXDOMAIN / NODATA.

ACK.

What is your opinion on blindly grafting the sub-domain onto the parent 
zone without proper delegation.  I.e. internal DNS server hosts 
internal.example.net and external DNS server returns NXDOMAIN for 
internal.example.net.

I have my doubts about this sort of scheme supporting DNSSEC.  -  I 
think it would be better to have a mostly empty zone that is properly 
delegated that re-use the same DNSSEC keys.

I might even go so far as to have the external server be a slave for a 
specific empty view transferred from the internal server.  That way the 
keys stay internal.

> Returning REFUSED for a private zone causes retries, and not responding 
> at all causes even worse problems such as EDNS fallback attempts.

ACK

> I haven't tried delegating to RFC1918 addresses, but that is likely to 
> cause similar weirdness.

As I type this I wonder about delegating to RFC 1918 address via names 
in an NS record that are within delegated zone.  Thus they would require 
glue records.  Externally I'd omit the glue records.  Internally I'd 
have the records within zone scope along with all the other zone data.

I suspect that this may cause odd retry issues too.

It may leak some information, but I do think that the hard NXDOMAIN / 
NODATA is likely cleanest for the DNS protocol.



-- 
Grant. . . .
unix || die

v2.14.0 | Report a Bug | By Email