Institute of Computer Science
  1. Courses
  2. 2018/19 spring
  3. System Administration (LTAT.06.003)
ET
Log in

System Administration 2018/19 spring

  • Home
  • Video Lectures
  • Practicals
  • Exam
  • Grades?
  • References

Lab 5. Make sure you did finish all the tasks of the previous week.

PS! Before continuing please make sure you have completed all previous labs.

This means your Virtual Machine is in System Administration course cluster and accessible over SSH and VPN connection.

  1. /etc/hostname file has your hostname in FQDN format <host>.est
    • <host> refers the host name of your VM that was chosen chosen during VM setup dialog in ETAIS web interface
  2. You can access your Virtual Machine over SSH with Putty or any other SSH client
  3. You can access your Virtual Machine with an SSH key over SSH
  4. Service bind is running and enabled systemctl status bind9.service -l
  5. Local DNS resolver is capable of resolving world addresses
    • dig @127.0.0.1 www.ut.ee
    • dig @127.0.0.1 www.google.com
  6. The DHCP client omits DNS related options
  7. /etc/resolv.conf has a line nameserver 127.0.0.1
    • /etc/resolv.conf is not getting rewritten after next reboot
  8. The OS can use the local DNS resolver to resolve any DNS host name
    • nslookup www.ut.ee
    • nslookup www.google.com

1.Backup the VM

As usual, we do backup before we start with alternating the configuration of the VM!

Here we assume you know how to do the backup using ETAIS web interfaces (as we did it during the last lab).

NB! Please delete the last backup, as you can only keep 1!

2.Check for updates

Before continuing with the lab, it's almost always a good thing to check for updates and install them.

Here we assume you are already familiar with the routines of check for updates and upgrade (we did this during the last lab).

3.Setting up <vm-name>.est personal domains

During the creation of the VM's we gave them a public IP address of 193.40.154.XXX , and we are able to access these machines using the IP address and an SSH client. Now we would like to refer to our machines by using a domain name, for an example:

  • vm.student-test.est
  • mail.student-test.est
  • www.student-test.est

We do not have an .est TLD in the world, so this will work perfectly for in-lab testing and practicing.

  • If we check its existence using nslookup est on our local dns server the answer is: 
Server:		127.0.0.1
Address:	127.0.0.1#53

** server can't find est: NXDOMAIN
  • And extended answer using dig @8.8.8.8 est NS (8.8.8.8 denotes one of the public accessible DNS resolvers provided by Google) 
; <<>> DiG 9.10.3-P4-Debian <<>> @8.8.8.8 est NS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 39128
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;est. IN NS

;; AUTHORITY SECTION:
. 86395 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2018031200 1800 900 604800 86400

;; Query time: 24 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon Mar 12 15:43:23 UTC 2018
;; MSG SIZE rcvd: 107

As you can see in the authority section, server responsible for the root zone answered NXDOMAIN (non-existant domain) for our query. For .est to become a valid TLD, we would have to submit it to the teams responsible for all the root DNS servers, which is time consuming and costly. In our lab network (193.40.154.XXX) we agree that we will have our own TLD which will be responsible for est domain. The TLD will be however only accessible from the lab network (eduroam Wi-Fi, class 123 Wi-Fi or UT VPN), and will not be resolvable from the world.

Next, each student should configure his(her) bind9 server to host a personal domain. For example if the VM name of your machine would be student-test and my corresponding address VM IP - 172.17.64.a, then the est TLD nameserver should have the following records pointing to sub-domain student-test.est : 

student-test.est. IN NS ns.student-test.est.
ns.student-test.est. IN A 172.17.64.a

Which means in case TLD will receive query regarding student-test.est domain, it should answer contact 172.17.64.a with all the queries related to student-test.est domain. The DNS server behind 172.17.64.a holds the actual zone data regarding the student-test.est domain: 

...
www.student-test.est. IN A 172.17.64.a
mail.student-test.est. IN A 172.17.64.a
...

Configuring the local-resolver

We have already setup the bind9 DNS server to act as local recursive resolver, we however did not yet add any configuration regarding our own personal domains. First we configure it locally, to be able to resolve queries regarding our personal domains. If it works, will also add world resolver (next lab) - so the other hosts in the lab network could refer to our resolver, not only our own VM.

As we are about to deploy two different DNS resolvers on the same DNS server (local one and world one) - bind9 suggests isolating the features of each particular one. Therefore we will first configure the view called local_resolver. Next we refer to bind9 configuration file names, make sure you remember them:

