[DNSOP] DNS updates and classless in-addr.arpa delegation/CNAMEs

Petr Spacek <pspacek@redhat.com> Wed, 03 June 2015 06:53 UTC

Return-Path: <pspacek@redhat.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B77001B35DC for <dnsop@ietfa.amsl.com>; Tue, 2 Jun 2015 23:53:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level:
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 cq9_xqmgZohJ for <dnsop@ietfa.amsl.com>; Tue, 2 Jun 2015 23:53:46 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 826091B35CD for <dnsop@ietf.org>; Tue, 2 Jun 2015 23:53:46 -0700 (PDT)
Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 4AA34BACC7 for <dnsop@ietf.org>; Wed, 3 Jun 2015 06:53:46 +0000 (UTC)
Received: from pspacek.brq.redhat.com (unused [10.34.128.7] (may be forged)) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t536riH8004334 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <dnsop@ietf.org>; Wed, 3 Jun 2015 02:53:45 -0400
Message-ID: <556EA478.80105@redhat.com>
Date: Wed, 03 Jun 2015 08:53:44 +0200
From: Petr Spacek <pspacek@redhat.com>
Organization: Red Hat
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: dnsop@ietf.org
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/8TFJ4BllefQ_Vxcd1g7_Ehg_lj4>
Subject: [DNSOP] DNS updates and classless in-addr.arpa delegation/CNAMEs
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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, 03 Jun 2015 06:53:47 -0000

Hello,

I would like early feedback about following idea about interaction between DNS
updates (RFC 2136) and classless IN-ADDR.ARPA delegation (RFC 2317).

In short, the RFC 2317 tells me to fill reverse zone with CNAMEs pointing to
(potentially) some other zone.

At the same time, an attempt to add a PTR record to a node already containing
CNAME will fail, possibly without reporting an error to the requester. AFAIK
BIND 9.9 just prints an error to log but returns NOERROR to the client.

As a result, RFC 2317 breaks dynamic updates for classless reverse zones.


I'm going to sketch -00 draft which will attempt to address this by
client-side canonization:

The client should attempt to resolve whole chain of CNAME/DNAMEs from
1.2.0.192.in-addr.arpa down to terminal node and update the terminal node
instead of the original name.

Most interesting part of the text will be 'Security Considerations'
(considering signed updates).

I would welcome early feedback about the idea even before the -00 is published.

Thank you very much!

-- 
Petr Spacek  @  Red Hat