IETF Logo Mail Archive

Re: [DNSOP] review: draft-wessels-dns-zone-digest-04.txt

Richard Gibson <richard.j.gibson@oracle.com> Thu, 01 November 2018 13:08 UTC

Return-Path: <richard.j.gibson@oracle.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 9134F1286E7 for <dnsop@ietfa.amsl.com>; Thu, 1 Nov 2018 06:08:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.77
X-Spam-Level:
X-Spam-Status: No, score=-4.77 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.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 HUx1qJQ7xYEg for <dnsop@ietfa.amsl.com>; Thu, 1 Nov 2018 06:08:15 -0700 (PDT)
Received: from userp2130.oracle.com (userp2130.oracle.com [156.151.31.86]) (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 A11EE126DBF for <dnsop@ietf.org>; Thu, 1 Nov 2018 06:08:15 -0700 (PDT)
Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id wA1CwTvv005952; Thu, 1 Nov 2018 13:08:13 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type; s=corp-2018-07-02; bh=Jb83k9ALMzyPz4CVvqzi5Gzvz7YWCp8wA9jLOiTLs5U=; b=HLmG65//mAUOUYquZBkfXIEOCmZfbXk+x45GgUtLvzGWcE+YC6QUYn3/AoA1b0Y7DlfD U/UD5Bi27vS5NFIJMrGbPyQIT4yMRmeXEmBXxxHQ+aHONbcdSSeHb8/nYiB/t+TwVAvK F9muXgvkeUu1RWzROjytkg3rqIBUSnW03RBh6grRbgKHo3eGw1D3mw3TG4XdjyG+lm/G 38zG7jBB5warzpgkF+jku1uw6bxo5wAMLpPFcaVyFocwOWPjR2ma9eXljZ/KN7T6PK7y m0QKbeyxniK61xCDcrVCXTr8KJr+qSlO4hgiSEh7EgotbyD9bRkCp9Iu795B9asg5DKI LA==
Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp2130.oracle.com with ESMTP id 2nducmddt7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 01 Nov 2018 13:08:13 +0000
Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id wA1D8BhQ020935 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 1 Nov 2018 13:08:12 GMT
Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id wA1D8BXr020396; Thu, 1 Nov 2018 13:08:11 GMT
Received: from [172.16.30.225] (/216.146.45.247) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 01 Nov 2018 06:08:11 -0700
To: Joe Abley <jabley@hopcount.ca>, Wessels Duane <dwessels@verisign.com>
Cc: dnsop <dnsop@ietf.org>
References: <154020795105.15126.7681204022160033203@ietfa.amsl.com> <DD4AADA8-A23A-4C2C-9F0D-401CA5A51745@hopcount.ca> <509F5E08-5EDF-4A54-BB34-A76BA390F01D@verisign.com> <46FB2005-A7EF-42AD-9D78-5D121D26CB45@hopcount.ca>
From: Richard Gibson <richard.j.gibson@oracle.com>
Message-ID: <f82d7bc4-6c2c-9011-d4cd-5144977025a2@oracle.com>
Date: Thu, 01 Nov 2018 09:08:09 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <46FB2005-A7EF-42AD-9D78-5D121D26CB45@hopcount.ca>
Content-Type: multipart/alternative; boundary="------------3C0DAC7DBED90097370C9832"
Content-Language: en-US
X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9063 signatures=668683
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=811 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1811010116
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/LvzOEfH0S1QGnbkeCJQoqTmGb0E>
Subject: Re: [DNSOP] review: draft-wessels-dns-zone-digest-04.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 01 Nov 2018 13:08:18 -0000

On 10/31/18 19:50, Joe Abley wrote:
>> It sounds wrong to me to say that identical instances of RRs would not be allowed in a zone.
> It's true though, right? It's not meaningful to include more than one resource record with the same (owner,type, class, TTL, RDATA) in the same RRSet, and hence also not meaningful to include such duplicates in a single zone (which is a particular set of RRSets). I don't think RFC 1034 is explicit about this, but it's surely implied. I don't know of any nameserver software that would allow duplicates like that, though, with the possible exception of the SOA. Quite possibly I have just typed more nonsense about this than the world ever needed to see.

RFC 2181 section 5: "It is meaningless for two records to ever have 
label, class, type and data all equal - servers should suppress such 
duplicates if encountered."

And RFC 7719 section 4 affirms the "different data" requirement.

v2.23.0 | Report a Bug | By Email