Süsteemihaldus 2018/19 kevad

Lab 6: Understanding .est Zone forwarding

Up to now we have configured our bind9 to contain:

• Local resolver (serving only localhost 127.0.0.0/8) and it has:
  • Recursive resolver (for resolving world-wide addresses)
    • relying on TLD information available in default bind9 configuration
  • Regular Zone for resolving addresses in personal domain
  • Reverse Mapping Zone for resolving IP in LAB subnet

What happening in fact is:

• when resolving the personal domain (sub-domain in .est) - the local Zone definition is used
• when resolving world wide address, let's say www.ut.ee the recursive resolving is used (finding first .ee then .ut.ee then www.ut.ee using world-wide TLDs)
• when resolving address in a sub-domain of .est, bind9 will still try to rely on recursion.
  • The .est domain is not defined in any local Zones
  • bind9 thinks student-test.est should be world-wide one and starts recursive query (finding .est first then student-test.est using world-wide TLDs)
  • The point is: none of the world-wide TLDs knows about .est - it's inexistent world-wide

We have agreed in the LAB network we use .est as our TLD which is configured on LAB DNS server on Host: scoring.sa.cs.ut.ee | IP: 193.40.154.247 . This one contains the Zone file containing all the information about the student personal domains inside our lab network.

If you check if he can resolve testing.student-test.est it will give 172.17.65.234.

; <<>> DiG 9.10.3-P4-Debian <<>> @193.40.154.247 testing.student-test.est
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1422
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;testing.student-test.est.      IN      A

;; ANSWER SECTION:
testing.student-test.est. 900   IN      A       172.17.64.234

;; AUTHORITY SECTION:
student-test.est.       900     IN      NS      ns1.student-test.est.

;; ADDITIONAL SECTION:
ns1.student-test.est.   900     IN      A       172.17.64.234

;; Query time: 9 msec
;; SERVER: 193.40.154.247#53(193.40.154.247)
;; WHEN: Mon Mar 18 11:41:24 UTC 2019
;; MSG SIZE  rcvd: 103

Therefore it would be enough for our local_resolver to know that in case .est query which is not our personal one (defined locally in Zone file) we should refer to 193.40.154.247 and avoid doing recursive query relying on standard TLDs.

This technique is called forwarding and in this case we need to define the zone clause for .est in local_resolver specifying type forward (check the details about zone type forward here). According to documentation regarding type option of the zone clause:

• in case zone type is forward additional options have to be provided:

...
A zone of type forward is simply a way to configure forwarding on a per-domain or per zone basis. To be effective both a forward and forwarders statement should be included. 
...

• So additional options we have to add are:
  • forward option which has only two choices:
    • only - forward only (and not try to user recursion)
    • first - forward once and if not answered try to resolve using recursion
  • forwarders list of IP addresses of the servers to whom to forward the query
    • example: { 8.8.8.8; 7.7.7.7; };

After understanding the idea of forward zone, please, declare the one for .est in your local configuration file of the bind9 service.

Understanding other existing Zone files in bind9 default setup

There are existing zone-data files given in /etc/bind directory, and those are referenced in the /etc/bind/named.conf.default-zones (the one we included in local_resolver):

• db.root
  • Very important zone data file - holds the information on root name servers, thanks to it our local_resolver can do recursive queries ( recursion yes; directive makes sense only if bind9 knows where to find the "." TLD responsible servers).

Now the next 4 files are there because of RFC recommendation. According to RFC1912 (point 4.1):

Certain zones should always be present in nameserver configurations.
...
These are set up to either provide nameservice for "special"
addresses, or to help eliminate accidental queries for broadcast or
local address to be sent off to the root nameservers. 
...

Regarding the localhost address in the context of DNS configuration and RFC1912 recommends:

...
The "localhost" address is a "special" address which always 
refers to the local host. 
...
localhost by itself is used and expected to work in some systems.
Translating 127.0.0.1 into "localhost.dom.ain" can cause some
software to connect back to the loopback interface when it didn't
want to because "localhost" is not equal to "localhost.dom.ain".
...

Therefore we have following zone data files regarding localhost:

• db.local
  • Contains the localhost to IP associations (127.0.0.1 IPv4 and ::1 IPv6). We have the corresponding associations in /etc/hosts file, which is considered before the DNS resolver (from /etc/resolv.conf).
• db.127
  • Reverse associations for localhost (backwards 127.0.0.1 to localhost)

Additionally RFC1912 recommends to kill the queries to broadcast addresses in order to avoid accidental PTR queries on the "." TLD nameservers:

...
to help eliminate accidental queries for broadcast 
or local address to be sent off to the root nameservers.
...
The "255" and "0" files should not contain any additional 
data beyond the NS and SOA records.
...

Therefore there are two files that contain nothing, and are meant just to capture the PTR queries regarding 255.x.x.x and 0.x.x.x addresses:

• db.255 - capturing accidental PTR queries regarding 255.x.x.x addresses
• db.0 - capturing accidental PTR queries regarding 0.x.x.x addresses

As there is no reason to overload the TLD root servers with non-sense queries, because broadcast address is not-unique address anyway.

The only zone data file which is not referenced in /etc/bind/named.conf.default-zones is:

• db.empty

You may find its reference in /etc/bind/zones.rfc1918 configuration file, which we did not include anywhere:

The output should look like:

