Re: [DNSOP] Review of draft-livingood-dns-redirect-00

Suzanne Woolf <woolf@isc.org> Tue, 14 July 2009 12:57 UTC

Return-Path: <woolf@isc.org>
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F88C3A699C for <dnsop@core3.amsl.com>; Tue, 14 Jul 2009 05:57:36 -0700 (PDT)
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=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bLhBW5oxy5Ng for <dnsop@core3.amsl.com>; Tue, 14 Jul 2009 05:57:35 -0700 (PDT)
Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) by core3.amsl.com (Postfix) with ESMTP id 604773A67C1 for <dnsop@ietf.org>; Tue, 14 Jul 2009 05:57:35 -0700 (PDT)
Received: by farside.isc.org (Postfix, from userid 10265) id 9DEC2E608C; Tue, 14 Jul 2009 12:58:03 +0000 (UTC)
Date: Tue, 14 Jul 2009 12:58:03 +0000
From: Suzanne Woolf <woolf@isc.org>
To: "Livingood, Jason" <Jason_Livingood@cable.comcast.com>
Message-ID: <20090714125803.GA18883@farside.isc.org>
References: <p062408b6c67ed70acc85@[10.20.30.158]> <C680B51E.EB21%Jason_Livingood@cable.comcast.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <C680B51E.EB21%Jason_Livingood@cable.comcast.com>
User-Agent: Mutt/1.4.2.3i
X-Mailman-Approved-At: Tue, 14 Jul 2009 07:51:56 -0700
Cc: dnsop@ietf.org, Paul Hoffman <paul.hoffman@vpnc.org>
Subject: Re: [DNSOP] Review of draft-livingood-dns-redirect-00
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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: Tue, 14 Jul 2009 12:57:36 -0000

On Mon, Jul 13, 2009 at 09:55:42AM -0400, Livingood, Jason wrote:
> On the topic of "lying resolvers" though, that seems a bit strong IMHO.  But
> perhaps I have missed a strong MUST statement (per RFC 2119) in a relevant
> RFC that you could refer me to?

It's always seemed to me that it was implicit in the DNS model that
properly delegated authoritative servers determine what's "true" about
a given portion of the namespace. That's why they're "authoritative".
Recursive resolvers ask for data, and they use data they got from
authoritative servers to answer queries. They don't generate data from
whole cloth.

In contexts where I'm a domain owner, or responsible for the correct
propagation of zone data from authoritative servers, I'm not going to
be happy about intermediate resolvers rewriting my data on the fly. It
renders the whole concept of the hierarchical namespace, with
delegations of authority over various pieces of it, pretty much
meaningless.

"DNS redirect" is a fundamental violation of the assumptions behind
the protocol....a philosophical violation, if you will. This means
that it's esthetically unpleasant to a lot of people, but more to the
point, that it's impossible to do cleanly.

It's understood that service providers live in a world where such
philosophical violations occur regularly, for all kinds of
reasons. But you can't make people like it, particularly not by trying
to dress it up. In this case, we're talking about resolvers replacing
authoritative server data with their own. If you believe the model of
DNS that I asserted above, "lying" is a defensible description.

To the draft specifically: the goal behind it is laudable, and a lot
of the complaints about it are in the nature of shooting the
messenger.  I'm one of the people who shares the belief that there's
no "Best" in this space to justify the "BCP" tag, but an informational
document will be useful. I look forward to the -01 and the discussion
in Stockholm.


Suzanne