Gentoo Archives: gentoo-commits

From: "Markos Chandras (hwoarang)" <hwoarang@g.o>
To: gentoo-commits@l.g.o
Subject: [gentoo-commits] gentoo-x86 commit in net-libs/adns/files: adns-1.4-cnamechain.patch
Date: Tue, 10 Nov 2009 13:53:38
Message-Id: E1N7rA7-0001Fz-VT@stork.gentoo.org
hwoarang    09/11/10 13:53:35

  Added:                adns-1.4-cnamechain.patch
  Log:
  Fix cname issue ( bug #292545 ). EAPI2fy it
  (Portage version: 2.2_rc49/cvs/Linux x86_64)

Revision  Changes    Path
1.1                  net-libs/adns/files/adns-1.4-cnamechain.patch

file : http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-libs/adns/files/adns-1.4-cnamechain.patch?rev=1.1&view=markup
plain: http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-libs/adns/files/adns-1.4-cnamechain.patch?rev=1.1&content-type=text/plain

Index: adns-1.4-cnamechain.patch
===================================================================
[ADNS] Re: CNAME chains 
Brad Spencer spencer at infointeractive.com 
Mon, 28 Aug 2006 14:43:00 -0300 

Previous message: CNAME chains 
Next message: CNAME chains option 
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] 
--pf9I7BMVVzbSWLtt
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Fri, Aug 25, 2006 at 11:36:04AM -0700, William Ahern wrote:
> On Fri, Aug 25, 2006 at 09:39:01AM +0100, peter burden wrote: > > Hello, > > Is there any way to make ADNS follow CNAME chains ? > > > > I have set the adns_qf_cname_loose query flag and it seems OK for a > > single > > CNAME - e.g. (output from 'dig')
I posted a small patch back in 2003 that made changes to adns so that it would follow CNAME chains. See http://www.chiark.greenend.org.uk/pipermail/adns-discuss/2003/001072.html The patch included in that post is against an old adns version, so I have attached my latest version of the patch to this message. (I have not tested that the attached patch applied cleanly to the current adns source, but it may be slightly more in sync with the current version.)
> CNAME chains are technically not allowed. Such chains are violations of the > specifications. Also, I believe MX host lookups returning CNAMEs (i.e. MX > yahoo.com -> A mail.yahoo.com -> CNAME foo) is also illegal.
I have also been told that CNAME chains are illegal, but I can not find any actual text that says that a resolver should fail when it encounters them. In fact, RFC 1034 Section 3.6.2 says: Domain names in RRs which point at another name should always point at the primary name and not the alias. This avoids extra indirections in accessing information. For example, the address to name RR for the above host should be: 52.0.0.10.IN-ADDR.ARPA IN PTR C.ISI.EDU rather than pointing at USC-ISIC.ARPA. The above implies that CNAME chains are illegal, IMO. But then, the next sentence is: Of course, by the robustness principle, domain software should not fail when presented with CNAME chains or loops; CNAME chains should be followed and CNAME loops signalled as an error. This advice, coupled with the fact that CNAME chains exist in the wild, triggered me to create the patch in the first place. My patch doesn't detect loops, but instead simply won't follow chains longer than a certain (hard-coded) size. Hope this helps! -- ------------------------------------------------------------------ Brad Spencer - spencer@×××××××××××××××.com - "It's quite nice..." Systems Architect | InfoInterActive Corp. | A Canadian AOL Company --pf9I7BMVVzbSWLtt Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="cname_chains.diff" Index: src/internal.h =================================================================== RCS file: /iia/cvsroot/3rdParty/gnu/adns/adns-1.0/src/internal.h,v retrieving revision 1.3 retrieving revision 1.4 diff -u -p -r1.3 -r1.4 --- src/internal.h 2 Oct 2003 17:01:46 -0000 1.3 +++ src/internal.h 2 Oct 2003 17:14:29 -0000 1.4 @@ -206,6 +206,9 @@ struct adns__query { int cname_dglen, cname_begin; /* If non-0, has been allocated using . */ + int cname_alias_hops_left; + /* The number of cname alias hops we will allow */ + vbuf search_vb; int search_origlen, search_pos, search_doneabs; /* Used by the searching algorithm. The query domain in textual form Index: src/query.c =================================================================== RCS file: /iia/cvsroot/3rdParty/gnu/adns/adns-1.0/src/query.c,v retrieving revision 1.3 retrieving revision 1.4 diff -u -p -r1.3 -r1.4 --- src/query.c 2 Oct 2003 17:01:47 -0000 1.3 +++ src/query.c 2 Oct 2003 17:14:29 -0000 1.4 @@ -63,6 +63,8 @@ static adns_query query_alloc(adns_state qu->cname_dgram= 0; qu->cname_dglen= qu->cname_begin= 0; + /* Allow CNAME chains up to some sane limit */ + qu->cname_alias_hops_left = 10; adns__vbuf_init(&qu->search_vb); qu->search_origlen= qu->search_pos= qu->search_doneabs= 0; Index: src/reply.c =================================================================== RCS file: /iia/cvsroot/3rdParty/gnu/adns/adns-1.0/src/reply.c,v retrieving revision 1.3 retrieving revision 1.4 diff -u -p -r1.3 -r1.4 --- src/reply.c 2 Oct 2003 17:01:47 -0000 1.3 +++ src/reply.c 2 Oct 2003 17:14:30 -0000 1.4 @@ -191,12 +191,13 @@ void adns__procdgram(adns_state ads, con if (qu->flags & adns_qf_cname_forbid) { adns__query_fail(qu,adns_s_prohibitedcname); return; - } else if (qu->cname_dgram) { /* Ignore second and subsequent CNAME(s) */ + } else if (qu->cname_dgram && --(qu->cname_alias_hops_left) <= 0) { /* Don't follow "too long" CNAME chains */ adns__debug(ads,serv,qu,"allegedly canonical name %s" - " is actually alias for %s", qu->answer->cname, + " is actually alias for %s and aliases too deep", + qu->answer->cname, adns__diag_domain(ads,serv,qu, &qu->vb, dgram,dglen,rdstart)); - adns__query_fail(qu,adns_s_prohibitedcname); + adns__query_fail(qu,adns_s_norecurse); return; } else if (wantedrrs) { /* Ignore CNAME(s) after RR(s). */ adns__debug(ads,serv,qu,"ignoring CNAME (to %s) coexisting with RR", --pf9I7BMVVzbSWLtt--