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

Nicholas Weaver <nweaver@ICSI.Berkeley.EDU> Mon, 07 May 2012 14:54 UTC

Return-Path: <nweaver@ICSI.Berkeley.EDU>
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 5572421F8613 for <dane@ietfa.amsl.com>; Mon, 7 May 2012 07:54:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.539
X-Spam-Level:
X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599]
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 76agEdJzTs7x for <dane@ietfa.amsl.com>; Mon, 7 May 2012 07:54:48 -0700 (PDT)
Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id C8EFD21F85FF for <dane@ietf.org>; Mon, 7 May 2012 07:54:48 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 7803B2C400B; Mon, 7 May 2012 07:54:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU
Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id jPlq9SldLuMJ; Mon, 7 May 2012 07:54:48 -0700 (PDT)
Received: from gala.icir.org (gala [192.150.187.49]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 269242C4004; Mon, 7 May 2012 07:54:48 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=us-ascii
From: Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>
In-Reply-To: <C8A32DF2-E912-4D53-B0E3-D79852632A3E@kumari.net>
Date: Mon, 7 May 2012 07:54:48 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <C8244A46-63BD-4903-B72C-6AB43413FB61@ICSI.Berkeley.EDU>
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> <alpine.LFD.2.02.1205041553030.7798@bofh.nohats.ca> <AD11709E-F662-492E-BE3B-23ADD82536F0@icsi.berkeley.edu> <C8A32DF2-E912-4D53-B0E3-D79852632A3E@kumari.net>
To: Warren Kumari <warren@kumari.net>
X-Mailer: Apple Mail (2.1257)
Cc: Paul Wouters <paul@nohats.ca>, 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: Mon, 07 May 2012 14:54:49 -0000

On May 7, 2012, at 7:46 AM, Warren Kumari wrote:
>>> How many months until Rogers (or OpenDNS, or...) starts spitting out AD=1
>>> on their DNS rewriting schemes?
>> 
>> Xerocole already says "Just do it"...
> 
> Win!

For those overall interested in the business of DNS NXDOMAIN and other modifications, the outsourced companies, the ISPs, the profitability claims ($1-3 per customer per year), etc, our paper from last year covers this space.  I think I posted a note to other DNS groups last year, but I don't think I posted it here:

http://www.icir.org/christian/publications/2011-foci-dns.pdf

"Redirecting DNS For Ads and Profit"


This is also why I am so cynical about recursive resolver validation, rather than end-host validation, and assert that the recursive resolver should be considered an adversary.