IETF Logo Mail Archive

Re: [dnsext] Authenticated denial of existence...

Miek Gieben <miek@miek.nl> Wed, 20 November 2013 07:54 UTC

Return-Path: <miek@miek.nl>
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 571881AC4AC for <dnsext@ietfa.amsl.com>; Tue, 19 Nov 2013 23:54:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 s_xtsZAn3Pjj for <dnsext@ietfa.amsl.com>; Tue, 19 Nov 2013 23:54:11 -0800 (PST)
Received: from mail-we0-f173.google.com (mail-we0-f173.google.com [74.125.82.173]) by ietfa.amsl.com (Postfix) with ESMTP id 53D731AE381 for <dnsext@ietf.org>; Tue, 19 Nov 2013 23:54:10 -0800 (PST)
Received: by mail-we0-f173.google.com with SMTP id t61so2159094wes.32 for <dnsext@ietf.org>; Tue, 19 Nov 2013 23:54:04 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=DoTgLj180NyXqNRXgtdmDmU2ZOwecMpJioaSm5nwz74=; b=kQjWYpdc6wEqqRRm1jKSvcsHCWN0h56WvFeUH8t8NnGQ4M3MOfPHE4gcXWMazvBZG9 lPojrp3OYAKRHBJMwXQ4LEGhDuXJkrMzctg+2djgAH5Knq30AXgHlFIQIhxSAH1Jb0bF YL20Ck/MKi5vJ0IEKgSJscfRkdkrEHMQwEJzBCsqRb0CGLlX6c8YcLjuj/JWpicPUQcJ x5AqpW3eofmhstdtFcVwRQcjjsWw2cPrr2pmvTMVrRr6uSotHQF/65WePWgvEWOXp71p XMD6TttrZqnEk4WmmDdFzTppxBX1fYhJ20ibCMQYNYnZKvIsN6bNbZqQ0bkeMja1jF/+ +PZQ==
X-Gm-Message-State: ALoCoQknQL32ZcaLSSMfQ9KS0YoOfhTnHOqi7mD3yLScVPrQYmeBSGBEQwsGDvCQijDxIP8jKlUT
X-Received: by 10.180.14.226 with SMTP id s2mr4155wic.41.1384934044029; Tue, 19 Nov 2013 23:54:04 -0800 (PST)
Received: from miek.nl (host86-145-158-57.range86-145.btcentralplus.com. [86.145.158.57]) by mx.google.com with ESMTPSA id qc10sm42362859wic.9.2013.11.19.23.54.02 for <multiple recipients> (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 19 Nov 2013 23:54:03 -0800 (PST)
Date: Wed, 20 Nov 2013 07:53:59 +0000
From: Miek Gieben <miek@miek.nl>
To: Jiankang Yao <yaojk@cnnic.cn>
Message-ID: <20131120075359.GA23121@miek.nl>
Mail-Followup-To: Jiankang Yao <yaojk@cnnic.cn>, Ted Lemon <ted.lemon@nominum.com>, "dnsext@ietf.org Group" <dnsext@ietf.org>
References: <CFD6B510-D70E-4308-BF3E-B2E7C2ADCBEB@nominum.com> <201311201459364160303@cnnic.cn>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <201311201459364160303@cnnic.cn>
User-Agent: Vim/Mutt/Linux
X-Home: http://www.miek.nl
Cc: Ted Lemon <ted.lemon@nominum.com>, "dnsext@ietf.org Group" <dnsext@ietf.org>
Subject: Re: [dnsext] Authenticated denial of existence...
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext/>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Nov 2013 07:54:13 -0000

[ Quoting <yaojk@cnnic.cn> in "Re: [dnsext] Authenticated denial o..." ]
> 
> good writing of this draft.
> 
> I am interested the following text in section 3:
> "   2.  The DNS packet header is not signed.  This means that a "status:
>        NXDOMAIN" can not be trusted.  In fact the entire header may be
>        forged, including the AD bit (AD stands for Authentic Data, see
>        RFC 3655 [RFC3655]), which may give some food for thought;
> "
> so if the resolver is attacked, such as hacking the "status" field or the whole header, what will happen?

A good resolver should check the complete message and then header so see if they
match. Of course this only works if the message contains signatures. 

Should we add something along these lines to the draft. Currently it is an
"exercise for the reader", which I kinda like.

Regards,
Miek

v2.39.1 | Report a Bug | By Email | System Status