Secure Bind DNS server problem
Guido Roeskens
groeskens at bluewin.ch
Thu Apr 21 18:58:42 UTC 2005
Hello,
First: please fix you setup (see ****) :
$ dig ns1.ptera.net @69.28.32.17
; <<>> DiG 9.2.3 <<>> ns1.ptera.net @69.28.32.17
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 1
;; QUESTION SECTION:
;ns1.ptera.net. IN A
;; ANSWER SECTION:
ns1.ptera.net. 86400 IN CNAME dns.ptera.net.
**** NS records MUST NOT be an Alias (CNAME) !!!
dns.ptera.net. 86400 IN A 69.28.32.16
;; AUTHORITY SECTION:
ptera.net. 86400 IN NS dns.ptera.net.
ptera.net. 86400 IN NS dns2.ptera.net.
;; ADDITIONAL SECTION:
dns2.ptera.net. 86400 IN A 69.28.32.17
;; Query time: 200 msec
;; SERVER: 69.28.32.17#53(69.28.32.17)
;; WHEN: Thu Apr 21 10:33:30 2005
;; MSG SIZE rcvd: 114
see RFC1912; Section 2.4
---
Don't use CNAMEs in combination with RRs which point to other names
like MX, CNAME, PTR and NS. (PTR is an exception if you want to
implement classless in-addr delegation.) For example, this is
strongly discouraged:
---
an last paragraph:
---
Having NS records pointing to a CNAME is bad and may conflict badly
with current BIND servers. In fact, current BIND implementations
will ignore such records, possibly leading to a lame delegation.
There is a certain amount of security checking done in BIND to
prevent spoofing DNS NS records. Also, older BIND servers reportedly
will get caught in an infinite query loop trying to figure out the
address for the aliased nameserver, causing a continuous stream of
DNS requests to be sent.
---
Right now you have "CNAME and other data" for ns1.ptera.net
(In the gTLD for net. there are glue A records for ns1.ptera.net
while in your zone its an alias (CNAME)
If you look at
http://www.dnsreport.com/tools/dnsreport.ch?domain=ptera.net
you see many problems with your domain.
Why does this not work:
0. we want to look up ns1.ptera.net
1. a nameserver queries the gTLD Servers for net. for the NS and A
Records for the domain ptera.net
---
ptera.net. 172800 IN NS ns1.ptera.net.
ptera.net. 172800 IN NS ns2.ptera.net.
ns1.ptera.net. 172800 IN A 69.28.32.16
ns2.ptera.net. 172800 IN A 69.28.32.17
---
2. Now the nameserver queries the servers authoritative for the domain
---
ns1.ptera.net. 86400 IN CNAME dns.ptera.net.
---
so forget anything (the IP address) about ns1.ptera.net and replace
ns1.ptera.net
with dns.ptera.net
3. Now the nameserver wants to follow the alias
- ns1.ptera.net is a nameserver for ptera.net
- ns1.ptera.net is really dns.ptera.net
- dns.ptera.net cannot be looked up (we don't have an IP address
of a nameserver to query)
(A glue record in the net. gTLD for dns.ptera.net wouldn't help either)
Arthur Stephens wrote:
> I am trying to secure my DNS BIND version 9.2.5 servers so I found this
> template
> Secure BIND Template Version 4.8 12 APR 2005
> By Rob Thomas, robt at cymru.com
> After disabling these that complained at startup...
>
> //pid-file "/var/named/named.pid";
> //memstatistics-file "/var/named/named.memstats";
>
> I got the server up and running. And successfully tested from inside.
> But I noticed these in the logs right away.
>
> Apr 18 13:46:11 daffy named[24498]: client 71.4.246.96#32770: query
> 'ptera.net/IN' denied
> Apr 18 13:46:16 daffy named[24498]: client 195.49.141.22#32819: query
> 'mail.aiin.com/IN' denied
> Apr 18 13:46:16 daffy named[24498]: client 195.49.141.22#32819: query
> 'mail.aiin.com/IN' denied
> Apr 18 13:46:16 daffy named[24498]: client 195.49.141.22#32819: query
> 'dns2.ptera.net/IN' denied
> Apr 18 13:46:16 daffy named[24498]: client 195.49.141.22#32819: query
> 'dns2.ptera.net/IN' denied
> Apr 18 13:46:16 daffy named[24498]: client 195.49.141.22#32819: query
> 'dns.ptera.net/IN' denied
> Apr 18 13:46:16 daffy named[24498]: client 195.49.141.22#32819: query
> 'dns.ptera.net/IN' denied
> Apr 18 13:46:36 daffy named[24498]: client 67.19.0.13#53: query
> 'aiin.com/IN' denied
>
> This was not good. I then tried using tools at http://www.dnsstuff.com/
>
> It returned that the DNS server refused to resolve the names. This is
> bad because it means that people legitimately trying to get to
> mail.aiin.com etc. couldn't. Just in case here is the db file for aiin.com
>
> $ORIGIN .
> $TTL 86400 ; 1 day
> aiin.com IN SOA aiin.com. hostmaster.aain.com. (
^^^ Your SOA record seems wrong to me
aiin.com. IN SOA dns.ptera.net. hostmaster.aain.com. (
^^^^ add a dot here. If someone deletes to "$ORIGN ." statement
above, yor SOA record will still work
^^^^ the MNAME field should contain a
hostname of a nameserver authoritative
for the domain (It should be the master
or primary for the domain.
See also http://www.dnsreport.com/tools/dnsreport.ch?domain=aiin.com
Check all you zone files for similar errors.
I don't use this explicit nameing in my zone files and
also avoid '$ORIGIN'
then you could use
@ IN SOA dns.ptera.net. hostmaster.aain.com. (
> 2004111602 ; serial
> 10800 ; refresh (3 hours)
> 3600 ; retry (1 hour)
> 604800 ; expire (1 week)
> 86400 ; minimum (1 day)
> )
> IN NS dns.ptera.net.
> IN NS dns2.ptera.net.
> IN A 216.255.223.207
> IN MX 10 mail.aiin.com.
> $ORIGIN aiin.com.
> mail IN A 69.28.41.3
> www IN A 216.255.223.207
>
> As you can see their web server is hosted outside of our network but
> their mail server is inside of our network. This worked before.
>
> Can anyone look at the named.conf file below and tell me where I missed?
>
When using such templates you need to read them carefully
http://www.cymru.com/Documents/secure-bind-template.html
If you use the bogon filter, you need to update it regularily
http://www.cymru.com/Documents/bogon-list.html
(It was changed
From the template (and also in your config)
--- SNIP ---
allow-query {
// Accept queries from our "trusted" ACL. We will
// allow anyone to query our master zones below.
// This prevents us from becoming a free DNS server
// to the masses.
trusted;
};
--- SNIP ---
Read the second sentence and look further down in the template:
--- SNIP ---
// Create a view for external DNS clients.
view "external-in" in {
// ...
zone "ournetwork.net" in {
type master;
file "master/db.ournetwork";
allow-query {
any;
};
// ^^^^ HERE the template allows anyone to query
// the zones for which the server is authoritative
};
So need to allow querying in the external view
--- SNIP ---
// ....
// Create a view for external DNS clients.
view "external-in" in {
// Our external (untrusted) view. We permit any client to access
// portions of this view. We do not perform recursion or cache
// access for hosts using this view.
match-clients { any; };
recursion no;
additional-from-auth no;
additional-from-cache no;
--- SNIP ---
Alternative 1:
generally (before any zone definition)
---
allow-query { any; };
---
Alternative 2: per domain
--- SNIP ---
// ....
zone "aiin.com" IN {
type master;
file "aiin.com.db";
// HERE: allow anybody to query the zone
allow-query { any; };
};
--- SNIP ---
You would need to add the allow-query to
every zone you are authoritative.
---
Now to another post regarding the question.
--- SNIP ---
0.0.0.0/8; <- maybe this is hosing up BIND?
--- SNIP ---
No, not at all...
0.0.0.0 is a valid IP address and 0.0.0.0/8 is
a normal A class (this is really a class A
However 0.0.0.0/8 was never issued and will probably never be
assigned to anyone (as 0.0.0.0 is the network address of the
whole IPv4 address space)
Guido
More information about the bind-users
mailing list