Re: [dane] Behavior in the face of no answer?

Paul Wouters <paul@nohats.ca> Fri, 04 May 2012 20:03 UTC

Return-Path: <paul@nohats.ca>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D91F621E8039 for <dane@ietfa.amsl.com>; Fri, 4 May 2012 13:03:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.528
X-Spam-Level:
X-Spam-Status: No, score=-0.528 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HOST_MISMATCH_COM=0.311, RDNS_DYNAMIC=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EuWVWkdeUGzQ for <dane@ietfa.amsl.com>; Fri, 4 May 2012 13:03:56 -0700 (PDT)
Received: from letoams.cypherpunks.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) by ietfa.amsl.com (Postfix) with ESMTP id 5D35D21E8012 for <dane@ietf.org>; Fri, 4 May 2012 13:03:55 -0700 (PDT)
Received: by letoams.cypherpunks.ca (Postfix, from userid 500) id E9A1D855F9; Fri, 4 May 2012 16:03:54 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1]) by letoams.cypherpunks.ca (Postfix) with ESMTP id DA8B5855F8; Fri, 4 May 2012 16:03:54 -0400 (EDT)
Date: Fri, 4 May 2012 16:03:54 -0400 (EDT)
From: Paul Wouters <paul@nohats.ca>
To: Andrew Sullivan <ajs@anvilwalrusden.com>
In-Reply-To: <20120504194132.GF7394@mail.yitter.info>
Message-ID: <alpine.LFD.2.02.1205041553030.7798@bofh.nohats.ca>
References: <20120504021044.GB4560@mail.yitter.info> <B25C977F-6B4E-458C-879D-A36EDB94DA75@icsi.berkeley.edu> <20120504023602.GA4683@mail.yitter.info> <CABcZeBO93n_C5detefBcOjAoswe2inGKDj65gQPDQmREyGnhAw@mail.gmail.com> <20120504112922.GB4929@mail.yitter.info> <CABcZeBPTTa07iUHo9XL5WrHGMYHwaQzs6xYtiF25O4Jek8E3RQ@mail.gmail.com> <20120504144426.GD4929@mail.yitter.info> <CABcZeBOM_0L42Rng75AsVda9u4G=FH8=OB8Qg=nQpL-BzRoBuQ@mail.gmail.com> <20120504165512.GC7394@mail.yitter.info> <CABcZeBO4zRSa=JexqZ8uw7o26tM4SZk2GDivTAWD5ZF1pZR9Og@mail.gmail.com> <20120504194132.GF7394@mail.yitter.info>
User-Agent: Alpine 2.02 (LFD 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: dane@ietf.org
Subject: Re: [dane] Behavior in the face of no answer?
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:dane-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:dane@ietf.org>
List-Help: <mailto:dane-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:dane-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 May 2012 20:03:57 -0000

On Fri, 4 May 2012, Andrew Sullivan wrote:

> I believe it is possible to get a useful response that has nothing in
> the Answer, Authority, and Additional sections only if you trust your
> upstream, you trust the connection somehow, you set CD=0, and you get
> AD=1 on the response.  In that case, I believe it is a legitimate
> NODATA response (though I don't know of any implementation that works
> this way), and it is validated.

How many months until Rogers (or OpenDNS, or...) starts spitting out AD=1
on their DNS rewriting schemes?

>From RFC3655:

    The AD bit SHOULD be used by the local resolver if and only if it has
    been explicitly configured to trust the remote resolver.  The AD bit
    SHOULD be ignored when the recursive name server is not trusted.

So your scenario really only happens when you bring up a VPN and connect
back to a trusted network. At that point, you can trust the AD bit, but
you also no longer have DNS breakage/filtering happening, so the point
is moot.

The other scenario is an application talking to the local resolver that
returns the AD bit, which just moves the DNS connectivity problem from the
application to the local resolver, but runs into the same hard/soft
fail issue, except the browser knows even less about the reasons for
the failure or success, and can give less feedback to the user to make
an educated guess as to the severity of the failure to be hard or soft.

Regardless, all of this is not DANE specific, and IMHO does not belong
in the DANE document.

Paul