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