FreeBSD DNS Servers Part 2

The original Japanese version is available here.

My home is in Osaka, so I often go to Osaka, Kyoto, Kobe, Nara, Wakayama, Fukui, Shiga, Hyogo, Kagawa, and Tokushima for day trips by car. Kyoto City is one of the most frequently visited places, as is Utsubo Park in Osaka. In Kyoto, there are many utility poles buried underground as part of aesthetic measures. In addition, some of the information boards that were originally attached to utility poles, such as road signs, are now on the ground. In towns without power lines, it is pleasant to look up at the sky.

Now, following on from the last article, we will continue with the topic of DNS. Last time we talked about very small set up in the home, but I would like to talk about larger set up at the company level. My company uses ISC BIND918, and we have two DNS servers in each of three data centers in Asia, Europe, and the U.S. We share these DNS servers from each office in the area. ISC BIND918 has a concept “view” and this single “view” works as same as single DNS implementation. When you look at one DNS server, you see one host running DNS, one process, but virtually multiple DNS servers running in separate configurations. A single view contains the entire DNS configuration. A query from a DNS client matching a source IP address defined in a DNS access list will use the configuration of the view whose access list matches the query to construct a response. In this example, we will define a view as a trial. In this example, we will make pokemon a client of view OSAKA and package a client of view SAOPAULO. home.jf3vqb.net DNS resources will be used in common, but other Internet resources used by pokemon in Osaka or package in SaoPaulo can be provided differently. The purpose of the design is to allow pokemon to assemble a response that would be best used in Osaka, and package to assemble a response that would be best used in Sao Paulo. In addition, the MX records for the home.jf3vqb.net domain will be set to pokemon.home.jf3vqb.net, package.home.jf3vqb.net and to dhcp.home.jf3vqb.net in this order in Osaka. In Sao Paulo, set to package.home.jf3vqb.net, pokemon.home.jf3vqb.net and dhcp.home.jf3vqb.net in this order. We would like to keep the definition files for each view as separate files for easier handling. The basic configuration file is named.conf, so if there are other files, we will define them in named.conf. It looks like this. The same basic policy applies to both primary and secondary views.

If you don’t have more than 2 separate configurations, then view is not required.

When using a view, all zone configurations must be defined inside the view, so comment out all zone definitions in named.conf. Or, delete them for easier viewing. We used two files for each view this time. The *-client.conf file defines the DNS clients belonging to the view. Based on our design policy, we chose OSAKA for pokemon and SAOPAULO for package. Incidentally, other machines do not belong to any view, but we will ignore them here. The settings are processed in order from the top, so a Windows PC that does not belong to any view will have no settings to process the query, so the query itself will be rejected. If you want, you should create a view HOME that covers 192.168.0.0/24, and put it at the bottom of the settings, the process order should be like OSAKA -> SAOPAULO -> HOME, and cover all the views except for pokemon and packages, but since the home view is just a test, I will not go too deep into it.

It doesn’t mean it doesn’t like M$ but it means there is no configuration for Windows client. That’s why it was denied 🙂

The *-client.conf file looks like this. Remember, the resolver for each host is set to 127.0.0.1 in the first line. So the loopback address of pokemon must belong to OSAKA. For the same reason, the package loopback must belong to SAOPAULO.

Copy the entire zone definition commented out or removed in the previous step into COMMON.conf so that it can be used with include statements from other files. It may be difficult to understand because I copied everything, comments and all others, but it looks like this

Copied entirely between head and tail commands.

Insert COMMON.conf into the definition files for view OSAKA and SAOPAULO. The view OSAKA is defined in OSAKA.conf and looks like this

As an aside, I think most company networks of a certain size use M$ Windows Active Directory even if they do not want to use it. In that case, I think they define AD servers as conditional forwarders in COMMON.conf and so on. Therefore, I think that there is no zone that is defined as type primary in the BIND918 zone definition. Of course, if there are zones that exist only in bind918, they will be primary. assuming home.jf3vqb.net is the M$ AD domain, it would look like this. According to the BINS918 manual, Forwarders will not be used in a order of written in the configuration but the forwarder with the best response will be used.

