Re: [DNSOP] IVIPTR: New RR for DNS

Stephane Bortzmeyer <bortzmeyer@nic.fr> Mon, 27 November 2017 14:45 UTC

Return-Path: <bortzmeyer@nic.fr>
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 4A6B512895E for <dnsop@ietfa.amsl.com>; Mon, 27 Nov 2017 06:45:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no
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 kaMHNKUkqjRW for <dnsop@ietfa.amsl.com>; Mon, 27 Nov 2017 06:45:17 -0800 (PST)
Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (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 042E6126D85 for <dnsop@ietf.org>; Mon, 27 Nov 2017 06:45:17 -0800 (PST)
Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 89E10282186; Mon, 27 Nov 2017 15:45:15 +0100 (CET)
Received: by mx4.nic.fr (Postfix, from userid 500) id 843CF282194; Mon, 27 Nov 2017 15:45:15 +0100 (CET)
Received: from relay01.prive.nic.fr (unknown [10.1.50.11]) by mx4.nic.fr (Postfix) with ESMTP id 7D6DF282186; Mon, 27 Nov 2017 15:45:15 +0100 (CET)
Received: from b12.nic.fr (b12.tech.ipv6.nic.fr [IPv6:2001:67c:1348:7::86:133]) by relay01.prive.nic.fr (Postfix) with ESMTP id 7A968663E720; Mon, 27 Nov 2017 15:45:15 +0100 (CET)
Received: by b12.nic.fr (Postfix, from userid 1000) id 6E9C140034; Mon, 27 Nov 2017 15:45:15 +0100 (CET)
Date: Mon, 27 Nov 2017 15:45:15 +0100
From: Stephane Bortzmeyer <bortzmeyer@nic.fr>
To: Tariq Saraj <tariqsaraj@gmail.com>
Cc: dnsop@ietf.org
Message-ID: <20171127144515.4ol63kkaptnwmemn@nic.fr>
References: <CAAdbxrqKMHGaA+Z79MmfOV1f4+diL3W=EmQrxC1XXH7PND0iFg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAAdbxrqKMHGaA+Z79MmfOV1f4+diL3W=EmQrxC1XXH7PND0iFg@mail.gmail.com>
X-Operating-System: Debian GNU/Linux 9.2
X-Kernel: Linux 4.9.0-3-amd64 x86_64
X-Charlie: Je suis Charlie
Organization: NIC France
X-URL: http://www.nic.fr/
User-Agent: NeoMutt/20170113 (1.7.2)
X-Bogosity: No, tests=bogofilter, spamicity=0.000209, version=1.2.2
X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2017.11.27.143616
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/twdS3nnzs59siR3-UFxr__iuOOM>
Subject: Re: [DNSOP] IVIPTR: New RR for DNS
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, 27 Nov 2017 14:45:18 -0000

On Sat, Nov 25, 2017 at 10:41:13PM +0500,
 Tariq Saraj <tariqsaraj@gmail.com> wrote 
 a message of 60 lines which said:

> Please provide your valuable feedback on the newly uploaded draft.
> draft-tariq-dnsop-iviptr-00
> <https://datatracker.ietf.org/doc/draft-tariq-dnsop-iviptr/>
> *IVIPTR: Resource Record for DNS*

The only use case you describe (firewall configuration) is
questionable. Most firewall configuration interfaces allow you to use
domain names instead of IP addresses. So, if I want to allow port 443
to www.example.com (which has IPv4 and IP v6 addresses), I can. Note
that many firewall administrators don't use this because, rightly or
wrongly, they don't trust the DNS. They'll have the same issue with
your proposal.

By the way, that's why you _need_ to write something in the Security
Considerations, probably mentioning DNSSEC.

Otherwise, I'm not convinced by your argument against using PTR. If
people don't configure PTRs to get the effect you want, it may be because:

* they don't want to (so they don't need your proposal)
* they're lazy or incompetent (so they'll ignore your proposal)