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

Jelte Jansen <jelte@NLnetLabs.nl> Mon, 13 July 2009 08:48 UTC

Return-Path: <jelte@NLnetLabs.nl>
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 0098628C226 for <dnsop@core3.amsl.com>; Mon, 13 Jul 2009 01:48:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.55
X-Spam-Level:
X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.050, 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 Bunr9FKiTDc2 for <dnsop@core3.amsl.com>; Mon, 13 Jul 2009 01:48:34 -0700 (PDT)
Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by core3.amsl.com (Postfix) with ESMTP id D93C328C22F for <dnsop@ietf.org>; Mon, 13 Jul 2009 01:48:33 -0700 (PDT)
Received: from mirre.nlnetlabs.nl (mirre.nlnetlabs.nl [IPv6:2001:7b8:206:1:216:76ff:fecd:6a66]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.3/8.14.3) with ESMTP id n6D8mwwU019566 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Jul 2009 10:48:58 +0200 (CEST) (envelope-from jelte@NLnetLabs.nl)
Message-ID: <4A5AF445.1020801@NLnetLabs.nl>
Date: Mon, 13 Jul 2009 10:45:57 +0200
From: Jelte Jansen <jelte@NLnetLabs.nl>
User-Agent: Thunderbird 2.0.0.21 (X11/20090423)
MIME-Version: 1.0
To: Florian Weimer <fw@deneb.enyo.de>
References: <C67B83C4.E855%Jason_Livingood@cable.comcast.com> <87ws6enw09.fsf@mid.deneb.enyo.de> <74DA3552-160F-4912-B8B4-FAD506B4D4D1@eng.colt.net> <4A5AEA32.5010102@NLnetLabs.nl> <87tz1hyokg.fsf@mid.deneb.enyo.de>
In-Reply-To: <87tz1hyokg.fsf@mid.deneb.enyo.de>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Mon, 13 Jul 2009 10:48:58 +0200 (CEST)
Cc: dnsop@ietf.org, "Livingood, Jason" <Jason_Livingood@cable.comcast.com>
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: Mon, 13 Jul 2009 08:48:35 -0000

Florian Weimer wrote:
> * Jelte Jansen:
> 
>> Ralf Weber wrote:
>>>> No redirection on SERVFAIL seems to be a strange recommendation.
>>>> Wouldn't this be a very good reason to provide a diagnostics page,
>>>> especially if there's been a DNSSEC validation failure?
>>> This sounds like an excellent idea to help DNSSEC adoption and
>>> is something that should go into the draft.
>>>
>> then a SERVFAIL will also result in an e-mail bounce that says
>> connection refused
> 
> Not a hard 5xx error?
> 

not unless there's also a specific 5xx error generator listening on the host 
that is redirected to, i guess.

>> instead of DNS error (assuming there's no e-mail
>> sink on the host that is redirected to). Fun times for the helpdesk.
> 
> Only if the mail server falls back to the A record if the MX lookup
> results in SERVFAIL, which seems like a questionable approach to me.
> 

is it? (i'm asking, i don't know; even the updated smtp rfc seems a bit unclear 
about that)

> Anyway, I think DNS rewriting is mainly for folks who also block
> 25/TCP in- and outgoing or list the address space on the PBL and
> similar DNSBLs, so the SMTP argument is not really valid anymore.
> 

well in that case it might be worth adding a section that your own services 
should definitely not have the same resolvers that you have set up for your 
customers, and that a separate non-lying resolver should be set up for those.

But this is just an example of an unintended side effect from assuming that only 
web browsers ask for A/AAAA.

Jelte