IETF Logo Mail Archive

Re: [dnsext] CNAME and NXDOMAIN

"W.C.A. Wijngaards" <wouter@nlnetlabs.nl> Wed, 26 May 2010 07:28 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 EAAAC3A67AF; Wed, 26 May 2010 00:28:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.85
X-Spam-Level: **
X-Spam-Status: No, score=2.85 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_NL=0.55, HELO_MISMATCH_NL=1.448, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_LOW=-1, 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 dBa2fZ9vrfu3; Wed, 26 May 2010 00:28:21 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 038BE3A66B4; Wed, 26 May 2010 00:28:21 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1OHAyw-000MEK-00 for namedroppers-data0@psg.com; Wed, 26 May 2010 07:24:50 +0000
Received: from [85.17.178.138] (helo=rotring.dds.nl) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <wouter@nlnetlabs.nl>) id 1OHAys-000MDh-AR for namedroppers@ops.ietf.org; Wed, 26 May 2010 07:24:46 +0000
Received: from localhost (localhost [127.0.0.1]) by rotring.dds.nl (Postfix) with ESMTP id 18111583CA; Wed, 26 May 2010 09:24:45 +0200 (CEST)
Received: from [192.168.254.1] (195-241-9-117.adsl.dds.nl [195.241.9.117]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rotring.dds.nl (Postfix) with ESMTP id DB08858155; Wed, 26 May 2010 09:24:26 +0200 (CEST)
Message-ID: <4BFCCCAA.5000102@nlnetlabs.nl>
Date: Wed, 26 May 2010 09:24:26 +0200
From: "W.C.A. Wijngaards" <wouter@nlnetlabs.nl>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100430 Fedora/3.0.4-2.fc11 Thunderbird/3.0.4
MIME-Version: 1.0
To: Paul Vixie <vixie@isc.org>
CC: namedroppers@ops.ietf.org
Subject: Re: [dnsext] CNAME and NXDOMAIN
References: <a06240801c82233ee8b67@[10.31.200.147]> <55156.1274856474@nsa.vix.com>
In-Reply-To: <55156.1274856474@nsa.vix.com>
X-Enigmail-Version: 1.0.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.95.3 at rotring
X-Virus-Status: Clean
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
List-ID: <namedroppers.ops.ietf.org>
List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with
List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body.
List-Archive: <http://ops.ietf.org/lists/namedroppers/>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Paul,

On 05/26/2010 08:47 AM, Paul Vixie wrote:
>> From: Edward Lewis <Ed.Lewis@neustar.biz>
>> I had this additional thought - if the QNAME is pop.example.tld. and I find
>> this:
> before we start, note, i concur w/ marka, who answered simply:
> 	No. 

However, this line of reasoning is why NOERROR is returned.  Since the
QNAME exists.  And 'if the query is original' line from the algorithm.

> the query processing specified in RFC 1034 says that a CNAME RR can only be
> considered an answer if QTYPE=CNAME. i think you meant QNAME not QTYPE above
> but if you didn't then you're merely mistaken differently, or confused.

Actually, maybe not.  Perhaps the user wants the CNAME that the CNAME is
pointing to with its QTYPE=CNAME?   (or could be pointing to if you
modify your example).  Otherwise, how could the user specify he wanted
the second or third link in the chain of redirections?  It makes sense
to return the entire chain as far as it goes, lookup of the x-th CNAME
in the packet is very easy for the client, making it follow the chain
itself is hard (and the chain may change while it is working on it).

[Ed says:]
>> The issue is that there is only one RCODE in a return packet and it applies
>> to the QNAME, not where the query is redirected.

Yes I think this is.  You sometimes also get referrals after a CNAME for
example ... and there is but one AA flag.  (more evidence that QCOUNT!=1
is not easy).

Best regards,
   Wouter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkv8zKoACgkQkDLqNwOhpPgfegCeNTyKPUSmaeGPkMuEjtfNxXKF
VJQAoJ73g30ibeQtV1AhfhNbIHFHGeh/
=rstS
-----END PGP SIGNATURE-----

v2.23.0 | Report a Bug | By Email