[DNSOP] how DNS redirect works with empty response

JINMEI Tatuya / 神明達哉 <jinmei@isc.org> Mon, 27 July 2009 21:25 UTC

Return-Path: <jinmei@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 1A7D23A6CEC for <dnsop@core3.amsl.com>; Mon, 27 Jul 2009 14:25:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.601
X-Spam-Level:
X-Spam-Status: No, score=0.601 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2]
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 HlIhEAMmsP2w for <dnsop@core3.amsl.com>; Mon, 27 Jul 2009 14:25:36 -0700 (PDT)
Received: from mon.jinmei.org (mon.jinmei.org [IPv6:2001:4f8:3:36::162]) by core3.amsl.com (Postfix) with ESMTP id 15B213A68DC for <dnsop@ietf.org>; Mon, 27 Jul 2009 14:25:36 -0700 (PDT)
Received: from jmb.jinmei.org (unknown [212.112.167.85]) by mon.jinmei.org (Postfix) with ESMTPA id D69C133C37; Mon, 27 Jul 2009 14:25:34 -0700 (PDT)
Date: Mon, 27 Jul 2009 23:25:32 +0200
Message-ID: <m2tz0x24z7.wl%jinmei@isc.org>
From: JINMEI Tatuya / 神明達哉 <jinmei@isc.org>
To: jason_livingood@cable.comcast.com
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.1 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset="US-ASCII"
Cc: dnsop@ietf.org
Subject: [DNSOP] how DNS redirect works with empty response
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, 27 Jul 2009 21:25:37 -0000

[resending it after resolving the mismatched sender address...]

(apologize if this point was already discussed in the thread.  I've
read all relevant threads but due to their volume I may miss
something).

I have one quick question about what the DNS redirect service
does/would/should with an empty response in terms of "Web Error
Redirect".

Suppose that a zone "example.com" has a wildcard RR at the apex, a
common practice for catch-all MX configuration:

*.example.com.	IN	MX	  10	mx.example.com.

also assume this zone doesn't have wwww.example.com (four 'w's).

If a user specifies this non-existent name, intending to mean
www.example.com, and the stub resolver queries for A and/or AAAA RRs
of that name, the authoritative server will return a no error, empty
response.  This is a variant of "web error' situation, but it doesn't
result in an NXDOMAIN.

What does a recursive server that implements the DNS redirect service
do in this case?  Does it return the original empty response intact?
Or does it "redirect" such responses too?  If it's the latter, what if
only one of A and AAAA answers is empty (which is actually today's
common situation)?

If it currently returns the original empty response, and our consensus
is it should keep this behavior in the future (even with those who are
for NXDOMAIN redirect), then I guess authoritative server implementors
who don't like NXDOMAIN redirect could introduce a "auto-site-finder"
option, defaulting to yes, which automatically adds a wildcard name
(of some meaningless RR type) at the apex of each authoritative
zone:-)

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.

p.s. I also have one very minor nit, which is irrelevant to the
subject of this message, but I think it's too minor to raise in a
separate message...so here it goes:

The draft uses the term "NXDOMAIN", seemingly intentionally.  But if
you eventually want to publish it as an RFC, you may want to know that
when I co-authored RFC4074 one of IESG's DISCUSS comment was "don't
use NXDOMAIN":
https://datatracker.ietf.org/idtracker/draft-ietf-dnsop-misbehavior-against-aaaa/comment/21536/

If the IESG is consistent about their DISCUSS criteria (which I
actually doubt), you may face the same challenge.  So, unless there's
a strong reason for keeping this term, it would be safer to rephrase
it to "name error".