← Back to branch summary

~ubuntu-branches/ubuntu/trusty/maradns/trusty-proposed

« back to all changes in this revision

Viewing changes to doc/en/text/dangling.txt

  • Committer: Package Import Robot
  • Author(s): Dariusz Dwornikowski
  • Date: 2014-02-16 19:36:04 UTC
  • mfrom: (1.2.11) (21.1.11 experimental)
  • Revision ID: package-import@ubuntu.com-20140216193604-xtmcopn9pilzszae
Tags: 2.0.09-1
http://bugs.debian.org/739084
http://bugs.debian.org/739755
http://bugs.debian.org/710903
http://bugs.debian.org/709826
http://bugs.debian.org/701657
* New maintainer (Closes: #739084)
* New upstream release to unstable
* Several security bugs (Closes: #739755)
   - security bugfix for CVE-2011-5055, CVE-2011-5056, CVE-2012-0024,
   CVE-2012-1570
   - security bugfix agains blind spoofing attack (no CVE number)
   - security bugfix for packet of death attack (no CVE number)
* Bump standards to 3.9.5
* Updated d/postinst to no longer modify conffiles (Closes: #710903)
* Init script fixed (Closes: #709826)
* --reinstall no longer kills the process (Closes: #701657)
* Updated old d/changelog entries, added information when the CVEs were
  fixed: 2.0.06-1, 2.0.04-1, 1.4.11-1, 1.2.12.06-1, 1.2.12.05-1, 1.0.28-1

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/en/text/dangling.txt
 
1
   This document is for people who are getting a "dangling CNAME"
 
2
   warning, or who wish to have CNAME records that point to records
 
3
   served by other DNS servers.
 
4
 
1
5
   There are two cases that can cause the "dangling CNAME" message
2
6
   to appear:
3
7
 
29
33
   not resolvable by some stub resolvers. In order to resolve
30
34
   dangling CNAME records, MaraDNS can be configured thusly:
31
35
 
32
 
     * We run two servers of MaraDNS on two different IPs.
 
36
     * We run MaraDNS server on one IP and a Deadwood server on
 
37
       another IP.
33
38
     * For the sake of this example, we will suppose that the
34
39
       server people send queries to for resolving hostnames has
35
 
       the IP 192.168.1.1. We will further suppose that there is a
36
 
       server which has the dangling CNAME issue with the IP
37
 
       192.168.1.2
38
 
     * Set up 192.168.1.1 to use 192.168.1.2 as an upstream server
39
 
       by the use of the upstream_servers mararc variable.
40
 
     * Set up 192.168.1.2 to be both an authoritative and recursive
41
 
       DNS server, and have dangling CNAME records in the
 
40
       the IP 192.168.1.1, which will be running Deadwood. We will
 
41
       further suppose that there is a MaraDNS server which has the
 
42
       dangling CNAME issue with the IP 192.168.1.2
 
43
     * Set up 192.168.1.1 to use 192.168.1.2 to resolve all
 
44
       hostnames that end in, say, "example.com.", via the
 
45
       upstream_servers dwood3rc variable.
 
46
     * Set up 192.168.1.2 to have dangling CNAME records in the
42
47
       authoritative half.
43
48
 
44
49
   This will cause dangling CNAME records to be fully resolved;
48
53
    1. A stub resolver asks 192.168.1.1 the IP address for, say
49
54
       "google.example.com"
50
55
    2. 192.168.1.1 asks 192.168.1.2 the IP address for
51
 
       "google.example.com"
 
56
       "google.example.com" (since the name ends in "example.com")
52
57
    3. 192.168.1.2 tells 192.168.1.1 "google.example.com is a CNAME
53
58
       for www.google.com, and I don't have an IP for it"
54
59
    4. 192.168.1.1, seeing that it has a CNAME without an IP, asks
55
 
       192.168.1.2 the IP for "www.google.com"
56
 
    5. 192.168.1.2 recursively resolves the IP for www.google.com,
57
 
       and gives this IP for 192.168.1.1
58
 
    6. Now that 192.168.1.1 has a complete record, it will send
59
 
       this record to the stub resolver. In other words,
60
 
       192.168.1.1 will tell the stub resolver that
61
 
       google.example.com is a CNAME for www.google.com, and then
62
 
       give out the IP for www.google.com.
 
60
       nameservers on the internet for the IP for "www.google.com"
 
61
    5. When 192.168.1.1 has a complete record, it will send this
 
62
       record to the stub resolver. In other words, 192.168.1.1
 
63
       will tell the stub resolver that google.example.com is a
 
64
       CNAME for www.google.com, and then give out the IP for
 
65
       www.google.com.
63
66
 
64
 
   Here is an example mararc file for 192.168.1.1:
 
67
   Here is an example dwood3rc file for 192.168.1.1:
65
68
 
66
69
 ipv4_bind_addresses = "192.168.1.1"
67
70
 chroot_dir = "/etc/maradns"
68
71
 recursive_acl = "192.168.1.0/24"
69
 
 upstream_servers = "192.168.1.2"
 
72
 upstream_servers = {}
 
73
 upstream_servers["example.com."] = "192.168.1.2"
70
74
 
71
75
   Here is an example mararc file for 192.168.1.2:
72
76
 
73
77
 ipv4_bind_addresses = "192.168.1.2"
74
78
 chroot_dir = "/etc/maradns"
75
 
 recursive_acl = "192.168.1.1"
76
79
 csv2 = {}
77
80
 csv2["example.com."] = "db.example.com"
78
81
 
79
82
   If dangling CNAMEs are not an issue for a given setup, or if
80
 
   they are resolved by the above setup with two instances of
81
 
   MaraDNS, the warnings about dangling CNAMEs can be turned off by
82
 
   adding this to a mararc file:
 
83
   they are resolved by the above setup using both MaraDNS and
 
84
   Deadwood, the warnings about dangling CNAMEs can be turned off
 
85
   by adding this to a mararc file:
83
86
 
84
87
 no_cname_warnings = 1
85
88