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
|
Local DNSSEC validation with OpenSwan
=====================================
Introduction
------------
These patches add support for performing local DNSSEC validation for
all DNS lookups. This document contains very brief instructions
on how to use this feature. Configuring DNS is out of the scope of this
document.
There are 3 patches:
- makefile.patch, which add some defines and libraries
- libval.patch, which adds local validation to adns
- libval-threads.patch, which adds local validation to adns, using
pthreads instead of forked processes.
Background
----------
A detailed description of DNSSEC is out of scope for this document,
but a basic background is provided.
DNS response packets are fairly easy to spoof, so an attacker situated
in the network path between a host and its configured DNS server
could possibly inject DSN response packets,
DNSSEC introduces cryptographic signing of DNS records, allowing a
resolver to verify that a response has not been spoofed. This is
done by configuring 'Trust Anchors', which are know good keys used to
sign a zone.
Further rational for why one might want to use local validation is
give at the end of this document.
Requirements
------------
This code requires that the DNSSEC-Tools resolver and validator
libraries and headers be installed. The DNSSEC-Tools package
can be obtained from:
http://www.dnssec-tools.org/resources/download.html
Note that the Perl requirements are not needed if you only want
to install/use the resolver and validator libraries.
By default, the validator library will use the resolver specified
in /usr/local/etc/dnssec-tools/resolv.conf when performing DNS queries.
If the resolver(s) in that file are not DNSSEC aware, the validator
won't be able to get the data is needs for local validation. In this
case, you may need to tweak the RESOLV_CONF definition in the validator
library header (dnssec-tools/validator/includes/validator/validator.h)
before building and installing the libraries. If there is not a DNSSEC
aware nameserver you can use, simply leave the file empty, and the library
will perform all validation itself, starting from the root
nameservers.
Using DNSSEC validation
-----------------------
The extra validation code in OpenSwan is optional, and must be enabled
by specifying "-DDNSSEC_LOCAL_VALIDATION" in the CFLAGS defined in
the programs/pluto/Makefile. Additionally, -DADNS_THREADS may be
specified to use pthreads instead of forked processes. The advantage
of using pthreads is that all threads will share a local DNS cache.
Rational for Local Validation
-----------------------------
OpenSwan already has code to verify DNSSEC validity for DNS records,
so one might wonder why they would want local validation. There are
several reasons.
- Deployment of DNSSEC is progressing quite slowly, so end
users might not have DNS servers which are capable of, or configured
for, DNSSEC processing.
- DNSSEC only guarantees the integrity of the DNS response to
the DNS server. The response from the DNS server to the local host
has no protection. Thus an attacker who can inject packets in the
path between a DNS server and a stub resolver can not only redirect
the client, but can make it belive a response was authentic!
- Even if a DNSSEC server is on a local and trusted network, an end
user might not have any influence over local policy. In other words,
they might not be able to get a new Trust Anchor configured for a
zone which they trust.
- A DNSSEC server will not return data to an application for a response
which appears to have been modified. The means that, to the local
host, the DNS lookups will appear to have failed, even if the DNS
Robert Story
SPARTA, Inc.
|
