Secure Bind DNS server problem
Arthur Stephens
astephens at ptera.net
Fri Apr 22 17:57:29 UTC 2005
These records were created many years ago before I got here.
This should be fixed now...
Thanks
Guido Roeskens wrote:
> 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
>
--
Arthur Stephens
Senior Sales Technician
PO Box 135
Liberty Lake, WA 99019
509-927-7837
www.ptera.net
More information about the bind-users
mailing list