Re: [dnsext] CNAME/DNAME and NXDOMAIN

Matthijs Mekking <matthijs@NLnetLabs.nl> Mon, 14 November 2011 10:42 UTC

Message-ID: <4EC0F0A3.1090501@nlnetlabs.nl>
Date: Mon, 14 Nov 2011 11:42:43 +0100
From: Matthijs Mekking <matthijs@NLnetLabs.nl>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110922 Thunderbird/3.1.15
MIME-Version: 1.0
To: Mark Andrews <marka@isc.org>
References: <a06240803cad9af9e1e04@[192.168.128.112]> <20111104231715.AA38F16AD6F6@drugs.dv.isc.org>
In-Reply-To: <20111104231715.AA38F16AD6F6@drugs.dv.isc.org>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: Edward Lewis <Ed.Lewis@neustar.biz>, dnsext@ietf.org
Subject: Re: [dnsext] CNAME/DNAME and NXDOMAIN
Precedence: list

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

On 11/05/2011 12:17 AM, Mark Andrews wrote:
> 
> Both answers are self consistant and neither should cause a problem.
> 
> Following CNAME records, when not recursing for the client, is a
> security issue as the target of the CNAME may not be delegated to
> the same machine leading to potential, accidental, cache poisioning.

An authoritative server should follow CNAME records while the target is
actually being served. If it is delegated to another machine, you return
the chain of CNAMEs until then. The recursive name server can continue
recursing.

> We (ISC) have looked at not following CNAME records when generating
> such replies.  We already discard the rest of the response and
> requery for the target of the CNAME.

So you would query the same machine, despite that server is giving you a
chain?

Refocusing on Ed Lewis initial question, regarding the RCODE. One server
is giving NXDOMAIN, the other NOERROR. Given the fact that CNAME records
where followed, the status code should not be switched to NXDOMAIN. This
is conform the server algorithm in RFC2672.

Also, it was questioned if this should be changed in the dname-bis document:

    http://www.ietf.org/mail-archive/web/dnsext/current/msg09224.html

Although the response was minimal, the suggestion was to make no change.

For NSD, because it is not considered an NXDOMAIN response (following
step 3c of the server algorithm), the SOA record is not added to the
Authority Section. Though, the target does not exist, so the NSEC3
records are still added.

I don't know if adding the NSEC3 records is the right thing to do, I
seem to be unable to find the text what to do in this specific case.
Although, both NSD and BIND seem to be in some sort of agreement that
the records are needed.

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

iQEcBAEBAgAGBQJOwPCjAAoJEA8yVCPsQCW5PjwIAKB5FYDCBkGgml/o2EoKyxDw
KY4cSquPk2u7JAN3GBW3Q5v2xU+6vATg/JrYjDmKjTH+IElT2lmoNVKRNe5C42/i
4UvoyIwMgF9LIVp0pnaPLE1RaGyCurqVkQiFZ7OqNtmB5rLzncXMYAtc2fKQfnYQ
oiNsjaKGHoVcJAmYBQHQ26Y+FwL8kD8PELVBU666jkOJQp2S1xQhqxgzfzOswUtS
7cXkob79yTC4BgB/Fqmdfyt326In+jstpfYE3vAnmfpvaKzOYYp7pnX56k54YC7x
39sZoum9njlxSShLTCEWGR7eUL7TlyZIVgwWh7xUE01hUwDxbk/uazTLZAZC2xQ=
=2W0Q
-----END PGP SIGNATURE-----

[dnsext] CNAME/DNAME and NXDOMAIN Edward Lewis
Re: [dnsext] CNAME/DNAME and NXDOMAIN Mark Andrews
Re: [dnsext] CNAME/DNAME and NXDOMAIN Matthijs Mekking
Re: [dnsext] CNAME/DNAME and NXDOMAIN Evan Hunt
Re: [dnsext] CNAME/DNAME and NXDOMAIN Nicholas Weaver