In the /etc/bind/named.conf.local local definitions file:

  • Add the following view declaration: 
view local_resolver {

};
  • Save and close the file

This will be our local resolver definition, which is currently empty. First of all we want to isolate in local_resolver our existing configuration (which we added during previous week). Without using views - there is only one resolver possible in bind9.

During the previous lab we did add the white-list of local clients from 127.0.0.0/8 and we called it goodclients. We leave the definition of goodclients as it is in the options file. We however have also declared that only goodclients are allowed to make queries: 

allow-query { goodclients; };

... now this line has to be moved to the corresponding view local_resolver that we have just created.

Find the configuration line:

  • allow-query { goodclients; };
    • Remember which file was it in ?
  • Move this line into newly created local_resolver configuration block
  • Make sure no other configuration files do contain those line but the local_resolver

In addition, we configured recursive resolver in the previous lab, hence the line: 

recursion yes;

... and this one we also want to isolate for the local_resolver.

Find the configuration line:

  • recursion yes;
    • Remember what file was it in ?
  • Move this line into newly created local_resolver
  • Make sure no other configuration files do contain those line but the local_resolver

Now let's try to check if the configuration is OK:

  • What command did we use for checking the bind9 configuration ?
  • Surely you remember it (HINT: into a bash terminal type named and press TAB twice), anyway you might expect an output like this: 
/etc/bind/named.conf.default-zones:2: when using 'view' statements, all zones must be in views

As the output says, we switched to use views and we should isolate all our zone declarations inside the views. We however did not yet configure any zones, and in fact the bind9 complains about the default zones specified in the file: 

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

The main configuration file named.conf is where bind9 starts looking for it's configuration. We could keep all of our modifications in the same config, but this usually gets complicated to read quite fast. For this reason we use the include statements to split configuration across multiple files. Now we look for the default-zone reference starting in our main configuration file. 

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

Now it becomes obvious we have to move the last include declaration inside the view local_resolver we have created:

In main configuration file find the inclusion line: 

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

... and move it inside the local_resolver definition

Now let's check once again if the bind9 configuration is OK

If no error was reported restart the bind9 service

  • systemctl restart bind9.service
  • systemctl status bind9.service -l

Try testing if the recursive-resolver feature is functional, make some DNS queries in your VM.

  • What commands would we use for that ?

Adding zone definition to the local resolver

Creating a new zone is a two step process:

  • First, the records for the zone must be entered into the zone file
  • Second, the zone must be described/declared in the named.conf.local file.

Understanding the zone record files

The typical Zone file contains information about associations between host names and IP addresses within the domain of responsibility. The records inside the Zone file can be of different types:

  • SOA - Start of Authority. Defines the zone name, an e-mail contact and various time and refresh values applicable to the zone.
  • A - IPv4 Address record. An IPv4 address for a host.
  • AAAA - IPv6 Address record. An IPv6 address for a host. Current IETF recommendation for IPv6 forward-mapped zones.
  • NS - Name Server. Defines the authoritative name server(s) for the domain (defined by the SOA record) or the sub-domain.
  • MX - Mail Exchange. A preference value and the host name for a mail server/exchange that will service this zone. RFC 974 defines valid names.
  • PTR - IP address (IPv4 or IPv6) to host. Used in reverse maps.
  • CNAME - Canonical Name. An alias name for a host. Causes redirection for a single RR at the owner-name.

More details about record types you can find here.

Example Zone file content looks as follows:

NB! In Zone file ; denotes comments in configuration 

