0

I'm struggling for a last couple of days to make my bind work. I believe, it have a very generic config, but somehow it won't serve a proper IP of my server to local clients, when the domain name is used (myho.st). System is Debian Wheezy. named-checkconf does not report any errors.

Configs are as follows:

/etc/bind/named.conf:

include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.log";
include "/etc/bind/named.conf.local";
include "/etc/bind/named.conf.default-zones";

acl localhost_acl {
        127.0.0.1;
};

acl internal_10_acl {
        192.168.10.0/24;
};

/etc/bind/named.conf.local:

include "/etc/bind/zones.rfc1918";

view "local_view" {

        match-clients { localhost_acl; internal_10_acl; };

        zone "myho.st" {
                type master;
                file "/etc/bind/db.myho.st";
        };

};

/etc/bind/zones.rfc1918:

view "global_view" {

        zone "10.in-addr.arpa"      { type master; file "/etc/bind/db.empty"; };

        zone "16.172.in-addr.arpa"  { type master; file "/etc/bind/db.empty"; };
        zone "17.172.in-addr.arpa"  { type master; file "/etc/bind/db.empty"; };
        zone "18.172.in-addr.arpa"  { type master; file "/etc/bind/db.empty"; };
        zone "19.172.in-addr.arpa"  { type master; file "/etc/bind/db.empty"; };
        zone "20.172.in-addr.arpa"  { type master; file "/etc/bind/db.empty"; };
        zone "21.172.in-addr.arpa"  { type master; file "/etc/bind/db.empty"; };
        zone "22.172.in-addr.arpa"  { type master; file "/etc/bind/db.empty"; };
        zone "23.172.in-addr.arpa"  { type master; file "/etc/bind/db.empty"; };
        zone "24.172.in-addr.arpa"  { type master; file "/etc/bind/db.empty"; };
        zone "25.172.in-addr.arpa"  { type master; file "/etc/bind/db.empty"; };
        zone "26.172.in-addr.arpa"  { type master; file "/etc/bind/db.empty"; };
        zone "27.172.in-addr.arpa"  { type master; file "/etc/bind/db.empty"; };
        zone "28.172.in-addr.arpa"  { type master; file "/etc/bind/db.empty"; };
        zone "29.172.in-addr.arpa"  { type master; file "/etc/bind/db.empty"; };
        zone "30.172.in-addr.arpa"  { type master; file "/etc/bind/db.empty"; };
        zone "31.172.in-addr.arpa"  { type master; file "/etc/bind/db.empty"; };

};

/etc/bind/named.conf.default-zones:

view "default_view" {

        // prime the server with knowledge of the root servers
        zone "." {
                type hint;
                file "/etc/bind/db.root";
        };

        // be authoritative for the localhost forward and reverse zones, and for
        // broadcast zones as per RFC 1912

        zone "localhost" {
                type master;
                file "/etc/bind/db.local";
        };

        zone "127.in-addr.arpa" {
                type master;
                file "/etc/bind/db.127";
        };

        zone "0.in-addr.arpa" {
                type master;
                file "/etc/bind/db.0";
        };

        zone "255.in-addr.arpa" {
                type master;
                file "/etc/bind/db.255";
        };

};

/etc/bind/named.conf.log:

logging {
        channel update_debug {
                file "/var/log/bind/update_debug.log" versions 3 size 100k;
                severity debug;
                print-severity  yes;
                print-time      yes;
        };
        channel security_info {
                file "/var/log/bind/security_info.log" versions 1 size 100k;
                severity info;
                print-severity  yes;
                print-time      yes;
        };
        channel bind_log {
                file "/var/log/bind/bind.log" versions 3 size 1m;
                severity info;
                print-category  yes;
                print-severity  yes;
                print-time      yes;
        };

        category default { bind_log; };
        category lame-servers { null; };
        category update { update_debug; };
        category update-security { update_debug; };
        category security { security_info; };
};

/etc/bind/named.conf.options:

options {

        directory "/var/cache/bind";
        dnssec-validation auto;
        auth-nxdomain no;    # conform to RFC1035
        listen-on-v6 { none; };
        listen-on {
                127.0.0.1;
                192.168.10.1;
        };
        allow-transfer { none; };
        allow-query { localhost_acl; internal_10_acl; };

};

and finally /etc/bind/db.myho.st:

$TTL    3h
@       IN      SOA     ns.myho.st. hostmaster.myho.st. (
                          4        ; Serial
                          3h       ; Refresh after 3 hours
                          1h       ; Retry after 1 hour
                          1w       ; Expire after 1 week
                          1h )     ; Negative caching TTL of 1 day
