IETF Logo Mail Archive

Re: [DNSOP] [Ext] Re: Comments on draft-wessels-dns-zone-digest-02

Edward Lewis <edward.lewis@icann.org> Mon, 13 August 2018 17:50 UTC

Return-Path: <edward.lewis@icann.org>
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 0167D124BE5 for <dnsop@ietfa.amsl.com>; Mon, 13 Aug 2018 10:50:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 RwHHH7XrmAe3 for <dnsop@ietfa.amsl.com>; Mon, 13 Aug 2018 10:50:03 -0700 (PDT)
Received: from out.west.pexch112.icann.org (out.west.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 589C712F295 for <dnsop@ietf.org>; Mon, 13 Aug 2018 10:50:03 -0700 (PDT)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Mon, 13 Aug 2018 10:50:01 -0700
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1367.000; Mon, 13 Aug 2018 10:50:01 -0700
From: Edward Lewis <edward.lewis@icann.org>
To: John R Levine <johnl@taugh.com>
CC: "dnsop@ietf.org" <dnsop@ietf.org>
Thread-Topic: [DNSOP] [Ext] Re: Comments on draft-wessels-dns-zone-digest-02
Thread-Index: AQHUMx1RgcQejTWkS0KFdY3XnrmfnqS+IT4AgABF9gD//8D4AA==
Date: Mon, 13 Aug 2018 17:50:00 +0000
Message-ID: <744AD583-1F3A-455B-B0BB-6DF9A42CC90A@icann.org>
References: <7223EEB4-57A4-4C54-8C62-631B5FBEE0A5@icann.org> <20180813154946.A0D5020036E99E@ary.qy> <55C39266-40BA-4266-B631-28050CCE8242@icann.org> <alpine.OSX.2.21.1808131330440.95713@ary.qy>
In-Reply-To: <alpine.OSX.2.21.1808131330440.95713@ary.qy>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.d.0.180513
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.0.47.234]
Content-Type: text/plain; charset="utf-8"
Content-ID: <D96D73A1E7F0434A85311D7052F3F402@pexch112.icann.org>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/UDYuZouZjlEhpDhyE3EOM7fKiic>
Subject: Re: [DNSOP] [Ext] Re: Comments on draft-wessels-dns-zone-digest-02
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: Mon, 13 Aug 2018 17:50:06 -0000

On 8/13/18, 13:35, "John R Levine" <johnl@taugh.com> wrote:

    
>Hey, I have a great idea.  We could make sure that the zone file received matches the zone file sent by including a hash of the zonee in a record in the zone.  Whaddaya think?

In some sense, it's re-inventing the wheel.
    
>I realize you could refetch all the glue and check it but that's a lot more work.

Some code already does that, in the sense that the glue may be needed for other queries.

If not, what happens if bad glue (meaning the address is not in use by the intended server) is included?  Either no response, lame server response, or a response with false data.  The first two are denials of service but the querier ought to (as in not guaranteed to) be able to find another source.  The latter may be a mistake (neglected decommissioning of a zone when service is transferred) or malicious (the user case usually in mind).  For the latter to "disrupt" the data would have to be correctly signed to get past DNSSEC validation.

What this keeps coming back to is - is this new invention giving us anything that DNSSEC doesn't already give us?  As in, if it seems that DNSSEC is needed to validate it, why not just validate the data we are after?

v2.23.0 | Report a Bug | By Email