;
; Zone file for domain-example.org
$ORIGIN domain-example.org.  ; Zone starting point in the name-space tree
                     ; (if skipped - the origin is inferred by the DNS server based on
                     ; zone declaration in name.conf.local file
$TTL 15M             ; Default expiration time for all resources
@ IN SOA ns.domain-example.org. root.domain-example.org.(
	 2012020101       ; Serial
		15M       ; Refresh (15 minutes)
		5M        ; Retry (5 minutes)
		604800    ; Expire (7 days in seconds)
		600 )     ; Negative Cache TTL
@       IN      NS      ns            ; name server for domain-example.org
@       IN      A       172.17.6.1    ; IPv4 address for domain-example.org
ns      IN      A       172.17.6.1    ; IPv4 address for ns.domain-example.org
@       IN      MX  10  mail          ; mail server for domain-example.org
myhost  IN      A       172.17.6.5    ; IPv4 address for myhost.domain-example.org
mail    IN      A       172.17.6.6    ; IPv4 address for mail.domain-example.org
myhost2 IN      A       172.17.6.7    ; IPv4 address for myhost2.domain-example.org
www     IN      CNAME   myhost        ; www is an alias for myhost in domain-example.org
ftp     IN      CNAME   myhost        ; ftp is an alias for myhost in domain-example.org
www.other-domain.org. IN A 192.168.1.11 ;  www.other-domain.org. is outside of domain-example.org
                                      ; and therefore needs to be declared using FQDN

The syntax explained here:

  • ; - Comment, disabled line
  • $ORIGIN - Zone starting point in the name-space tree, (if skipped - the origin is inferred by the DNS server based on zone declaration in name.conf.local file
  • $TTL - Default expiration time for all resources (cache time, specified in seconds)
    • (alternatively M, H might be appended to denote minutes or hours)
  • @ IN SOA ns.domain-example.org. root.domain-example.org.( 2012020101 15M 5M 604800 600) :
    • @ - Will be expanded to $ORIGIN if specified or assigned by DNS server
      • (in current example to domain-example.org)
    • IN - Protocol family:
      • IN - Internet protocol (IP)
      • HS and CH - historic MIT protocols from the times there was DNS but there was no IP
    • SOA - Zone authority info:
    • ns.domain-example.org - Address of name-server
    • root.domain-example.org - Will be expanded to root@domain-example.org and will correspond to email address of DNS master in the domain-example.org
    • 2012020101 - Serial Number (as specified here):
      • Unsigned 32 bit value in range 1 to 4294967295 with a maximum increment of 2147483647. In BIND implementations this is defined to be a 10 digit field. This value MUST increment when any resource record in the zone file is updated. A slave (Secondary) DNS server will read the master DNS SOA record periodically, either on expiry of refresh (defined below) or when it receives a NOTIFY and compares, arithmetically, its current value of sn with that received from the master. If the sn value from the master is arithmetically HIGHER than that currently stored by the slave then a zone transfer (AXFR/IXFR) is initiated by the slave. If the value of sn from the master DNS SOA is the same or LOWER then no zone transfer is initiated.
      • The convention is to use a date based sn value to simplify the task of incrementing the sn - the most popular convention being yyyymmddss where yyyy = year, mm = month and dd = day ss = a sequence number in case you update it more than once in the day!

As you can see after declaring SOA Zone authority, the actual Zone related data is added: the zone records:

  • <name> <ttl> <class> <type> <data>
    • name record name
    • ttl time to live in seconds, how long cache lives, if skipped $TTL variable is used.
    • class record class, the protocol family (in modern world only IN remains)
    • type record type
    • data type related value of the record

Record name can be one of three:

  • Short host name (inside current domain), like ns or mail , which will be then automatically extended to ns.domain-example.org and mail.domain-example.org .
  • FQDN (Fully-Qualified Domain Name), like www.otherd-domain.org.
    • '''In this case we have to terminate FQDN with . in order to avoid auto-expansion to www.otherd-domain.org.domain-example.org
  • @ sign which will be expanded to domain-example.org denoting the domain itself.

Understanding how the Zone files are included into bind9 configuration

Referring to the configuration files of the bind9 server, the obvious one to configure local Zones in is the local configuration file. We did modify it already to add the local_resolver configuration. The same file is used to add the zone related configuration. Very similar to how we did declare the view clause we may declare the zone clauses: 

zone "domain-example.org" {
    file "/etc/bind/zones/domain-example.org.zone";
    type master;
    allow-update { none; };
};

... and similar to view clause we may have a number of options available for the zone clause, the full list of options is available here, we however will cover the most important ones:

  • file - absolute path to Zone file (the one containing SOA and other records).
  • type - dependent on configuration, may have the following values
    • In our lab-setup we will mostly use the master type.
  • allow-update - hosts that are allowed to submit dynamic updates for master zones, and thus this statement enables Dynamic DNS. If omitted the DDNS is disabled by default.

Creating Zone file and adding configuration for personal domain

First let's create the directory zones inside the bind configuration directory.

  • What was its absolute path ?
  • HINT: you can use pwd (print working directory) to check your working directory.

Next let's assign it properly to be owned by bind group

  • What was the command we have to use ?
  • HINT: Shorthandle for change ownership

Make sure the zones directory is only accessible to bind and root users.

  • Random user in the system should not be able to access this directory.

In addition make sure all the files we create in zones directory are also automatically assigned to bind group:

  • setuid and setgid bits can be added with the chmod command, using u+s and g+s respectively.
  • Further reading on special permissions here

Make sure you have executable bit set on the zones folder, otherwise bind user will be unable to traverse that folder.

After you managed to prepare the zones directory properly, you may create the zone file in it, but first let's make sure you know your domain:

Personal student domain is a sub-domain of est zone and has your VM's name as the domain name; therefore, if my VM's name is student-test , then my domain would be student-test.est

Here we assume you got your domain name correctly and we proceed with Zone file creation:

Create the file:

  • <student_zone>.zone in the zones directory
    • here <student_zone> is your domain name
    • example: if my domain name is student-test.est then the file is student-test.est.zone
  • If you setup the zones directory properly, it should be automatically assigned to bind group, and if not, please make sure you did assigned the ownership and permissions properly to the zones directory.

If the file was created properly you may edit the zone and add the bare minimal amount of zone records to your zone file.

Edit the zone file you have just created, add following:

  • Default time-to-live value of 15 minutes
  • SOA Authority record of your domain
    • having ns1.<your_domain>. as the name server
    • having root.<your_domain>. as the email of DNS master
    • having serial properly specified
    • having refresh interval of 15 minutes
    • having retry interval of 5 minutes
    • having expiry interval 2 hours
    • having negative cache TTL 600 seconds
  • NS record of your domain pointing to host ns1 in your domain
  • A records:
    • ns1 pointing to your External IP address
    • <your_domain> pointing to your External IP address
    • <your_hostname> pointing to your External IP address

Example file of ours /etc/bind/zones/student-test.est.zone , domain student-test.est and IP 172.17.64.a : 

;
; BIND data file for local zone student-test.est;
$TTL    15M
@       IN      SOA     ns1.student-test.est. root.student-test.est. (
                     2012020201         ; Serial
                            15M         ; Refresh
                             5M         ; Retry
                           120M         ; Expire
                            600 )       ; Negative Cache TTL
@              IN      NS      ns1
@              IN      A       172.17.64.a
ns1            IN      A       172.17.64.a
student-test   IN      A       172.17.64.a

If you did edit the file properly the following command may be used to test if the Zone file is valid

  • # named-checkzone <your_domain> /etc/bind/zones/<your_domain>.zone
    • here <your_domain> is your personal domain name

If command reports no error, the Zone file is correct

If the zone file is correct we may add the defined zone into bind configuration.

Edit the bind local configuration, the one containing the declared local_view .

  • In local_view add new zone clause
    • having zone name set to your personal domain
    • pointing to the previously defined
    • having type master

In our examples we made it as follows: 

...
view local_resolver {
  allow-query { goodclients; };  
  recursion yes;

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

  zone "student-test.est" {
        type master;
        file "/etc/bind/zones/student-test.est.zone";
  };
};

After editing configuration, do not forget to check if it is valid, using named-checkconf command

If the configuration is OK:

  • Restart the bind9 service
  • Make sure it did load the new zone (check the bind9 log file)
    • /var/log/bind9/bind.log

The log has to have line like: 

...
28-Mar-2016 19:52:53.204 general: info: zone student-test.est/IN/local_resolver: loaded serial 
...

Afterwards you should be able to use dig or nslookup commands for testing:

  • $ dig @127.0.0.1 <your_domain>
  • $ dig @127.0.0.1 ns1.<your_domain>
  • $ dig @127.0.0.1 <your_host>.<your_domain>
  • $ dig @127.0.0.1 <your_domain> NS

The dig should show result properly:

Example dig result of the command:

  • dig @127.0.0.1 student-test.est 
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17432
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2

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

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

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

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

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Apr 04 18:01:59 EEST 2016
;; MSG SIZE  rcvd: 88

Understanding reverse mapping Zone files

The interesting fact about records in Zone file configurations:

  • all the associations are unidirectional

which means if we have

  • ns1.example.org. A IN 10.10.10.5

it is equivalent to the link

  • ns1.example.org. -> 10.10.10.5

and not opposite way around:

  • 10.10.10.5 -> ns1.example.org.

The secondary link from IP to the host name has to be added by introducing the PTR records. The PTR records are organized and collected in separate Zone file called Reverse Mapped Zone.

Why can't we just put PTRs in same Zone file we created in previous tasks?

You already know the DNS name space is organized in hierarchical structure:

The whole domain name space is first addressed from root(.) which is the root of the whole DNS tree, then it's divided across number of TLDs, like .com, .org, .net etc. You can check the full list of TLDs here. Next, each TLD has a number of sub-domain and for us we did introduce additional TLD .est with sub-domains for each student. Following the divide and conquer idea each of the sub-domains can further be divided in sub-domains (each student can potentially create an infinite amount of sub-domains).

Considering the TLDs once again there is one specific: .arpa which currently isn't serving any of the domains, but is holding routing and addressing parameters and is therefore called Infrastructure TLD.

  • The DNS architecture was designed by US Advanced Research Project Agency (ARPA)
  • .arpa was originally domain name of the ARPA agency, and it was the first domain introduce in DNS name space.
  • as it turned to be Infra-TLD the .arpa is referred as Addressing and Routing Parameter Area.

The idea behind .arpa Infra-TLD is to provide reverse mappings (from IP to host name), and is mainly used by humans for such things as tracking where a web-site visitor came from, or where an e-mail message originated etc.

However reverse DNS is important for one particular application. Many e-mail servers on the Internet are configured to reject incoming e-mails from any IP address which does not have reverse DNS. So if you run your own e-mail server, reverse DNS must exist for the IP address that outgoing e-mail is sent from. Reverse DNS mappings are also an important part of keeping the trust-based DNS working. A simple check any service provider can run is looking for mismatches in PTR and A type records, and usually if these don't match data is marked as spam.

The IPv4 address space is of course not infinite but the idea of hierarchy is followable if we consider how the IPv4 space is divided into subnets. Each organization is assigned with a big subnet (A class or B class dependent on the size of the organization). Dependent on the inner structure of the organization the big subnet can be divided again and again till there are free unused IPv4 addresses.

As you can see, the bigger subnets can still be broken into smaller ones, the simple example is explained here (if you struggle understanding concepts of IP addressing you may first read the IP Basics). Now, taking this into account, all of the IP address space was structured and reduced into reverse mapping Zones under the .arpa TLD. Therefore the .arpa is broken into sub-domains as follows:

  • in-addr.arpa domain contains all the reverse mappings for IPv4 address space (in-addr stands for Internet Address)
  • in-ip6.arpa domain contains all the reverse mappings for IPv6 address space

Now each of them is broken down into sub-domains denoting subnets of IPv4 or IPv6. The domain name for the subnet is then constructed as follows:

  • For the IPv4 subnet:
    • Consider your subnet (for example you have 172.17.6.0/24)
    • The non-changeable part is 172.17.6. (by subnet 172.17.6.0) and only the last octet can change (by netmask 255.255.255.0)
    • Non-changeable part is then reversed (so we get 6.17.172)
    • in-addr.arpa is appended to the reversed subnet (we get 6.17.172.in-addr.arpa)
    • 6.17.172.in-addr.arpa is then our domain for reverse mapping:
      • This will be the $ORIGIN for the reverse mapping Zone file
  • For the IPv6 subnet:
    • ... to be added ...

Now the reverse mapping Zone files are similar to regular Zone files, here is an example: 

$ORIGIN 6.17.172.in-addr.arpa.   ; Zone starting point in the name-space tree
                     ; (if skipped - the origin is inferred by the DNS server based on
                     ; zone declaration in name.conf.local file
$TTL 15M             ; Default expiration time for all resources
@ IN SOA ns.domain-example.org. root.domain-example.org.(
	 2012020101       ; Serial
		15M       ; Refresh (15 minutes)
		5M        ; Retry (5 minutes)
		604800    ; Expire (7 days in seconds)
		600 )     ; Negative Cache TTL
@              IN      NS      ns.domain-example.org.       ; Name Server for domain-example.org
1             IN      PTR     ns.domain-example.org.       ; 172.17.6.1 has name ns.domain-example.org
5             IN      PTR     myhost.domain-example.org.   ; 172.17.6.5 has name myhost.domain-example.org
6             IN      PTR     mail.domain-example.org.     ; 172.17.6.6 has name mail.domain-example.org
7             IN      PTR     myhost2.domain-example.org.  ; 172.17.6.7 has name myhost2.domain-example.org

As you can see there is not much changed in the headers:

  • $ORIGIN - pointing to 1.168.192.in-addr.arpa
    • we can omit specifying origin, leaving it for bind9 to specify it (inferring named.conf.local configurations
  • TTL and SOA records remain the same as in regular Zone file (we are still in domain-example.org)
  • NS record is the same (we are still having DNS server's FDQN: ns.domain-example.org.)
  • Next we have the PTR record for each A or AAAA type of records from the regular Zone file of our domain
    • Each host name -> IP association should have a reverse association IP -> host name.

Please note, that it is possible to specify multiple A or AAAA types of record pointing to the same IP address, however in reverse mapping only one of the host names may be pointed by the PTR type of record. For example, in the regular Zone file we have: 

@       IN      A       172.17.6.1    ; IPv4 address for domain-example.org
ns      IN      A       172.17.6.1    ; IPv4 address for ns.domain-example.org

Both domain-example.org and ns.domain-example.org are having the A type of record pointing to the same IP of 172.17.6.1. In the reverse mappings however we have only one record: 

1             IN      PTR     ns.domain-example.org.

... saying 172.17.6.1 has name ns.domain-example.org

The content of reverse mapping Zone file is then stored similar to regular Zone:

  • Zone example-domain.org was stored in file example-domain.org.zone
  • Zone 6.17.172.in-addr.arpa should be stored in file 6.17.172.in-addr.arpa.zone

The file name convention is not important to follow (you can use other names if you wish), the idea of this convention is to keep named.conf.local configuration file more clear and followable.

The last thing to understand is how the reverse mapping Zone file is embedded into existing bind9 configuration, and this is fact 1-to-1 similar to how we declared the regular Zone in bind9 configuration (we have to add another zone clause in the local configuration file):

  • We cannot reuse existing zone clause domain-example.org for the reversed one 6.17.172.in-addr.arpa

Can you now explain why ? If you struggle with an answer think about the following: What is the $ORIGIN variable? How is it assigned? How is it related to domain name? How does the DNS name space look like? What is TLD? What is Infrastructure TLD? Which part of DNS name space is responsible for direct lookup queries? Which part of DNS name space is responsible for reverse lookup queries?

After answering those questions it should be clear - the reverse mappings we can only specify under .arpa infrastructure TLD; which separate branch of DNS name space (not overlapping with .org TLD). Therefore the $ORIGIN is different too, and has to be declared separately.

Declaring the zone clause for reverse mapping Zone is then looking like: 

zone "6.17.172.in-addr.arpa" {
    file "/etc/bind/zones/6.17.172.in-addr.arpa.zone";
    type master;
    allow-update { none; };
};

Is it by the way important to specify

  • allow-update { none; };

After the reverse mapping Zone file is included in bind configuration, the standard check-routines should follow:

  • Checking the reverse mapping Zone file:
    • named-checkzone ''6.17.172.in-addr.arpa'' <path to 6.17.172.in-addr.arpa.zone file>
  • Checking the bind9 configuration using named-checkconf command

Now we are ready to add the reverse mapping Zone to our bind9 configuration for our network and to populate it with PTR records.

Create the reverse mapping Zone file for 172.17.64.X/24 or 193.40.154.X/24 (depending which external-IP you have):

  • use the same $TTL and $SOA as in the regular Zone file you created for your domain
  • add the required PTR records
    • if you do not know what to add, please refer to the Understanding reverse mapping Zone files'
  • save the reverse mapping file
    • into the same directory as the regular Zone file you created for your domain
    • select the proper file name, try to follow the conventions we have explained
    • make sure the Zone file has proper ownership and permissions
  • check the Zone file using named-checkzone command
    • the example was given before

If the reverse mapping Zone is OK, construct the reverse mapping domain name:

  • The example how to get reverse domain name from IPv4 subnet was given before

If you have calculated the reverse mapping name for your subnet:

Edit the bind9 local configuration file:

  • find the proper place to add new zone clause
  • add new zone clause having:
    • zone name properly assigned with reverse mapping domain name you have calculated
    • file - assigned with absolute path of the corresponding file containing reverse mappings
    • type - assigned to master
  • save the configuration file

Check the configuration using corresponding command

If the configuration is OK:

Restart the DNS service

Check if reverse mapping is working properly using the following command:

  • host <your external-IP address>
  • nslookup <your external-IP address>
    • It should give you back the FQDN you assigned to IP address
  • Institute of Computer Science
  • Faculty of Science and Technology
  • University of Tartu
In case of technical problems or questions write to:

Contact the course organizers with the organizational and course content questions.
The proprietary copyrights of educational materials belong to the University of Tartu. The use of educational materials is permitted for the purposes and under the conditions provided for in the copyright law for the free use of a work. When using educational materials, the user is obligated to give credit to the author of the educational materials.
The use of educational materials for other purposes is allowed only with the prior written consent of the University of Tartu.
Terms of use for the Courses environment