;
@               IN      NS      ns.myho.st.

@               IN      A       192.168.10.1
ns              IN      A       192.168.10.1

named-checkzone myho.st /etc/bind/db.myho.st doesn't report any errors.

My clients are in 192.168.10.0/24 subnet and all of them can ping 192.168.10.1, which is server's IP. But the myho.st domain name is getting resolved through the ISP's DNS to the global IP, however seems like served by my server:

user@client:~$ nslookup myho.st
Server:         192.168.10.1
Address:        192.168.10.1#53

Non-authoritative answer:
Name:   myho.st
Address: *some global IP*

Obviously I missed some essential setting in named.conf*, but I fail to see which exactly. Probably the views aren't configured properly. Please advise.

Neurotransmitter
  • 468
  • 1
  • 6
  • 17

2 Answers2

1

From what I see the names of your config parts are misleading (furthermore, I can say that the Debian tradition of splitting one decent config file to over 9000 includes is misleading and counter-productive in general).

Considering this:

view clauses are processed in the order in which they appear in the named.conf file.
Thus, in the example above the 'badguys' view clause matching condition (any) also 
satisfies the 'trusted' view matching condition. However, since 'trusted' appears first
its matching condition is the first to be satisfied and view matching stops.

I can say that your global_view is processed first, thus your local clients are matching it. Move the include "/etc/bind/zones.rfc1918"; (and yes, this is the misleading name include) after a local_view view.

drookie
  • 8,625
  • 1
  • 19
  • 29
  • Well, that did the trick, didn't knew that `views`/`zones` declaration order matters. Thanks a lot! – Neurotransmitter Feb 04 '15 at 14:48
  • 1
    While changing the order of the views fixes one aspect of the problem there's still a fundamental problem remaining: There are three views, two of which have no `match-*` directives meaning that regardless how these are ordered there is at least one view that can never be hit. Needless to say the Debian default config does not use of views at all and wrapping the contents of each of their files in a view of its own does not seem like a reasonable way of introducing views to their config. – Håkan Lindqvist Feb 04 '15 at 19:13
1

It's important to understand that each query will hit exactly one view and that is the first view matching the incoming query (based on match-*).

You have three views, two of which have no requirements at all as to which queries will match.

This results in a situation where depending on how the views are ordered either one or two views cannot ever be queried by anyone.

If either your default_view or your global_view views are first in order, then all queries will enter that view, leaving the remaining two views unreachable.

If your local_view view is first then addresses not matching match-clients { localhost_acl; internal_10_acl; }; can query the first of default_view or global_view but the last view remains unreachable.

Another aspect of this is that in this last example, queries that do match local_view will not see any of the zones in the other views, even though those have no particular requirements on the query.


All in all, your introduction of views into this distro-provided default configuration should really not be done on a "one view per file" basis but instead with the above in mind.

Håkan Lindqvist
  • 35,011
  • 5
  • 69
  • 94
  • Thank you for your explanation, Hakan. In my case, however the caveats which you pointed me to are not really relevant, because only root and local users are allowed to use DNS-server and only `local_view` view and its `myho.st` zone will be hit ever. So, if I follow your logic properly, I can even delete all other views and their underlying zones in their entirety and this will not affect the name resolution at all. – Neurotransmitter Feb 04 '15 at 20:54
  • Thinking about it more, I decided to include the zones within the unhittable views (`default_view` and `global_view`) into my custom views in the named.conf.local. I didn't managed to do this gracefully using `include` directive (named-checkconf reports `<...> all zones must be in views` error, even if I include zones in a view; probably should bugreport this), so I ended up just copypasting all the zones to all of my three views, which are actually used (in the original question I simplified things and mentioned only one). The resulting `named.conf.local` is http://pastebin.com/VF3Y7xL5 – Neurotransmitter Feb 05 '15 at 08:19
  • @TranslucentCloud Are you positive that you didn't have some additional `include` directive for one of these files in the global context? Do start reading in `named.conf` as that's the only file `named` actually knows about, anything put in a separate file must be referenced with `include` for it to find it. `named-checkconf -p` may be helpful to get the complete picture (prints the full config as named would read it). – Håkan Lindqvist Feb 05 '15 at 08:55
  • Nope, no extra `include`s anywhere. And all is working good. Take a look at the output of `named-checkconf -p`, if you would like — http://pastebin.com/2pzzciS2 – Neurotransmitter Feb 05 '15 at 11:19