System Administration 2017/18 spring

Lab 6: Understanding .est Zone forwarding

NB! You have a 60GB storage limit in ETAIS therefore dont forget to delete your backups before creating new ones.

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, let's say mail.teacher.est bind9 will still try to rely on recursion.
  • The teacher .est domain is not defined in any local Zones
  • bind9 thinks it is then teacher.est should be world-wide one and starts recursive query (finding .est first then .teacher.est using world-wide TLDs)
  • The point is: none of the world-wide TLDs knows aboy .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 172.17.64.203. 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 mail.teacher.est it will give 172.17.65.162.

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13579
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;teacher.est.			IN	A

;; ANSWER SECTION:
teacher.est.		10	IN	A	172.17.65.162

;; AUTHORITY SECTION:
teacher.est.		900	IN	NS	nsdom5.est.

;; ADDITIONAL SECTION:
nsdom5.est.		900	IN	A	172.17.65.162

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 172.17.64.203 and avoid doing recursive query relying on standard TLDs. The 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.

Undestanding DNSSEC

An further important step is to enforce the DNSSEC feature, otherwise forward queries will not work and here is explanation. The forward query resolving is not happening in our local bind9 setup as opposed to recursive queries. In case of forwarding the query is delegated to 172.17.64.203 machine in our case and then 172.17.64.203 is resolving the query relying on his Zone definitions or using the recursion. When delegating the query-resolving somewhere outside our local bind9 setup we need obviously ensure the endpoint is trusted, and here the DNSSEC feature is useful. Without it there is no way to guarantee that the 172.17.64.203 IP is having Name Service which is not compromised. Imagine scenario:

• first day: we did setup our local bind9 to relay on 172.17.64.203 when resolving .est and we assumed 172.17.64.203 is trusted
• the next day the IP 172.17.64.203 is assigned to different machine running compromised Name Service software
• how do we understand the fact of changed software serving port 53 on 172.17.64.203
  • original DNS protocol do no include any features to validate the endpoints

Therefore by default bind9 does not allow the query forwarding if the DNSSEC is not explicitly enabled. If you try resolving some host from .est domain which is not our own sub-domain of .est - this will evolve forwarding the query to 172.17.64.203 (according to our configuration). The answer will be however SERVFAIL, and this OK default behavior of bind9 according to documentation:

...
 Any tampering with DNS replies would be replaced with a SERVFAIL reply by an intermediate resolver or detected by the resolver on the user's local machine. 
...

Server:		127.0.0.1
Address:	127.0.0.1#53

** server can't find mail.teacher.est: SERVFAIL

There are number of options that affect the DNSSEC features in bind9 configuration. The default one we have in the options configuration file /etc/bind/named.conf.options :

• dnssec-enable possible: yes, no (default)
• dnssec-validation possible values: yes, no, auto (default)

In oder to enforce DNSSEC the options shall be set to yes. The details and explanations of DNSSEC options is well documented here

Now everything related to forwarding .est zone should be configured.

If bind9 restart successfully, you may check if the forwarding now working. The previously failing query mail.teacher.est should now give 172.17.65.162 in response.

Server:		127.0.0.1
Address:	127.0.0.1#53

Non-authoritative answer:
Name:	mail.teacher.est
Address: 172.17.65.162

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

Seriously, there is no reason to overload the TLD root servers with non-sense queries as 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 your 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
• domain - Local Domain Name
• 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/2018/sa/spring/Main/DNS#DHCPconf

domain <yourdomain>.est
search <yourdomain>.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:

OK for educational purposes lets now brake the configuration so you see what happens if you would have not changed domain and search parameters in previous lab.

Now the OS should also be able to resolver 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 ).

Now in the world_resolver we match any clients and any destinations

If everything was configured properly both local_resolver and world_resolver should now serve Zone yourdomain.est, which should be observable from the bind9 logs. Example of the log file for teacher.est domain:

...
11-Apr-2016 17:50:03.593 general: info: zone teacher.est/IN/world_resolver: loaded serial 2015040602
...
11-Apr-2016 17:50:03.606 general: info: zone teacher.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 rsolver

If everything works as expected - the DNS service is ready to be exposed to LAB network. Yes, it is no yet available in LAB network - our firewall does not have the corresponding rule added.

Enable Firewall and final testing.

In cloud environment our VM is protected by 2 different Firewalls:

1. Firewall in Debian
2. NAT router acting as Firewall in cloud infrastructure

Open debian Firewall ports

Enable traffic through in NAT

Network address translation (NAT) is a method of remapping one IP address space into another by modifying network address information in IP header of packets while they are in transit across a traffic routing device. The technique was originally used as a shortcut to avoid the need to readdress every host when a network was moved. It has become a popular and essential tool in conserving global address space in the face of IPv4 address exhaustion. One Internet-routable IP address of a NAT gateway can be used for an entire private network. https://en.wikipedia.org/wiki/Network_address_translation

Our Cloud environment is actively remapping 172.17.64.A IP range to 192.168.42.B and more precisely we use one-to-one NAT or basic NAT.

Now we need to allow traffic through your NAT router in cloud environment. It can be done by something called security groups.

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

Correct answer from custom DNS server in Windows