There is a network with white IP (111.222.333.0) and domain (mydomain.ru). It is required to raise the DNS that looks at the Internet.
Boot the FreeBSD 10.0 image
Set, assign the address 111.222.333.2 to the network interface
We set up time synchronization once a day. add to crontab:
1 6 * * * root ntpdate -s 0.freebsd.pool.ntp.org
Install bind 9.9 from the repository:
Pkg install bind99
Editing the config
At the beginning of the config, we write the rules for allow-recursion allow-transfer allow-query
Acl "recursion-ip" (127.0.0.1; 111.222.333.0/24;); acl "trusted-dns" (111.111.111.111; 222.222.222.222;); acl "query-ip" (127.0.0.1; 111.222.333.0/24;);
In the options section, write:
// allow recursive requests allow-recursion (recursion-ip;); // allow the transfer of the zone to trusted DNS servers // (specifies the ns server of the domain registrar) allow-transfer (trusted-dns;); // allow us to submit requests to our server allow-query (query-ip;); // hide the version of our server version "MyDNS";
We indicate which interfaces to work on.
Listen-on (127.0.0.1; 111.222.333.2;);
At the end of the file, we write the forward and reverse zones:
Zone "mydomain.ru" (type master; file "/usr/local/etc/namedb/master/mydomain.ru-forward.db";); zone "333.222.111.in-addr.arpa" (type master; file "/usr/local/etc/namedb/master/mydomain.ru-333.222.111-reverse.db";);
Now we create zone files. We register in the file mydomain.ru-forward.db
$ TTL 3600 @ IN SOA ns1.mydomain.ru. root.ns1.mydomain.ru. (2014040101; Serial 3600; Refresh 900; Retry 360000; Expire 3600; Neg. Cache TTL) IN A 111.222.333.1; our domain mydomain.ru IN NS ns1.mydomain.ru will be resolved to this address. IN NS ns1-your_registrator.ru. ; ns server of your registrar IN NS ns2-your_registrator.ru. IN MX 10 mail.mydomain.ru. ; if there is mail in the ns1 domain IN A 111.222.333.2; The IP address of our DNS first IN A 111.222.333.10; then the domains second IN A 111.222.333.11 will go; the third level of our network
Then we write to the reverse zone file mydomain.ru-333.222.111-reverse.db following:
$ TTL 3600 @ IN SOA ns1.mydomain.ru. root.ns1.mydomain.ru. (2014032801; Serial 3600; Refresh 900; Retry 360000; Expire 3600; Neg. Cache TTL) IN NS ns1.mydomain.ru. IN NS ns1-your_registrator.ru. IN NS ns2-your_registrator.ru. 2 IN PTR ns1.mydomain.ru. 10 IN PTR first.mydomain.ru. 11 IN PTR second.mydomain.ru.
The Serial value must be incremented each time a zone is changed.
From this value, the secondary server detects that the information needs to be updated.
Now let's check the zone files:
Named-checkzone mydomain.ru mydomain.ru-forward.db named-checkzone 333.222.111.in-addr.arpa mydomain.ru-333.222.111-reverse.db
The command output should look like this:
Zone mydomain.ru/IN: loaded serial 2014040101 OK
Let's set up logging.
We register bind ( /usr/local/etc/namedb/named.conf)
Logging (channel default_ch (file "/var/log/named/named.log" versions 3 size 500k; severity info; print-time yes; print-category yes;); channel security_ch (file "/ var / log / named / named-security.log "versions 3 size 500k; severity info; print-time yes; print-category yes;); channel transfer_ch (file" /var/log/named/named-transfer.log "versions 3 size 500k; severity info; print-time yes; print-category yes;); channel lame_ch (file "/var/log/named/named-lamers.log" versions 3 size 500k; severity info; print-time yes; print-category yes; ); category default (default_ch;); // everything for which there is no own channel category security (security_ch;); // security events category xfer-in (transfer_ch;); // sending zones category xfer-out (transfer_ch;) ; // receiving zones category notify (transfer_ch;); // notifications and registration facts category lame-servers (lame_ch;); // events from "crooked" DNS servers);
Set the owner to the / var / log / named directory
Chown bind: bind / var / log / named
We check the correctness of the named.conf config with the command
Named-checkconf
If the result of this command is "nothing" then everything is OK.
Now load the actual root zone file (named.root).
Fetch ftp://ftp.internic.net/domain/named.root
Let's place it in the / usr / local / etc / namedb directory and replace the existing one.
It is advisable to periodically repeat this procedure, or configure this operation using cron.
It's almost done! Let's configure the management utility - rndc
Go to the directory / usr / local / etc / namedb
Delete the rndc.conf file
We carry out:
Rndc-confgen -a
Change owner:
Chown bind: bind rndc.key
We enable the autostart of the name server.
In the /etc/rc.conf file, add:
Named_enable \u003d "YES" # if only IPv4 is needed, then named_flags \u003d "- 4"
Let's configure DNSSEC.
Create a keys directory for key files.
Create a master key - Key Signing Key (KSK) and a key for the zone - Zone Signing Key (ZSK).
KSK key creation command:
Dnssec-keygen -f KSK -a RSASHA256 -b 2048 -n ZONE mydomain.ru
Command to create ZSK key:
Dnssec-keygen -a RSASHA256 -b 2048 -n ZONE mydomain.ru
make sure your domain registrar supports RSASHA256 algorithm
we set the rights to the key files:
Chown bind: bind Kmydomain.ru *
Let's enable logging. To config /usr/local/etc/namedb/named.conf add to the logging section:
Channel dnssec_ch (file "/var/log/named/named-dnssec.log" versions 3 size 500k; severity info; print-time yes; print-category yes;); category dnssec (dnssec_ch;);
and add to the zone description:
Key-directory "/ usr / local / etc / namedb / keys"; inline-signing yes; auto-dnssec maintain;
now the mydomain.ru zone looks like this:
Zone "mydomain.ru" (type master; file "/usr/local/etc/namedb/master/mydomain.ru-forward.db"; key-directory "/ usr / local / etc / namedb / keys"; inline- signing yes; auto-dnssec maintain;);
To support DNSSEC validation on the resolver side, add to the options section:
Dnssec-enable yes; dnssec-validation yes;
After rasterizing the daemon, files with the extension: .jbk, .jnl and.signed will appear in the zones directory
If you use DNSSEC Look-aside Validation (dnssec-lookaside auto; option), you can see multiple messages in the log like: got insecure response; parent indicates it should be secure. To prevent this, set the dnssec-validation value to auto; and use DNS servers with DNSSEC support as forwarders, for example from Google - 8.8.8.8
For the verification process to work, the registrar of your domain needs to certify the generated KSK key and confirm your trust.
for this you need to register DS records in the domain control panel.
DS records are created based on the KSK key with the command:
Dnssec-dsfromkey ksk_file_name
the records issued by this command are registered in the control panel of the domain registrar.
Mydomain.ru. IN DS 54808 5 1 0FC489EFD28C2 ... 28EA985CAFBBC1 mydomain.ru. IN DS 54808 5 2 03B685D8003834B492F6 ... B134ABF9D41A28193171352F0280
Some registrars also need to register DSKEY from the key KSK file.
Mydomain.ru. IN DNSKEY 257 3 5 YthgRbNKP5P8e5cDJhYsCwFr7AK17m + SeV5pgW ... bLVa2A0 / dWXkPwi1TZ3lNfkjhhYFGR
Finally, we will configure the firewall.
Let's create a file /etc/ipfw.my_rules with the following content:
#! / bin / sh cmd \u003d "/ sbin / ipfw -q add" # command for adding rules oint \u003d "vmx0" # interface on which named ipo \u003d "111.222.333.2" # IP address of this interface # Reset all rules: / sbin / ipfw -f flush # Check for packet compliance with dynamic rules: $ (cmd) check-state # Allow all traffic on the lo0 internal interface $ (cmd) allow ip from any to any via lo0 # cut off attempts to climb from lo0 and to it $ (cmd) deny ip from any to 127.0.0.0/8 $ (cmd) deny ip from 127.0.0.0/8 to any # block private networks and auto-config because the interface looks at the internet. $ (cmd) deny ip from any to 10.0.0.0/8 in via $ (oint) $ (cmd) deny ip from any to 172.16.0.0/12 in via $ (oint) $ (cmd) deny ip from any to 192.168 .0.0 / 16 in via $ (oint) $ (cmd) deny ip from any to 0.0.0.0/8 in via $ (oint) $ (cmd) deny ip from any to 169.254.0.0/16 in via $ (oint) # block multicast packets $ (cmd) deny ip from any to 240.0.0.0/4 in via $ (oint) # block broadcast and fragmented icmp $ (cmd) deny icmp from any to any frag $ (cmd) deny log icmp from any to 255.255.255.255 in via $ (oint) $ (cmd) deny log icmp from any to 255.255.255.255 out via $ (oint) # traffic to private networks $ (cmd) deny ip from 10.0.0.0/8 to any out via $ (oint) $ (cmd) deny ip from 172.16.0.0/12 to any out via $ (oint) $ (cmd) deny ip from 192.168.0.0/16 to any out via $ (oint) $ (cmd) deny ip from 0.0.0.0/8 to any out via $ (oint) # auto-configured private network $ (cmd) deny ip from 169.254.0.0/16 to any out via $ (oint) # multicast mailings $ (cmd) deny ip from 224.0. 0.0 / 4 to any out via $ (oi nt) $ (cmd) deny ip from 240.0.0.0/4 to any out via $ (oint) # allow established connections $ (cmd) allow tcp from any to any established # allow outgoing traffic from the server $ (cmd) allow ip from $ (ipo) to any out xmit $ (oint) # allow time synchronization via ntpdate $ (cmd) allow udp from any 123 to any via $ (oint) # allow DNS $ (cmd) allow udp from any 53 to any via $ (oint) # allow incoming DNS (tcp is required for zone transfer) $ (cmd) allow udp from any to any 53 via $ (oint) $ (cmd) allow tcp from any to any 53 via $ (oint) # allow ICMP - echo request, echo reply, packet lifetime expired $ (cmd) allow icmp from any to any icmptypes 0,8,11 # allow port 22 for a specific address and log attempts to connect from different addresses $ (cmd) allow tcp from 111.222.333.3 to $ (ipo) 22 via $ (oint) $ (cmd) deny log tcp from any to me 22 in via $ (oint)
To autostart the firewall, add the following lines to the /etc/rc.conf file:
Firewall_enable \u003d "YES" firewall_script \u003d "/ etc / ipfw.my_rules" firewall_logging \u003d "YES"
Logs will be written to the file / var / log / security
In this article, we will cover network interfaces in FreeBSD 11.1, let's show the network setup through the configuration file / etc / rc.conf, namely the purpose staticsettings and getting them by DHCP.Let's write the addresses DNS-servers, set up hostsand consider the indication temporary network settings.
View network interfaces.
First, let's be clear: There are two states of the network card UP(involved) and DOWN(not used).
The first step is to look at our network interfaces, we will look with the command ifconfig. (Fig. 1) Command output shows all interfaces UPand DOWN.
Ifconfig
ifconfig -a will show you the same.
Ifconfig -a
There are some differences from ifconfig at Ubuntu server.(at Ubuntu server "ifconfig" only shows interfaces UP, "ifconfig -a"shows all interfaces and UPand DOWN)
Fig. 1 - The result of entering the ifconfig command.
And so what do we see:
- em0- our network card, with an IP address 192.168.3.11 .
- em1 - second network card not configured.
- lo - local loop, it is present for all by default.
To see interfaces only UP, the command is used ifconfig -u(Figure 2):
Ifconfig -u
and to view interfaces only DOWN, the command is used ifconfig -d(Fig. 3):
Ifconfig -d 
Fig. 2 - The result of entering the command ifconfig -u. 
Fig. 3 - The result of entering the command ifconfig -d.
In the future, I will show examples of settings on the interface "em0".
To enable the interface, use the command ifconfig"NAME-INTERFACE" up.
Ifconfig em0 up
To turn off the interface, use the command ifconfig "NAME-INTERFACE" down.
Ifconfig em0 down
"Play around" with an interface, unless of course you are connected by sshand leave it in a state UP.
Setting up the network through the configuration file.
To configure a static or dynamic IP address, we need to edit the configuration file for network interfaces - / etc / rc.confwe will edit it with a text editor vi. (Fig. 4) I'll tell you right away, in order to edit in vi need to press a letter "i", and to save and close the document, press "Esc"to introduce ": wq!"and press "Enter".
Figure 4 - vi /etc/rc.conf.Obtaining network settings via DHCP.
To assign the receiving of settings via DHCP, you need to enter (or change the existing) line in the / etc / rc.conf. (Fig. 5)
ifconfig_NAME-INTERFACE\u003d "DHCP"
Ifconfig_em0 \u003d "DHCP" 
Fig. 5 - Getting network settings via DHCP.
Restart the network service netif. (Fig. 6)
/etc/rc.d/netif restart Fig. 6 - Restarting the FreeBSD network service.
We look at the active network interfaces, we see, received via DHCP, the IP address of the interface em0- 192.168.3.6 (Fig. 7)
Ifconfig -u
Ping 8.8.8.8 
Fig. 7 - Checking active interfaces and network access.
Pings are coming. All perfectly!
Manually specifying network settings.
To assign a static address to our Freebsd need to file / etc / rc.conf enter two lines (Fig. 8)
ifconfig_NAME-INTERFACE\u003d "inetIP-ADDRESS-FREEBSD netmaskMASK NETS "
defaultrouter \u003d "GATEWAY IP ADDRESS "
Ifconfig_em0 \u003d "inet 192.168.3.11 netmask 255.255.255.0" defaultrouter \u003d "192.168.3.1" 
Fig. 8 - Static settings of the network interface.
We restart the network service.
/etc/rc.d/netif restart
Checking active interfaces
Ifconfig -u
We check the Internet access by pinging Google Eights.
Ping 8.8.8.8
DNS setup.
DNS server IP addresses are stored in the / etc / file resolv.conf(Fig. 9)
We open resolv.confin editor vi.
Vi /etc/resolv.conf
We enter IP the address DNS server. (You can enter as many addresses as you like.)
Nameserver 192.168.3.1 nameserver 8.8.8.8 nameserver 8.8.4.4
If you don't have a file resolv.conf then create it in the directory / etc
Touch /etc/resolv.conf 
Fig. 9 - Contents of the resolv.conf file.
The / etc / hosts file.
The / etc / file hosts contains tables for mapping DNS names to IP addresses. First of all, your server will access the file hosts, and then to the DNS server.
For myself, I noted it useful to make hosts recording this freebsd (LAN IP address - server name). Now we can specify the DNS name in all configuration files, not the IP address, and if necessary, change our IP address in the shortest time by correcting hosts and interface settings in / etc / rc.conf.
This is just an example for you to do this not necessary.
Let's start editing (Fig. 10):
Vi / etc / hosts
I enter:
192.168.3.11 freebsd.itdeer.loc Fig. 10 - Contents of the hosts file.
I'll check by pinging names from hosts. (Fig.11)
Ping localhost ping freebsd.itdeer.loc 
Fig. 11 - Pinging names from hosts.
Temporary assignment of an ip address.
To be honest, I do not know what the temporary assignment of network settings can be useful for. Unless let's say you have some kind of server that is designed only for your local network and you suddenly decided to quickly update the software via the Internet on this server, so as not to go to the gateway, not distribute the Internet to the desired IP address, etc. You can get by with a couple of commands.
For example, we know that on 192.168.3.109 There is definitely Internet access, we assign this IP address to our interface, you also need to specify the network mask (Fig. 12):
Ifconfig em0 192.168.3.109 netmask 255.255.255.0
or a command with a short netmask entry.
Ifconfig em0 192.168.3.109/24 
Fig. 12 - Specifying temporary settings for the em0 network interface.
Internet may not appear because no default gateway is specified. We register it and ping the Google Eights. (Fig. 13)
Route add default 192.168.3.1 ping 8.8.8.8 
Fig. 13 - Specify the default gateway. Checking ping.
Whether we have registered our default gateway correctly can be seen in the routing table. It is displayed using the command "netstat -rn"The default gateway will be flagged UG. (Fig. 14)
Netstat -rn 
Fig. 14 - Output of the routing table.
If you misspelled the spelling somewhere or you have specified a different gateway, then you can remove default gateway.
Route del default
This completes the temporary configuration, remember that after restarting the server or separately the services networking, all temporary settings will disappear.
Add a route to the network 192.168.0.0/16 (Mask 255.255.0.0) through the default gateway 192.168.3.1/24
Route add 192.168.0.0/16 192.168.3.1
Option to add a route with a full mask.
Route add -net 192.168.0.0 -netmask 255.255.0.0 192.168.3.1
Rename the em0 interface to wan0.
For convenience, some admins rename interfaces so that they can immediately see what the interface is for. Let's say we have a gateway with two network interfaces em0(internet) and em1(local network) and working with such names is inconvenient, since having a large number of interfaces can get confused. It is much more convenient to work with interfaces wan0and lan1.
We will show an example of renaming an interface em0 at wan0in the / etc / file rc.conf. (Fig. 15)
Ifconfig_em0 \u003d "inet 192.168.3.11 netmask 255.255.255.0"
Replace with two lines:
Ifconfig_ em0_name \u003d " wan0"ifconfig_ wan0\u003d "inet 192.168.3.11 netmask 255.255.255.0" 
Fig. 15 - Renaming the interfaces in the /etc/rc.conf file.
Don't forget to restart the network service:
/etc/rc.d/netif restart
Check, enter the command ifconfig -u... We see our wan0 with the right IP address. (Fig.16)
Ifconfig -u 
Fig. 16 - Checking the new name of the interface. ifconfig -u.
It's time to upgrade some of the servers running FreeBSD 9.3. In FreeBSD 10, the BIND server was removed from the base system, and if you continue to use it, then you need to install it from ports.
After update systems, I quickly changed a couple of lines of configs did not manage to start BIND in chroot'e on FreeBSD 10, so I decided to describe this process in detail. Perhaps it will save some time.
Install BIND from ports.
cd / usr / ports / dns / bind99 && make install clean
The remaining configuration from 9.X is located at / var / named / etc / namedb. And if we act in accordance with the standards, then we move the configuration to / usr / local / var / named / etc / namedb, because even the system itself tells us that we should not have anything in / var / named /.
[email protected]: / usr / src # make check-old
\u003e\u003e\u003e Checking for old files
/var/named/etc/namedb/named.root
\u003e\u003e\u003e Checking for old libraries
\u003e\u003e\u003e Checking for old directories
/ var / named / dev
/ var / named / etc
/ var / named / etc / namedb
/ var / named / etc / namedb / dynamic
/ var / named / etc / namedb / master
/ var / named / etc / namedb / working
/ var / named / etc / namedb / slave
/ var / named / var
/ var / named / var / dump
/ var / named / var / log
/ var / named / var / run
/ var / named / var / run / named
/ var / named / var / stats
/ var / run / named
To remove old files and directories run "/usr/obj/usr/src/make.amd64/bmake delete-old".
To remove old libraries run "/usr/obj/usr/src/make.amd64/bmake delete-old-libs".
Create a working directory for BIND.
mv / var / named / usr / local / var
The configuration files created by the installer will be located in / usr / local / etc / namedb. We reserve them just in case.
mv / usr / local / etc / namedb /usr/local/etc/namedb.orig
ln -s / usr / local / var / named / etc / namedb / usr / local / etc / namedb
mkdir -p / usr / local / var / named / usr / local
cd / usr / local / var / named / usr / local ln -s ../../etc
cp /usr/local/etc/namedb.orig/named.root / usr / local / var / named / etc / namedb
Create rules for devfs. We edit /etc/devfs.conf.
# Custom rules for the named chroot dev
add hide
add path run unhide
add path random unhide
Add to / etc / fstab.
devfs / usr / local / var / named / dev devfs rw, ruleset \u003d 4 0 0
We mount.
mount / usr / local / var / named / dev
We edit /etc/rc.conf with something like the following.
named_enable \u003d "YES" # Run named, the DNS server (or NO).
named_program \u003d "/ usr / local / sbin / named" # path to named, if you want a different one.
named_chrootdir \u003d "/ usr / local / var / named" # Chroot directory (or "" not to auto-chroot it)
named_conf \u003d "/ usr / local / etc / namedb / named.conf" # Path to the configuration file
named_flags \u003d "- 4" # Flags for named
named_uid \u003d "bind" # User to run named as
named_chroot_autoupdate \u003d "YES" # Automatically install / update chrooted
# components of named. See /etc/rc.d/named.
named_symlink_enable \u003d "YES" # Symlink the chrooted pid file
# named_wait \u003d "NO" # Wait for working name service before exiting
# named_wait_host \u003d "localhost" # Hostname to check if named_wait is enabled
# named_auto_forward \u003d "NO" # Set up forwarders from /etc/resolv.conf
# named_auto_forward_only \u003d "NO" # Do "forward only" instead of "forward first"
Editing the configuration file /usr/local/etc/namedb/named.conf
directory "/ usr / local / etc / namedb";
We set the correct access rights to the configuration files.
chown -R bind: wheel / usr / local / var / named / etc / namedb
At the moment, we still need to fix /usr/local/etc/rc.d/named, otherwise an error appears when the service stops.
Stopping named.
umount: / var / namedb / usr / local / lib / engines: statfs: No such file or directory
umount: / var / namedb / usr / local / lib / engines: unknown file system
Making the following changes
named_poststop ()
{
- if [-n "$ (named_chrootdir)" -a -c $ (named_chrootdir) / dev / null]; then
+ if [-d $ (_ openssl_engines) -a -n "$ (named_chrootdir)" -a -c $ (named_chrootdir) / dev / null]; then
Launching BIND
/usr/local/etc/rc.d/named start
The article used materials.
In this publication, I want to disclose the configuration of a DNS server on a machine running the FreeBSD operating system, with the help of which it would be possible to support several (in theory, unlimited) number of domain zones: primary (primary), secondary (secondary), as well as reverse or reverse (reverse)... But first, I will present a little theory, to explain what are needed for, what are and how these same domain zones differ from each other.
The primary, or, as it is also called, Primary DNS zone is a set of domain name records, as well as subnames, which are registered by the administrator of this zone. The primary DNS zone of a domain name is authoritative or authoritative for a secondary. That is, it contains the most relevant information about the zone and is shared with it with all secondary zones. The primary zone is usually supported by the primary DNS server of the given zone. The administrator of this server is responsible for registering zone records in the configuration files of the DNS server.
The secondary DNS zone is a duplicate and subordinate primary zone. It is necessary in order to maintain and distribute records for the domain name, in the event that for some reason the primary DNS server of the zone becomes unavailable on the Internet. The server on which the secondary DNS zone for a domain name is registered is called the secondary or alternative or secondary DNS server of the zone. There can be an unlimited number of secondary DNS servers for a zone. The only requirement is that they must all be configured to receive information about this zone from the primary DNS server. Accordingly, the primary DNS must be configured to provide this information to all secondary DNS servers in the zone. Usually one DNS server and one or two secondary ones are used to support domain zones. In rare cases, a scheme is possible when I use two primary DNS servers to support the zone, while configuring them in such a way that the information on them is always synchronized.
The primary and secondary DNS for a zone must be on different networks (autonomous systems). And the further they are geographically separated from each other, the better. Rarely, but nevertheless there are cataclysms on the Internet, in which entire countries become “cut off from the world”. In this case, having registered the zone on the primary DNS server in Ukraine, and using DNS as a secondary one in the United States, you do not have to worry that in case of problems with backbone channels, the domain zone will “die”.
The reverse zone is used to specify so-called reverse DNS records. They are used to indicate the correspondence of IP addresses to certain names. Difficult to understand? Let me give you an example.
There is an IP address of 213.180.204.8. This is the IP address of the server on which the well-known http://ya.ru/ runs. When searching for a match for the name ya.ru to the IP address of the machine to which this name is “tied”, you can run the command:
$ host ya.ru ya.ru has address 213.180.204.8 ...
or on Windows
C:\u003e nslookup ya.ru ... Name: ya.ru Address: 213.180.204.8
We have a mapping of a name to an IP address, or “direct translation of a name to an IP address” (using an A record). However, over time on the Internet, it became necessary to match the IP address of the name as well (perhaps this happened in the heat of the fight against the growing volumes of spam traffic). And then they came up with the so-called “IN-ADDR.ARPA” zone, to which all addresses on the Internet were tied, reversed. What does it look like?
$ host 213.180.204.8 8.204.180.213.in-addr.arpa domain name pointer ya.ru.
or on Windows
C:\u003e nslookup -q \u003d PTR 8.204.180.213.in-addr.arpa ... 8.204.180.213.in-addr.arpa name \u003d ya.ru ...
All IP addresses on the Internet can be converted to the form XXX.XXX.XXX.XXX.in-addr.arpa To do this, you just need to write the address itself “backwards” and add “.in-addr.arpa” at the end ... So, the zone prescribed for reverse conversion of the IP address is called the reverse or reverse or reverse zone. As you can see from the last example, for 8.204.180.213.in-addr.arpa the name ya.ru is registered
For a long time, it so happened that programs to work as basic network services are included by default in the code of the FreeBSD operating system. DNS is no exception. On FreeBSD, bind (or named) acts as the DNS server. Over time, a lot of different software has been written that can easily replace bind, however, since bind is "native" to FreeBSD and we will use it. Despite the number of critical vulnerabilities that have been discovered in bind throughout its history, it remains one of the most popular DNS servers on the Internet. By the way, the FreeBSD developers fixed the latest, not critical bug in bind on the eve of the 6.3 release.
So, we are working with the FreeBSD 6.3 RELEASE operating system. Latest version of bind to date:
# named -version BIND 9.3.4-P1
All our DNS configuration files are located in the / etc / namedb / directory, which is a link to the / var / named / etc / namedb directory. The / var / named / directory is the chroot environment in which bind starts. The following files can be located in this directory:
# ls / etc / namedb / dump -\u003e / var / named / var / dump master / named.conf named.root reverse / rndc.key slave / stats -\u003e / var / named / var / stats zones.master zones.slave zones.reverse
- named.conf - main bind configuration file
- zones.master, zones.slave, zones.reverse - configuration files that contain supported DNS zones
- slave /, master /, reverse / - directories where configuration files of DNS zones are located
- named.root - a system configuration file containing information about all root DNS servers on the Internet
- rndc.key - file with a key, which is required to control bind using the rndc utility
Our future DNS server requires:
- Distribute up-to-date information about our zone zone1.com, that is, be the primary DNS for it.
- Maintain the friends.com zone and be a secondary DNS for it.
- Since we have a certain number of machines on the local network, it is required to register a reverse DNS record for each machine. We need this so that in the logs of, for example, Apache (which will be running on the same server), not IP addresses are recorded, but the names of computers on our local network.
- Execute recursive search in the DNS system for zones (names) that are not currently in the cache and that are not registered on our DNS server.
Let's start by editing the config file /etc/namedb/named.conf... By the way, man named.conf Is a great tutorial for configuring bind.
A working example written for this tutorial is shown below. Lines starting with // are comments.
//////////////////////////////////// // Bind configuration file by Daemony ///// ///////////////////////////////// // 1. Global settings // // Create an access list. Let's call it IN_NET. Below will come in handy. acl "IN_NET" (127.0.0.1; 172.17.17.0/24;); // // The following are the main server options options (// - host name, in principle it is not needed hostname "ns.mydns.net"; // - directory with configuration files directory "/ etc / namedb"; // BE ATTENTION! Further paths to files and directories // are specified in the chroot "environment / var / named // - where the pid file of the daemon pid-file" / var / run / named / pid "will be located; // - here we can ( although it is optional) specify the file // into which the DNS cache will fall after the command // rndc dumbdb dump-file "/var/dump/named_dump.db"; // - and this file (also optional) will fall // server statistics if you run rndc stats statistics-file "/var/stats/named.stats"; // // On which interfaces to listen to port 53. // If the parameter is not specified, then everything listens. listen-on (127.0.0.1 ; 192.168.0.1; XXX.XXX.XXX.XXX;); // An interesting option. I'll tell you at the end of the config, // where it can help out. Interface-interval 10; // Allow recursive queries? Yes. Recursion yes; // We define, from to To process such networks // recursive requests. We use here, // the previously created Access Control // List named IN_NET allow-recursion ("IN_NET";); // If there is no entry in the cache about the zone we need, // what to do? Do you want to start searching for a name right from // root DNS servers, or try // to "check" this information from the nearest DNS (usually your // provider) by redirecting the request? // Yes, redirect. forward first; // To redirect, you need to know // who to redirect to. We indicate here the DNS "s // of your provider (several are possible). Forwarders (XXX.XXX.XXX.XXX; YYY.YYY.YYY.YYY;); // About those zones that we support // (both primary and secondary ) to whom we will // give information to everyone. This parameter // can be overridden for each specific // zone in the zone configuration file. allow-query (any;); // Parameter for specifying the server version. // Why is it not clear. version "SuperPuper DNS";); // Global settings are over. // Then there are optional parameters // for logging. You can write, but you can // not write. logging (channel syslog (syslog daemon; severity info; print-category yes ; print-severity yes;); category xfer-in (syslog;); category xfer-out (syslog;); category config (syslog;); category default (null;);); // // And here we write the settings "remote" // DNS server management with the rndc utility. // I took the remote in quotation marks, because // we will manage our DNS only from the localhost. // Though it is possible to make bind open // "command chanel" on the front // interface and accept commands from remote nodes. // But I think this is a "hole", and therefore not fig. // Let only listen to localhost and accept // commands only from it. In this section, we // only need to register only a key that // will be used when working with rndc. key "Daemony" (algorithm hmac-md5; secret "pPSvUGU4mRoD0vTuwpzvUg \u003d\u003d";); // // Actually, with the server configuration on this // everything. Next are the settings for only DNS zones. // //////////////////////////////////////////// // I conditionally called this section "SYSTEM" zones /////////////////////////////////////// ///// // ///// Root zone. Or the "point" zone. // GETTING STARTED! // Otherwise your DNS will not work. // zone "." (// - the zone type is described here type hint; // - the zone configuration file is specified here. file "named.root";); // ///// Forward zone for localhost zone "localhost" (// - the next parameter indicates that our DNS server // for this zone is authoritative type master; // - who can be told about this zone - // understandable the matter is that only to itself allow-query (127.0.0.1;); // - file with zone configuration file "master / localhost";); // ///// Reverse zone for localhost zone "0.0.127.IN-ADDR.ARPA" (type master; allow-query (127.0.0.1;); file "reverse / localhost.rev";); // Everything is the same as in the previous case. // // At the end of named.conf, we use the include // construction to include reading the rest of the // DNS configuration, namely information about the supported zones, // which is contained in the following files. // include "/etc/namedb/zones.master"; include "/etc/namedb/zones.slave"; include "/etc/namedb/zones.reverse"; /// End of bind configurationAs for the option “ interface-interval”It can be useful on servers where the external interface is dynamic, for example, tun0 ... If you are connected to an Internet service provider using PPP or PPPoE when the system starts up, bind may start faster than it will be brought up PPP / PPPoE compound. Coupled with “ listen-on”This will result in bind not being able to listen to the interface that appeared after it was started. I don't know how to treat it. If someone prompts, I will say thank you. But I know that with the help of “ interface-interval N; "You can make bind wait N seconds after starting it before it" spins "on interfaces. When the system starts up in 10 seconds, the PPPoE interface, for example, usually goes up without problems and bind continues to work normally.
File zones.reverse connected in the config named.conf and contains information about reversing zones. We have one. We need PTR records for machines on the local network, and on the local network we only have one subnet 192.168.0.0/24
// - zone name zone "0.168.192.IN-ADDR.ARPA" (// - zone type - we have it "primary" but registered for the reverse type master; // - who can be responsible for requests to receive // \u200b\u200binformation about names in this zone? Only our local network allow-query (127.0.0.1; 192.168.0.0/24;); // - path to the zone configuration file file "reverse / in.0.168.192.rev";);
The zones.master file is also included in the config named.conf and contains information about which primaries ( primary) zones we will support. For example, we will have only one. Zone zone1.com
// - zone name zone "zone1.com" (// - zone type - we have it "master" - primary type master; // - path to the zone configuration file file "master / zone1.com"; // - to whom can I be responsible for requests to obtain // information about the names in this zone? Everyone. allow-query (any;); // - who can give the entire zone configuration // (to carry out a transfer). Here we indicate only the IP // addresses of our secondary DNS servers for zone1.com allow-transfer (100.200.0.1; 200.100.0.2;););
The zones.slave file is again connected in the config named.conf and contains information about which secondary ( secondary) zones must be supported by our DNS server. In this example, we are supporting one zone friends.com
// - specify the name of the zone zone "friends.com" (// - indicate that this zone is a secondary (slave) type slave; // - in which file to save information about this zone file "slave / friends.com"; // - specify the IP address (s) of the primary DNS server (s) // Let me remind you that there can be more than one primary server masters (210.220.230.240;););
The zone configuration is done. If you need to add another zone, edit the corresponding file and instruct bind to re-read the settings. Now we will describe the zones themselves in the corresponding files. Let's start with localhost.
# cat / etc / namedb / master / localhost $ TTL 1D localhost. IN SOA ns.mydns.net. root.ns.mydns.net. (2007042001; serial number 86400; refresh 3600; retry 3888000; expire 3600; minimum) localhost. IN NS ns.mydns.net. localhost. IN A 127.0.0.1
In this example, the second line contains the following parameters: “ zone name"- localhost," record type"- IN SOA - Start Of Authority -" The beginning of the authoritative zone“, For which the authoritative DNS server is responsible ns.mydns.net, and the administrator of this server can be contacted by e-mail [email protected] (dot is replaced by "dog"). This is followed by the zone serial number ( serial number), which the is always should be changed when making changes to the zone, the zone update period ( refresh) by secondary DNS servers (in seconds), the period between attempts to update the zone by a secondary DNS server ( retry), if the previous attempt was unsuccessful, the zone lifetime ( expire) on the secondary DNS server if the primary is not available. What does the parameter “ minimum“I honestly don't remember.
This is followed by descriptions of the zone's DNS records. From the example you can see that one A record is registered for the localhost name and it points to the IP address 127.0.0.1 The ns.mydns.net server is responsible for maintaining the zone, that is, our local bind.
Example of reverse DNS zone configuration for localhost
# cat /etc/namedb/reverse/localhost.rev $ TTL 3600 @ IN SOA ns.mydns.net. root.ns.mydns.net. (2007042001; Serial 3600; Refresh 900; Retry 3600000; Expire 3600); Minimum IN NS ns.mydns.net. 1 IN PTR localhost.
Now our bind will know that the following PTR record is written for 127.0.0.1:
# host 127.0.0.1 1.0.0.127.in-addr.arpa domain name pointer localhost.
Now we need to create a reverse DNS zone file /etc/namedb/reverse/in.0.168.192.rev in which we will specify the PTR records for the machines on our local network. An example would be like this:
$ TTL 3600 @ IN SOA ns.mydns.net. root.ns.mydns.net. (2007042001; Serial 3600; Refresh 900; Retry 3600000; Expire 3600); Minimum IN NS ns.mydns.net. 1 IN PTR router. 2 IN PTR mail-server. 3 IN PTR web-server. 4 IN PTR boss. 5 IN PTR buhgalter. // etc...
After our DNS re-reads this configuration, on the local network, IP addresses will begin to resolve in something like this:
$ host 192.168.100.1 1.0.168.192.in-addr.arpa domain name pointer router. $ host 192.168.100.2 2.0.168.192.in-addr.arpa domain name pointer mail-server. $ host 192.168.100.3 3.0.168.192.in-addr.arpa domain name pointer web-server. $ host 192.168.100.4 4.0.168.192.in-addr.arpa domain name pointer boss. $ host 192.168.100.5 5.0.168.192.in-addr.arpa domain name pointer buhgalter.
To be honest, when parsing logs (and not only in FreeBSD), names are much more convenient than IP addresses.
Finally, we just need to create the primary DNS zone file we support. zone1.com For this in the catalog / etc / namedb / master create a file, for example, with the following configuration:
$ TTL 7200 @ IN SOA ns.mydns.net. hostmaster.ns.mydns.net. (2008020601; Serial 28800; Refresh 7200; Retry 2419200; Expire 86400); Negative Cache TTL; @ IN NS ns.mydns.net. @ IN NS ns1.somedns.net. @ IN NS ns2.somedns.net. @ IN A 212.212.212.212 @ IN MX 1 ASPMX.L.GOOGLE.COM. @ IN MX 5 ALT1.ASPMX.L.GOOGLE.COM. @ IN MX 5 ALT2.ASPMX.L.GOOGLE.COM. @ IN MX 10 ASPMX2.GOOGLEMAIL.COM. @ IN MX 10 ASPMX3.GOOGLEMAIL.COM. @ IN MX 10 ASPMX4.GOOGLEMAIL.COM. @ IN MX 10 ASPMX5.GOOGLEMAIL.COM. www IN CNAME zone1.com. ftp IN A 213.213.213.213
This example shows the entries (fictitious, of course) for the zone zone1.com: mail for this zone is accepted by Google servers (seven MX records - seven servers for receiving mail for this domain); the name itself zone1.com is bound by A record to the host with IP address 212.212.212.212, and www.zone1.com is synonymous with name zone1.com; at the same time, DNS servers are responsible for the zone ns.mydns.net, ns1.somedns.net and ns2.somedns.net... And at the address 213.213.213.213 there may be an FTP server ftp.zone1.com... At least there is a corresponding A record for this name.
Please note that the servers ns1.somedns.net and ns2.somedns.net, or rather, their IP addresses must be specified in the file /etc/namedb/zones.master at " allow-transfer”For this zone.
Pay close attention to dot placement. In general, it is enough to make a mistake in one punctuation mark in the config or zone files and DNS either will not start at all, or the zone will not work correctly.
DNS server configuration is complete. To make it work, add to /etc/rc.conf:
Named_enable \u003d "YES"
Everything else we need is written by default in the /etc/defaults/rc.conf file
# cat /etc/defaults/rc.conf | grep named_uid named_uid \u003d "bind" # User to run named as
Exactly. Named should start only as user bind and by no means from root. Otherwise, you risk becoming a victim of stupidity.
Bind can be started with the native startup script:
# /etc/rc.d/named start Starting named.
In this case, in / var / log / messages, it will write:
Named: starting BIND 9.3.4-P1 -t / var / named -u bind named: command channel listening on 127.0.0.1 # 953
To make sure everything works:
# sockstat | grep named bind named 33696 3 dgram -\u003e / var / run / logpriv bind named 33696 20 udp4 192.168.0.1:53 *: * bind named 33696 21 tcp4 192.168.0.1:53 *: * bind named 33696 22 udp4 127.0.0.1: 53 *: * bind named 33696 23 tcp4 127.0.0.1:53 *: * bind named 33696 24 udp4 XXX.XXX.XXX.XXX:53 *: * bind named 33696 25 tcp4 XXX.XXX.XXX.XXX:53 *: * bind named 33696 26 udp4 *: 53 *: * bind named 33696 27 tcp4 127.0.0.1:953 *: * root syslogd 462 7 dgram / var / named / var / run / log
Bind is running and ready to accept requests on all interfaces. If it does not process them for you, check if you have allowed access to your DNS on the firewall. On port 53 and from it, packets should run freely both over TCP and over UDP.
And finally, a little about how you can control bind with rndc.
- rndc reload - will reload the configuration (if there are no errors in the named.conf configuration)
- rndc stop - will stop the DNS server
- rndc stats - will display statistics of what your DNS has cached
- rndc dump - will throw its cache into the dump file specified in the named.conf config
- rndc flush - will reset its cache to zero
- rndc flushname zona.com - will delete information about the zona.com zone from its cache
- rndc halt - killing named without saving everything that he wanted to save at that moment
- rndc reconfig - will reload the main configuration of the file, as well as the configuration of new zones and a lot of nice and convenient things.
As you can see, there is absolutely nothing complicated in configuring a DNS server. Although, at first it seems to many the opposite.
How helpful was this post?
Click on a star to rate!
No ratings yet! Be the first to rate this post.
We are sorry that this post was not helpful to you!
Let's improve this post!
to send the comment
Thanks for your feedback!