DNS dynamic updates are important for Windows networks. In our virtual domain example, all SOA zones and NS records for home.jf3vqb.net point to the Windows domain controller, so the required dynamic updates would be sent to the Windows DC, not to BIND918. The reverse dynamic update, in this example it would be performed to BIND918. However, BIND918 by default does not accept dynamic updates for security reasons. if you want to provide reverse lookups for Windows PCs, you may need to make it accept reverse dynamic updates.

Get back to the original point. Since COMMON.conf is common to all views, we will add the same to SAOPAULO.conf. package has also been rewritten using views, so we will change it in the same way as pokemon. One thing to note is the handling of cache files created in secondary DNS. The primary uses the same file as the database, so the same description can be used in each view. However, in the secondary, data transfer is performed for each view, so if the same file name is used, there is a possibility that the file will be corrupted if it is updated at the same time by bad luck. For this reason, different file names should be used.

The next step is to configure forwarders. view OSAKA needs to create a response that is likely to be the best for DNS clients in Osaka. So the DNS server addresses defined in the forwarders used in view OSAKA should be DNS servers located in the Osaka area. Since many DNS sites these days support GEO-IP, it is necessary to find DNS servers that does not support GEO-IP. Similarly, view SAOPAULO will need to use DNS servers located near SAOPAULO that does not support GEO-IP. Here is a site that can help you with this task. This site provides a list of sites operating as DNS servers in each country, which is updated as needed and can be used as data. However, the sites provided are not necessarily free or unauthorized. Therefore, there is no guarantee that access will not be denied. In such cases, do not use them for forwarders. Here are the sites we have selected.

As the access may be denied, we need to use multiple forwarders. Also we shouldn’t use those addresses if query is denied.

Off topic again, but what is the problem with using a site that supports GEO-IP? Suppose DNS A supporting GEO-IP is located in Korea. If you use this site directly from a DNS client in Japan, it would return DNS records appropriate for use in Japan. This is how GEO-IP works. Let’s say we use this DNS A as a forwarder to our DNS server in Japan. If our server is used by a Korean client, the Korean client will receive DNS records suitable for Japan, meaning DNS records not so suitable for Korea, and the Korean client will have slower network access. This is because the IP addresses accessing DNS A will be Japanese addresses, not Korean addresses. To avoid this situation, it is necessary to use a DNS that does not support GEO-IP for fowarders. We can check if GEO-IP is supported by nslookup easily.This is just an example of how to do it, but query the address outlook.office365.com to the DNS you wrote for in view SAOPAULO’s forwarders.

The M$ data center has the IATA code of a nearby airport as its hostname. I accessed from Japan and it returns CPQ, so I assume this DNS does not support GEO-IP. CPQ is a Brazilian airport. If it supports GEO-IP, it should return ITM-efz.ms-acdc.office.com or at least HND-efz.ms-acdc.office.com. Again, for your information, ITM is for Itami and HND is for Haneda. Let’s move on to the final configuration. First, create MX records as designed in view OSAKA.

We haven’t seen dhcp before. It is very old 32bit physical machine. The pokemon or package were crashed as host Windows OS is rebooted due to Windows Update.

Now we have a problem. I have updated the data in the primary DNS and increase the serial number and then run rndc reload. Then the same changes are transferred to the secondary. But no transfer actually takes place. Why? Actually, the primary/secondary transfer is also affected by the view. We have specified 192.168.0.253 as the address which is allowed to transfer from the primary. This address is defined as the address of SAOPAULO. Therefore, if you want to transfer data from view OSAKA, you need to give the package an address that belongs to view OSAKA and transfer the data from that address. First, let’s start by changing the OS. Assign 192.168.0.252 to pokemon and 192.168.0.251.

A network interface could have multiple IP addresses.

Adapt those settings. A reboot will have the same effect.

Then specify the new IP address in named.conf and restart DNS.

Rebooting is required as bind user doesn’t have enough right to use physical network interface.

Next, modify the access list for each view.

Finally, modify and add the primary address of each view, the allowed forwarding address, and the forwarding source address. It looks like this

Specifying IP address is something like puzzle. If we have more views, it will be more difficult.

