← Back to branch summary

~ubuntu-branches/ubuntu/wily/maradns/wily-proposed

« back to all changes in this revision

Viewing changes to deadwood-3.2.05/doc/Recursive-algorithm.ej

  • Committer: Package Import Robot
  • Author(s): Dariusz Dwornikowski, Tomasz Buchert, Dariusz Dwornikowski
  • Date: 2015-03-27 18:34:08 UTC
  • mfrom: (1.2.12)
  • Revision ID: package-import@ubuntu.com-20150327183408-wnfachdkdjt96yu6
Tags: 2.0.11-1
http://bugs.debian.org/785536
http://bugs.debian.org/785535
[ Tomasz Buchert ]
* Imported Upstream version 2.0.11

[ Dariusz Dwornikowski ]
* d/patches: 
  - refreshed all patches for new deadwood version
  - removed generating of random prime on build (Closes: #785536) 
* d/rules: date taken from changelog (Closes: #785535)

Show diffs side-by-side

added added

removed removed

Lines of Context:
deadwood-3.2.05/doc/Recursive-algorithm.ej
1
 
<HEAD>
2
 
<TH>DEADWOOD 1 "August 2009" DEADWOOD "Deadwood reference"</TH>
3
 
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=utf-8">
4
 
</HEAD>
5
 
<BODY>
6
 
 
7
 
<b>Overview</b>
8
 
 
9
 
<p>
10
 
 
11
 
Deadwood is immune to many DNS spoofing attacks because it uses a 
12
 
different method to resolve domains than what most other DNS servers 
13
 
use.  While more complicated, and sometimes a little slower, this is 
14
 
more than compensated for by having better security.
15
 
 
16
 
<p>
17
 
 
18
 
The information here assumes some knowledge of DNS, which I will 
19
 
briefly summarize. 
20
 
 
21
 
<p>
22
 
 
23
 
<b>How DNS works</b>
24
 
 
25
 
<p>
26
 
 
27
 
A DNS reply contains multiple DNS answers.  It has an answer section, 
28
 
which has the answer to a DNS question made.  For example, if one 
29
 
requests the A (IPv4 IP) record for, say, www.example.com [<A 
30
 
href=#footnote1>1</A>], they may get an answer like "www.example.com's 
31
 
A record is the IP 10.1.2.3" [<A href=#footnote2>2</A>] [<A 
32
 
href=#footnote3>3</A>].
33
 
 
34
 
<p>
35
 
 
36
 
DNS replies can have multiple DNS records which can be in one of
37
 
three sections:
38
 
 
39
 
<ol>
40
 
<li>The "answer" section, which is for direct answers to DNS questions.
41
 
<li>The "authority records" (or "name server") section, which is for 
42
 
    nameserver referrals.
43
 
<li>The "additional records" or "glue" section, which has any other DNS 
44
 
    records which may be of interest.
45
 
</ol>
46
 
 
47
 
<p>
48
 
 
49
 
These are some typical answers we can get for our "www.example.com"
50
 
query above:
51
 
 
52
 
<ul>
53
 
<li>A direct answer to their question in the answer section, such as
54
 
    "www.example.com has the IP 10.1.2.3"
55
 
<li>What I call an "incomplete CNAME answer"; this is an answer 
56
 
    like "www.example.com has the CNAME www.example.net".  CNAME is
57
 
    a DNS record used for aliases; if, say, www.example.com has the CNAME
58
 
    www.example.net, this means that www.example.com's IP is whatever
59
 
    www.example.net's IP is.
60
 
<li>What I call an "incomplete NS referral"; this is an answer which
61
 
    has no records in the answer section, but has referrals to other
62
 
    DNS name servers in the "authority records" section, and, ideally,
63
 
    IPs for those name servers in the "additional records" section.
64
 
<li>What is sometimes called a "NXDOMAIN" answer.  This is an answer which
65
 
    means "this name does not exist".  Its format is no records in
66
 
    the answer section, and a record type called a "SOA" record in
67
 
    the "authority records" section. 
68
 
</ul>
69
 
 
70
 
Note that NS referrals are done by name, not IP.  DNS gives out a name 
71
 
like "www.example.net" for an answer instead of an IP like "10.4.2.1". 
72
 
[<A href=#footnote4>4</A>] A DNS answer may, or may not, have the IPs 
73
 
for the NS referrals in the "additional records" section of the answer.  
74
 
If if does have the corresponding IPs for the NS records, it is called 
75
 
a "glued NS referral".  If it does not have the corresponding IPs, it 
76
 
is a "glueless NS referral".
77
 
 
78
 
<p>
79
 
 
80
 
<b>How Deadwood resolves a name</b>
81
 
 
82
 
<p>
83
 
 
84
 
A simplified version of the method Deadwood uses to resolve a domain
85
 
via recursion is as follows:
86
 
 
87
 
<ol>
88
 
<li>Deadwood gets a request to resolve a given domain from a stub resolver
89
 
<li>Deadwood requests a domain from a root server.
90
 
<li>Deadwood gets an answer from that server.  
91
 
<li>Deadwood looks at the answer.
92
 
<li>There are three types of answers Deadwood can get:
93
 
        <ol>
94
 
        <li>A complete answer that answers the DNS question.
95
 
        <li>An incomplete NS referral, which can either have glue or
96
 
            be glueless.
97
 
        <li>An incomplete CNAME referral
98
 
        </ol>
99
 
<li>If the answer is a complete answer, Deadwood sends the answer 
100
 
    back to the stub resolver.
101
 
<li>If the answer is an incomplete answer, Deadwood must send more queries
102
 
    to get a complete answer.  I will detail this process below.
103
 
</ol>
104
 
 
105
 
<p>
106
 
 
107
 
<b>How Deadwood stops blind spoofing attacks</b>
108
 
 
109
 
<p>
110
 
 
111
 
Deadwood's recursive resolver is written with the following philosophy: 
112
 
The only answers that Deadwood will place in the cache while resolving 
113
 
a name are either pointers to incomplete NS referrals, or the direct 
114
 
answer to the question originally given to Deadwood.
115
 
 
116
 
<p>
117
 
 
118
 
For example, if someone asks Deadwood "what is the IP for 
119
 
www.paypal.com", Deadwood will only add the following records to the 
120
 
cache while resolving www.paypal.com:
121
 
 
122
 
<ul>
123
 
<li>The IPs of the name servers for anything ending ".com" that 
124
 
    doesn't otherwise have a name server.  These IPs can only be set
125
 
    by the root server IPs (which are either the default ICANN root 
126
 
    servers built-in to Deadwood or specified in ones dwood3rc file).
127
 
<li>The IPs of the name servers for anything ending in "paypal.com"
128
 
    can be added by either the root name servers or the name servers 
129
 
    delegated by the root servers as being the name servers for ".com".
130
 
    No other servers are allowed to assign names to "paypal.com".
131
 
<li>A name server delegation must be part of the domain asked for.  If 
132
 
    someone asks for "random-name-00000001.com", any answers received 
133
 
    will only affect ".com" (if they come from the root servers) or 
134
 
    "random-name-00000001.com" (but only if they come from the .com
135
 
    servers).  See dwx_string_bailiwick_query() in <A 
136
 
    href=http://maradns.org/deadwood/browse-source/stable/src/DwRecurse.c
137
 
    >DwRecurse.c</A>
138
 
<li>The IP for "www.paypal.com".  
139
 
</ul>
140
 
 
141
 
<p>
142
 
 
143
 
The information about what name servers to use for a given domain, say
144
 
"example.com", can only come from one of the following two sources:
145
 
 
146
 
<ul>
147
 
<li>The root name servers
148
 
<li>The name servers designated to serve ".com" domains.
149
 
</ul>
150
 
 
151
 
Information given by example.com's own name servers only affect names
152
 
ending in "example.com"; they do not affect the name servers for 
153
 
example.com [<A href=#footnote5>5</A>].
154
 
 
155
 
<p>
156
 
 
157
 
<b>Handling "incomplete" answers</b>
158
 
 
159
 
<p>
160
 
 
161
 
Deadwood does not store name server referrals as NS records nor 
162
 
incomplete CNAME referrals as CNAME records.  Deadwood uses special 
163
 
records for storing these incomplete records.
164
 
 
165
 
<p>
166
 
 
167
 
In the case of either a glueness NS referral or an incomplete CNAME 
168
 
answer, Deadwood will create a sub-query to answer the query in 
169
 
question.  This query is a new query that starts at the root to resolve 
170
 
a given name.
171
 
 
172
 
<p>
173
 
 
174
 
<b>Choosing what to cache</b>
175
 
 
176
 
<p>
177
 
 
178
 
Unlike other DNS resolvers, Deadwood does <i>not</i> indiscriminately 
179
 
add records to the cache that are seen in the additional records 
180
 
section of a DNS answer, even if the answers are "in bailiwick".  This 
181
 
protects Deadwood from the Kaminsky DNS attack where someone can try 
182
 
and get "www.paypal.com" to point to a phishing page by sending queries 
183
 
like "0000001.paypal.com", "0000002.paypal.com", and so on, along with 
184
 
spoofed answers which have a very small chance of being accepted.  The 
185
 
spoofed answers to the query have, in the additional records section, 
186
 
the DNS record "www.paypal.com has the IP 10.6.6.6" and "10.6.6.6" 
187
 
points to a phishing page.  If someone tries this attack on Deadwood, 
188
 
a successful spoof will only affect meaningless records like 
189
 
"62f8ec94.paypal.com".
190
 
 
191
 
<p>
192
 
 
193
 
<b>Linking names to IPs</b>
194
 
 
195
 
<p>
196
 
 
197
 
In order to avoid needing to indiscriminately store records in the 
198
 
"additional records" section, Deadwood, when getting an incomplete NS 
199
 
referral, will look to see if any of the names in the authority records 
200
 
section have a corresponding IP for the name in the additional records 
201
 
section.  If they do, said names are converted and stored in Deadwood's 
202
 
cache as IPs.  If not, they are stored as glueless names.
203
 
 
204
 
<p>
205
 
 
206
 
For example, let us suppose we have an answer like this when we ask for
207
 
www.example.com:
208
 
 
209
 
<ul>
210
 
<li>Authority section: A name server for example.com is ns1.example.com
211
 
<li>Authority section: A name server for example.com is ns2.example.com
212
 
<li>Authority section: A name server for example.com is ns.example.net
213
 
<li>Additional section: ns1.example.com has the IP 10.2.2.1
214
 
<li>Additional section: ns2.example.com has the IP 10.2.2.2
215
 
</ul>
216
 
 
217
 
Deadwood converts this answer to look like this:
218
 
 
219
 
<ul>
220
 
<li>This record contains name servers for example.com
221
 
<li>10.2.2.1 is a glued name server
222
 
<li>10.2.2.2 is a glued name server
223
 
<li>ns.example.net is a glueless name server
224
 
</ul>
225
 
 
226
 
See dwx_make_ns_refer() in <A
227
 
href=http://maradns.org/deadwood/browse-source/stable/src/DwRecurse.c 
228
 
>DwRecurse.c</A> for more details.
229
 
 
230
 
<p>
231
 
 
232
 
<b>Conclusion</b>
233
 
 
234
 
<p>
235
 
 
236
 
While more complicated, Deadwood's recursion algorithm provides, short of 
237
 
DNSSEC, the best DNS spoof protection.
238
 
 
239
 
<p>
240
 
 
241
 
<b>Footnotes</b>
242
 
 
243
 
<p>
244
 
 
245
 
<A name=footnote1>[1]</A> Note that "example.com" is always used for
246
 
examples and is reserved when examples are needed in documents about DNS.
247
 
example.net and example.org are other example domains.
248
 
 
249
 
<p>
250
 
 
251
 
<A name=footnote2>[2]</A> These are not real-world numbers; IPv4 IP
252
 
numbers that begin in "10" are only used in internal networks and can
253
 
not be reached from the Internet at large.
254
 
 
255
 
<p>
256
 
 
257
 
<A name=footnote3>[3]</A> The format of DNS queries is somewhat 
258
 
different; I am translating them in to English.  It's like translating
259
 
conversations from Spanish in to English.  The binary format is
260
 
described in <A href=http://www.ietf.org/rfc/rfc1035.txt>RFC 1035</A>.
261
 
 
262
 
<p>
263
 
 
264
 
<A name=footnote4>[4]</A> I agree with <A href=http://cr.yp.to>DJB</A>
265
 
that having NS referrals done by name instead of IP was a mistake in
266
 
the design of DNS.
267
 
 
268
 
<p>
269
 
<A name=footnote5>[5]</A> example.com's name servers can also 
270
 
sub-delegate domain names to other name servers.  For example, the 
271
 
example.com name servers can say "all names that end in 
272
 
'sub.example.com' are handled by the name servers at 10.3.2.1"
273
 
 
274
 
<p>
275
 
 
276
 
</BODY>