summaryrefslogtreecommitdiff
blob: 4c87a14346606c8e1360ae319778d250f94e412b (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
[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@infointeractive.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--