Now, increase the serial number of the data file.

The new address is already bound with root privileges, so re-read the configuration. Then the timestamps in the secondary osaka-home-xxxx and saopaulo-home-xxxx files will be changed, indicating that a transfer has occurred and data has been updated.

Now, let’s check the MX records. Now we have a problem. The order of MX records is the same for view OSAKA and SAPAULO. That’s normal. Because they use the same data file 🙁

The first thing that comes to mind as a solution is that it would be easy to create separate master files for OSAKA and SAOPAULO and write MX records to them separately. But think about it. If you have 100 offices that use this DNS server, do you want to edit all 100 master files every time there is a change? No way 🙂 A useful feature is response-policy. It allows zones defined in response-policy to respond differently than the original zone data. This time, I would like to use this MX record in view SAOPAULO with response-policy. First, create a zone file to be used in response-policy.

package -> pokemon -> dhcp. in this order.

Apply this response-policy to view SAOPAULO. It is important to note that communication for view OSAKA must be completed only between IP addresses defined in view OSAKA. Similarly, communication for view SAOPAULO must be completed only between IP addresses defined in view SAOPAULO.

We need to use spread sheet and assign IP address clearly and carefully. Otherwise we will be crazy if we have more views 🙂

It has become quite complicated. Now, let’s load the settings and check to see if it works. First, let’s start with pokemon. pokemon is OK as long as it can see the data in view OSAKA.

It returns MX records as expected no matter which interface is used to query. Now let’s test package as well.

The package has the smallest value in any of the DNS queries, as expected. Finally, let’s check how each of the forwarders work. The pokemon should be OK if it can get the address of the appropriate site for Osaka. As we did before, we will check using the M$ data center.

It returnes ITM and the latency is around 4ms. So we can say it is good. The package should be OK as long as it returns the address of a site suitable for Sao Paulo.

It returns CPQ and ping is around 280ms. The package is DNS for Sao Paulo, but it is located in Japan. So, CPQ is not so bad for the client in Sao Paulo. For your information, I pinged to the same address from iPXE’s server physically in Sao Paulo.

This is the result of experiment in SauPaulo.

How was it? It seems to be a bit crazy to have a DNS server in Japan taking care of clients in Sao Paulo, but to make it numerically easier to understand, we have recreated a situation that would normally not be possible. If you, as a network administrator, are using Windows Active Directory Integrated DNS and are wondering why it’s so slow, then small tricks for remote users works very well and you will be appreciated very much 🙂 It might be a good idea to use Wndows AD DNS only within a Windows environment.

Visiting Kyoto Nishiki Market on a rainy day is recommended as a calm, umbrella-free stroll, as there are fewer people than usual, combined with the influence of the corona. The parking lot that I often use is the underground parking lot around Teramachi Oike. The parking lot is located at the foot of the Kyoto City Hall. The parking lot is located underground on Oike Dori, which runs long from east to west, and the exit is at the east end of the parking lot leads to an underground shopping mall, from which you can walk to the entrance of Nishiki Market without using an umbrella. The first thing you see when you enter the Nishiki Market is the Honnoji monument. Oh, Honnoji Temple is here ? The Honnoji Temple where the Honnoji Incident took place is located a short distance away from here, and only the stone monument remains there. And this Honnoji Temple was rebuilt later. Walking south through Nishiki Market, you will find Nishiki Tenmangu Shrine on your left. I used to visit this shrine every time I visited Nishiki Market, turning over my wallet to make a small offering of coins. This one is famous for its torii gate, which dips into the surrounding building walls. I don’t think I have that picture of my own, so please try to find one by searching the Internet.

Walking west on Nishiki-koji Street from Nishiki Tenmangu Shrine for a while, we found a restaurant where people were drinking sake during the daytime. It was late lunch time, so my wife and I went in and enjoyed the local cuisine 🙂 My wife doesn’t like to drink and we were traveling by car, so we had to leave the fun for the next time we took the train with a friend who likes drinking.

The souvenir is red pepper with seven kinds of spices, so called “Shichimi”. Even if you are not in the Ninenzaka street or Sannenzaka street area, the Shichimi here is delicious as well.