Re: [dnsext] flip-flopping secure and unsecure DNAME/CNAME

Ben Laurie <ben@links.org> Mon, 13 October 2008 05:42 UTC

Return-Path: <owner-namedroppers@ops.ietf.org>
X-Original-To: ietfarch-dnsext-archive@core3.amsl.com
Delivered-To: ietfarch-dnsext-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F33883A6A27; Sun, 12 Oct 2008 22:42:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.437
X-Spam-Level:
X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1]
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 nHOg9rWh4lcB; Sun, 12 Oct 2008 22:42:19 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C58E63A69AC; Sun, 12 Oct 2008 22:42:18 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1KpG6A-000AUe-LP for namedroppers-data@psg.com; Mon, 13 Oct 2008 05:36:06 +0000
Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from <ben@links.org>) id 1KpG64-000AT0-2G for namedroppers@ops.ietf.org; Mon, 13 Oct 2008 05:36:04 +0000
Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 1635633C1E; Mon, 13 Oct 2008 06:37:21 +0100 (BST)
Message-ID: <48F2DE42.1060209@links.org>
Date: Mon, 13 Oct 2008 06:36:02 +0100
From: Ben Laurie <ben@links.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.4.0
MIME-Version: 1.0
To: Edward Lewis <Ed.Lewis@neustar.biz>
CC: Michael StJohns <mstjohns@comcast.net>, namedroppers@ops.ietf.org
Subject: Re: [dnsext] flip-flopping secure and unsecure DNAME/CNAME
References: <Your message of "Mon, 22 Sep 2008 15:12:44 -0400." <E1KhqqB-000CE1-QD@psg.com> <200809230016.m8N0GS9E069236@drugs.dv.isc.org> <E1Khwdp-000J3V-QJ@psg.com> <a06240804c4ffc42abc16@[10.122.105.108]> <E1KicTm-000ANO-PO@psg.com> <a06240800c50fd3decd5b@[192.168.1.101]>
In-Reply-To: <a06240800c50fd3decd5b@[192.168.1.101]>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
List-ID: <namedroppers.ops.ietf.org>

Edward Lewis wrote:
>> ps - anyone want to take a whack at documenting how various applications
>> should handle various DNSSEC outcomes?  The ones I can think of off
>> the top
>> of my head that should be done are: SMTP (both submitter to MTA and MTA
>> to MTA), HTTP (what the browser does *before* the user gets involved -
>> pretty sure just exposing the DNSSEC resolution state isn't the best
>> answer), SSH,  peer-to-peer.
> 
> DNSSEC was built ("repeat chorus") to stem cache poisoning, i.e.,
> protect the admission of DNS data to the cache.  It wasn't meant to
> protect the applications making use of the data.  If an application
> wants to act like a cache with a verifier, fine.  Then it asks for
> everything with CD, gets as much raw data, and does it's own check. If
> it can't reach the source (because of firewalls, forwarders, etc.,),
> well it's up a creek anyway.
> 
> To an application - either their is an answer in DNS or not.  The grey
> area is too hard to make use of, a general solution isn't useful.  It's
> like with lame delegation testing in the reverse map. There are a lot of
> screw ups there, a lot follow certain pathologies that, even common,
> make up a small percentage of the total problems. It isn't worth trying
> to diagnose for the few predictable misconfigurations.

Surely the point is that DNSSEC changes the possible answers from:

1. RR exists and here it is.
2. RR does not exist.
3. Server not reachable (or otherwise broken).

to

1. RR exists and here it is.
2. RR does not exist.
3. RR exists but is broken in some way.
4. Server not reachable (or otherwise broken).

The question is: what should applications do for state 3? My answer
would be to treat it like state 4, I think, but there's room for debate.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html           http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>