./named.conf.local:7://include "/etc/bind/zones.rfc1918";

... looks like the inclusion of this file is disabled ?

We know that RFC1912 is recommended to prevent sending the non-sense PTR queries to TLD root servers, and it is fulfilled in previously described zone files (db.0, db.255, db.127). Looks like there is another recommendation RFC1918 which is about the private subnets:

...
The Internet Assigned Numbers Authority (IANA) has reserved the
following three blocks of the IP address space for private internets:

     10.0.0.0        -   10.255.255.255  (10/8 prefix)
     172.16.0.0      -   172.31.255.255  (172.16/12 prefix)
     192.168.0.0     -   192.168.255.255 (192.168/16 prefix)
...

And the question is ''shall we also exclude PTR queries regarding these addresses from being sent to TLD root servers ? The answer is you should only serve PTR queries of the corresponding subnetwork that you are using and kill all the rest by serving empty zones. And this is exactly what the /etc/bind/zones.rfc1918 configuration file is for: it associates an empty zone to IP address ranges of private networks:

...
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 "168.192.in-addr.arpa" { type master; file "/etc/bind/db.empty"; };
...

Once included in bind9 configuration, the /etc/bind/zones.rfc1918 included will capture all PTR queries regarding private subnets. The only place where we allow such queries is the VM itself (recursion is only enabled for the queries sent from loopback interface of the VM). Hence the place where to include the /etc/bind/zones.rfc1918 is the local_resolver, moreover an inclusion must appear after the reverse zone declarations. Next lets add enable /etc/bind/zones.rfc1918 inclusion in our configuration. The /etc/bind/zones.rfc1918 file contains everything we need except for one line which we want to exclude:

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

...
// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";
...

Understanding the search keyword of /etc/resolv.conf

As we have configured now the local DNS server, and even featured it with information about personal domains in a fake domain est. We may remove corresponding alias from the /etc/hosts (remember we have added a record regarding our host name and FQDN into /etc/hosts file. We do not need it anymore - the local DNS server (if configured correct) should resolve it for us.

In /etc/resolv.conf file we have a system resolver configuration setup:

...The resolver is a set of routines in the C library that provide access to the Internet Domain Name System (DNS). The resolver configuration file contains information that is read by the resolver routines the first time they are invoked by a process...

More details regarding /etc/resolv.conf you may read using corresponding man command:

• man resolv.conf
• ... or in web browser by opening this link.

Normally in client machine configurations, we have /etc/resolv.conf automatically configured by the DCHP client when joining new network and the following variables are then assigned:

The options we are interested in are:

• nameserver - Name server IP address
• search - Search-list for host name lookup

In some configuration however we use static IP and therefore the /etc/resolv.conf have to edit manually. We did already edit it at least once, putting following line in it in First DNS lab https://courses.cs.ut.ee/2019/sa/spring/Main/DNS#DHCPconf

search est
nameserver 127.0.0.1

In our /etc/hosts file we however did declare an alias for both host name and FQDN, so both yourhostname as well as yourhostname.yourdomain.est are in use. If you check:

Now the OS should also be able to resolve short host names (with no FQDN) in your domain again:

Configuring world resolver

If everything we configured so far for our local resolver works perfectly ?

You may however notice when resolving the other students host name the nslookup command just hangs for awhile and the gives SERVFAIL. This is OK behavior as everything we configured so far regarding the DNS - is isolated inside your own VM (127.0.0.0/8).

In order to make it listening world-wide (all interfaces and all IP addresses that VM currently has) what shall we do ?

Additionally we have local_resolver is set to server local network only:

• allow-query clause is set to white list goodclients which is 127.0.0.0/8 network

Let's now create another resolver calling it world world_resolver and make it serving Zone yourdomain.est to everyone except 127.0.0.0/8 network (all networks except local one). So the world_resolver shall contain only one zone clause and nothing else (no forwarding, no reverses and no recursion).

Now we have 2 resolvers declared local_resolver and world_resolver. Let's make them aware of each other by adding match-clients and match-destinations options into both world_resolver and local_resolver .

By adding them we tell the particular resolver to take actions on the queries that have positive match, and if there is no match then the resolver should skip the query so the next resolver tries to match it. Details about match- options of the view your may read here.

In our setup we have local_resolver the first and world_resolver second, according to local configuration of the bind9 . So we want local_resolver to first match the query ( check if this originates from 127.0.0.0/8 and was sent to port 53 of 127.0.0.1 ).

If everything was configured properly both local_resolver and world_resolver should now serve Zone <vm-name>.est, which should be observable from the bind9 logs. Example of the log file for student-test.est domain:

...
11-Apr-2016 17:50:03.593 general: info: zone student-test.est/IN/world_resolver: loaded serial 2015040602
...
11-Apr-2016 17:50:03.606 general: info: zone student-test.est/IN/local_resolver: loaded serial 2015040602
...

In addition you may test if both world and local resolvers are working properly by resolving hosts in your own domain:

However the recursive queries should only work on local resolver:

Also the est Zone forwarding should only work on local resolver

If everything works as expected - the DNS service is ready to be exposed to LAB network.

Our DNS should work now so we do not need anymore an alias in /etc/hosts file:

Now lets test the configuration from your personal laptop / machine.

Setting Manual DNS in Windows (Use correct names and IP addresses)

Correct answer from custom DNS server in Windows