BIND9/TMP
DNS-Server- BIND9
Domain Name Service (DNS) is an Internet service that maps IP addresses and fully qualified domain names (FQDN) to one another. In this way, DNS alleviates the need to remember IP addresses.
Computers that run DNS are called name servers. Ubuntu ships with BIND (Berkley Internet Naming Daemon), the most widely deployed DNS server.
This guide is aimed at people looking to learn how to configure and maintain a DNS server, such as for a network (caching name server) or to serve DNS zones for a domain name.
Installation
BIND9 is available in the Main repository. No additional repository needs to be enabled for BIND9.
Before we begin, you should be familiar with RootSudo.
To install the server simply install the bind9 package. See InstallingSoftware for details on using package managers.
A very useful package for testing and troubleshooting DNS issues is the dnsutils package. Also, the BIND9 Documentation can be found in the bind9-doc package.
Set up DNS nameservers using BIND9
Just go to your linux console and type the following commands.
yum install bind
Create a new zone file for your domain and insert the sample zone file (see below). You have to change domain.com, serial and email parameters.
nano /var/named/domain.com.db
Open /etc/named.conf and place the following lines:
zone "domain.com" {
type master;
file "/var/named/domain.com.com.db";
};
Save changes to the file and restart bind.
service named restart
BIND9 Configuration Scenarios
BIND9 can provide many different DNS services. Some of the most useful setups are:
Caching Server
In this configuration BIND9 will find the answer to name queries and remember the answer for the next query. This can be useful for a slow internet connection. By caching DNS queries, you will reduce bandwidth and (more importantly) latency.
Primary Master Server
BIND9 can be used to serve DNS records (groups of records are referred to as zones) for a registered domain name or an imaginary one (but only if used on a restricted network).
Secondary Master Server
A secondary master DNS server is used to complement a primary master DNS server by serving a copy of the zone(s) configured on the primary server. Secondary servers are recommended in larger setups. If you intend to serve a registered domain name they ensure that your DNS zone is still available even if your primary server is not online.
Hybrids
You can even configure BIND9 to be a Caching and Primary Master DNS server simultaneously, a Caching and a Secondary Master server or even a Caching, Primary Master and Secondary Master server. All that is required is simply combining the different configuration examples.
Stealth Servers
There are also two other common DNS server setups (used when working with zones for registered domain names), Stealth Primary and Stealth Secondary. These are effectively the same as Primary and Secondary DNS servers, but with a slight organizational difference.
For example, you have 3 DNS servers; A, B and C.
A is the Primary, B and C are secondaries.
If you configure your registered domain to use A and B as your domain's DNS servers, then C is a Stealth Secondary. It's still a secondary, but it's not going to be asked about the zone you are serving to the internet from A and B
If you configure your registered domain to use B and C as your domain's DNS servers, then A is a stealth primary. Any additional records or edits to the zone are done on A, but computers on the internet will only ever ask B and C about the zone.
DNS Record Types
There are lots of different DNS record types, but some of the most common types are covered below.
IP Address Records
The most commonly used type of record. This record maps an IP Address to a hostname.
www IN A 1.2.3.4
Alias Records
Used to create an alias from an existing A record. You can create a CNAME record pointing to another CNAME record. But it doubles the number of requests made to the nameserver, thus making it an inefficient way to do so.
mail IN CNAME www www IN A 1.2.3.4
Mail Exchange Records
Used to define where email should be sent to and at what priority. Must point to an A record, not a CNAME. Multiple MX records can exist if multiple mail servers are responsible for that domain.
IN MX 10 mail.example.com.
[…]
mail IN A 1.2.3.4
Name Server
Used to define which servers serve copies of this zone. It must point to an A record, not a CNAME.
This is where Primary and Secondary servers are defined. Stealth servers are intentionally omitted.
IN NS ns.example.com.
[…]
ns IN A 1.2.3.4
DNS Zonendatei
Sample DNS Zone File for BIND
Use this file to set up your domains and nameservers in BIND9:
;================================================================= ;SAMPLE BIND DNS Zone FILE ;for ANY Domain (Just change domain.com to your site) ;================================================================ ; Before you start DONT FORGET THE DOT AND SERIAL INCREMENT $TTL 14400 $ORIGIN domain.com. ; SOA Record ; Specify Primary nameserver ns1.domain.com ; Serial should increment every update @ 14400 IN SOA ns1.domain.com. webmaster.domain.com. ( 2009092902 ; Serial in YYYYMMDDXX (XX is increment) 10800; refresh seconds 3600; retry 604800; expire 38400; minimum ); ; Website IP Address specified in A record IN A xx.xx.xx.xx ; Minimum 2 DNS nameserver names IN NS ns1.domain.com. IN NS ns2.domain.com. ; Mapping all Nameservers and their corresponding IPs (GLUE)
ns1 IN A xx.xx.xx.xx ns2 IN A xx.xx.xx.xx
; Specify any subdomains and www entry here using CNAME record
www IN CNAME domain.com. ftp IN CNAME domain.com. server IN CNAME domain.com. webmail IN CNAME domain.com.
; Setup MX record (mail exchanger with priority) domain.com. IN MX 10 mail.domain.com.
; set A record for mail mail IN A xx.xx.xx.xx;=====================================
Beispiel: Robot Standard-Template
Nachfolgende Zonendatei wurde für die Domain "grossefirma.de" erstellt:
$TTL 86400
@ IN SOA ns1.first-ns.de. postmaster.robot.first-ns.de. (
2000091604 ; Serial
14400 ; Refresh
1800 ; Retry
604800 ; Expire
86400 ) ; Minimum
@ IN NS ns1.first-ns.de. @ IN NS robotns2.second-ns.de. @ IN NS robotns3.second-ns.com.
localhost IN A 127.0.0.1 @ IN A 1.2.3.4 www IN A 2.3.4.5 mail IN A 2.3.4.5
loopback IN CNAME localhost pop IN CNAME www smtp IN CNAME www relay IN CNAME www imap IN CNAME www ftp 3600 IN CNAME ftp.anderedomain.de.
@ IN MX 10 mail
technik IN A 5.6.7.8 technik IN MX 10 technik
@ IN TXT "v=spf1 mx -all"
SOA-Record
$TTL 86400
@ IN SOA ns1.first-ns.de. postmaster.robot.first-ns.de. (
2000091604 ; Serial
14400 ; Refresh
1800 ; Retry
604800 ; Expire
86400 ) ; Minimum* Die TTL (Time To Live) der Zone beträgt 86400 Sekunden ($TTL 86400)
- Für die Internet-Domäne (das Zeichen @ ist Platzhalter für die Domäne "grossefirma.de" selbst) ist der Nameserver "ns1.first-ns.de" zuständig
- Der Punkt am Ende von "ns1.first-ns.de." verhindert, dass der primäre Nameserver "ns1.first-ns.de.grossefirma.de" genannt wird
- Der Administrator hat die E-Mailadresse "postmaster@robot.first-ns.de" (der erste Punkt wird immer durch das @-Zeichen ersetzt)
- Die Zonendatei wurde zuletzt am 16.09.2000 geändert, dies war die 4. Änderung an jenem Tag
- Der sekundäre Nameserver übernimmt alle 4 Stunden (TTL = 14.400 Sekunden; Time To Live) Änderungen vom primären Nameserver
- Im Fehlerfall versucht der sekundäre Nameserver den Abgleich nach 30 Minuten (1800 Sekunden) erneut
- Sollte der sekundäre Nameserver nach 7 Tagen (604800 Sekunden) keinen Abgleich mit dem primären Nameserver geschafft haben, erklärt er die Domain für ungültig
- Die Einträge sind normalerweise 24 Stunden (86400 Sekunden) gültig, falls kein anderer Wert definiert wird
- Andere Nameserver merken sich "negative" Antworten, also Anfragen nach nicht existierenden Hosts ebenfalls 24 Stunden
Nameserver
@ IN NS ns1.first-ns.de.
@ IN NS robotns2.second-ns.de. @ IN NS robotns3.second-ns.com.* Zuständig für die Nameserver sind "ns1.first-ns.de", "robotns2.second-ns.de" und "robotns3.second-ns.com"
- Der Punkt am Ende der Zeilen verhindert auch hier die Suche nach "ns1.first-ns.de.grossefirma.de", was in diesem Fall unsinnig wäre
- IP-Adressen sind in NS-Records nicht erlaubt (wird ein eigener Nameserver verwendet, dessen Hostname "ns1.grossefirma.de" lauten soll: Zusätzlich passenden A-Record definieren und Glue bei der Domainregistation angeben bzw. die Nameserver vorher bei den Registraren registrieren).
Hosts
localhost IN A 127.0.0.1 @ IN A 1.2.3.4 www IN A 2.3.4.5 mail IN A 2.3.4.5* "localhost.grossefirma.de" wird zur Loopback-Adresse "127.0.0.1" aufgelöst
- Anfagen z. B. im Webbrowser nach "grossefirma.de" (ohne "www.") werden nach "1.2.3.4" aufgelöst
- "www.grossefirma.de" hat die IP-Adresse "2.3.4.5"
- Es existiert ein Host mit dem Namen "mail.grossefirma.de", aber ob dieser auch der zuständige Mailserver ist, geht aus diesem Eintrag nicht hervor
Aliase
loopback IN CNAME localhost pop IN CNAME www smtp IN CNAME www relay IN CNAME www imap IN CNAME www ftp 3600 IN CNAME ftp.anderedomain.de.* "localhost.grossefirma.de" kann auch als "loopback.grossefirma.de" angesteuert werden
- "www.grossefirma.de" hat die zusätzlichen Namen "pop.grossefirma.de", "smtp.grossefirma.de", "relay.grossefirma.de" und "imap.grossefirma.de"
- "ftp.grossefirma.de" wird weitergeleitet zu "ftp.anderedomain.de", da der Punkt am Ende die Auflösung nach "ftp.anderedomain.de.grossefirma.de" verhindert
- "ftp.grossefirma.de" hat eine Gültigkeit von nur 1 Stunde (3600 Sekunden), daher sind Änderungen in den Einträgen relativ schnell bei den Nameservern im weltweiten Internet bekannt. Wichtig: solange der sekundäre Nameserver noch die veralteten Werte publiziert, verzögert sich eine eventuelle Änderung der Daten, daher sollte evtl. auch die Refresh-Zeit im SOA-Record verkürzt werden
Hinweis: Ist für eine Subdomain bereits ein CNAME-Record definiert, können für diese Subdomain keine weiteren Record-Typen gesetzt werden.
Mailserver
@ IN MX 10 mail* Es gibt nur einen Mailserver und das ist "mail.grossefirma.de"
- IP-Adressen sind bei MX-Records nicht erlaubt
- CNAME's sind in MX-Records nicht erlaubt, nur Verweise auf A-Records
- Weitere Mailserver könnten in eine zusätzliche Zeile eingetragen werden, dies ist aber oft nicht sinnvoll
- Bei mehreren Mailservern würde der mit der geringeren Priorität (hier 10) bevorzugt verwendet
"Subdomain"
technik IN A 5.6.7.8
technik IN MX 10 technik* Es ist innerhalb der Zonendatei eine "Subdomain" angelegt, allerdings ohne Delegation an einen externen Nameserver.
- Für die Subdomain "technik.grossefirma.de" ist der Host "technik.grossefirma.de" zuständig, der zur IP-Adresse 5.6.7.8 auflöst.
TXT records
@ IN TXT "v=spf1 mx -all"* Für "grossefirma.de" existiert ein TXT record mit dem Inhalt "v=spf1 mx -all"
- Nutzung beispielsweise für SPF (Sender Policy Framework)
Delegation einer Subdomain
Alternativ zum unter "Subdomain" beschriebenen Vorgehen, ist eine Delegation von Subdomains an einen anderen DNS-Server möglich.
Hinweis: Im Robot ist es nicht möglich, DNS-Zonen für Subdomains anzulegen! Hier können Subdomains nur wie im Abschnitt "Subdomain" beschrieben definiert werden.
Beispiel: Zu Testzwecken soll eine Subdomain für die Abteilung "Technik" einer großen Firma angelegt werden, die dann für kurzfristige interne Tests etc. verwendet werden kann. Die DNS-Einträge der Subdomain sollen unabhängig von den Einträgen der Domäne "grossefirma.de" verwaltet werden (die evtl. ein grosser und unflexibler Provider hostet).
Vorbereiten der Haupt-Domain
In der Zonendatei der Domain "grossefirma.de" werden folgende Einträge ergänzt:
technik IN NS ns.technik
ns.technik IN A 5.6.7.8
Hier werden Nameserveranfragen nach beispielsweise "www.technik.grossefirma.de" an "ns.technik.grossefirma.de" weitergeleitet. Da dieser Hostname ja selbst von eben diesem Nameserver aufgelöst werden müsste, wird in der übergeordneten Domain ein "Glue-Record" eingetragen: ns.technik.grossefirma.de --> 5.6.7.8.
Zonendatei für die neue Subdomain
Am neuen Nameserver muss nun noch eine Zonendatei für die neue Subdomain angelegt werden:
@ 86400 IN SOA ns1 admin (
2000091604 ; Serial
14400 ; Refresh
1800 ; Retry
604800 ; Expire
86400 ) ; Minimum
@ IN NS ns.technik ns IN A 5.6.7.8
@ IN MX 10 mail mail IN A 2.3.4.5
www IN A 2.3.4.5
Der Administrator hat die Mailadresse "admin@technik.grossefirma.de". * Der primäre Nameserver hat den Hostnamen "ns.technik.grossefirma.de".
- Es ist der einzige Nameserver (kein sekundärer Nameserver vorhanden).
- Er hat die IP-Adresse "5.6.7.8".
- Ein Host namens "mail.technik.grossefirma.de" mit der IP-Adresse "2.3.4.5" existiert und ist gleichzeitig zuständig für den Mailempfang der Subdomain.
- Es gibt einen weiteren Host mit Namen "www.technik.grossefirma.de", der zu "2.3.4.5" auflöst.
SOA Resource Record
SOA bedeutet Start of Authority (dt. Beginn der Zuständigkeit) und ist wichtiger Bestandteil einer Zonendatei im Domain Name System (DNS). Ein SOA-Record enthält wichtige Angaben zur Verwaltung der Zone, insbesondere zum Zonentransfer. Spezifiziert ist der SOA-Typ in RFC 1035.
Hintergrund
Üblicherweise werden DNS-Nameserver in Clustern aufgebaut. Der Datenbestand innerhalb eines Clusters wird mittels Zonentransfers synchronisiert. Der SOA-Eintrag in der Zonendatei (also in der Datei zur vollständigen Konfiguration und Beschreibung der Zone) enthält Daten, mit denen der Zonentransfer gesteuert wird. Es handelt sich dabei um die Seriennummer und verschiedene Timer.
Außerdem sind die E-Mail-Adresse des Verantwortlichen für diese Zone sowie der Name des primary Master-Servers aufgeführt. Normalerweise steht ein SOA-Record am Anfang der Datei. Eine Zone ohne diesen Eintrag erfüllt nicht den DNS-Standard und kann nicht transferiert werden.
Aufbau
Name
der Zone
IN
Zonenklasse (meist IN für Internet)
SOA
Kürzel für Start Of Authority
Primary
Primary Master für diese Zone, hat in der Praxis nur geringe Bedeutung:
- er definiert, an wen dynamische Updates gesendet werden sollen (siehe: Dynamisches Update)
- er gibt an, an wen keine Notifies gesendet werden (siehe: Zonentransfer)
Mail-Adresse
des Verantwortlichen für diese Zone. (Das @ wird durch . ersetzt. Punkte vor dem @ werden durch \. ersetzt; beispielsweise max\.mustermann.wikipedia.org für die E-Mail-Adresse max.mustermann@wikipedia.org)
Seriennummer
wird bei jeder Änderung inkrementiert (vorzugsweise JJJJMMTTVV; dient als Hinweis, wann die Zone zuletzt aktualisiert wurde[1])
Refresh
Sekundenabstand, in dem sekundäre Nameserver die Seriennummer vom primären Master abfragen sollen, um Änderungen der Zone festzustellen.[2] Empfehlung vom RIPE NCC für kleine und stabile Zonen: 86400 ≙ 24 Stunden.[1]
Retry
Sekundenabstand, in dem bei ausbleibender Antwort des Masters sekundäre Nameserver nochmals seine Seriennummer abfragen sollen. Dieser Wert muss kleiner als jener zum Refresh sein. Empfehlung vom RIPE NCC für kleine und stabile Zonen: 7200 ≙ 2 Stunden.[1]
Expire
Sekundenabstand, nach dem bei ausbleibender Antwort des Masters sekundäre Nameserver keine Antworten über die Zone mehr geben sollen. Dieser Wert muss größer als die Summe jener zum Refresh und Retry sein. Empfehlung vom RIPE NCC für kleine und stabile Zonen: 3600000 ≙ 1000 Stunden.[1]
TTL
Time to Live für Negatives Caching (Empfehlung vom RIPE NCC für kleine und stabile Zonen: 172800 ≙ 2 Tage[1]). Ursprünglich hatte dieses Feld die Bedeutung eines Minimum-TTL-Werts für alle Resource Records der Zone[3] und wurde in der Praxis als Standardwert verwendet, wenn bei einem Resource Record kein TTL-Wert angegeben war; diese Bedeutung wurde mit RFC 2308 abgeschafft.[4]
Beispiel eines SOA-Records in BIND
@ IN SOA master.example.com. hostmaster.example.com. (
2014031700 ; serial
3600 ; refresh
1800 ; retry
604800 ; expire
600 ) ; ttl
In diesem Beispiel wird festgelegt, dass sich ein Slave alle 3600 Sekunden mit seinem Master per Zonentransfer synchronisiert. Ist sein Master nicht erreichbar, wird alle 1800 Sekunden ein neuer Versuch gestartet. Kann der Master innerhalb von 604800 Sekunden (einer Woche) nicht kontaktiert werden, so erklärt der Slave die Zone example.com als inaktiv und beantwortet keine diesbezüglichen DNS-Requests mehr. DNS cached auch fehlgeschlagene Request. Die TTL beträgt 600 Sekunden.
Weiterhin wird definiert, dass der Primary Master dieser Zone master.example.com ist und dass der Administrator über die E-Mail-Adresse hostmaster@example.com erreichbar ist. Das @ muss durch einen . ersetzt werden. Kommt ein . vor dem @, z. B. vorname.nachname@example.com, so wird dieser mit einem \ maskiert – also z. B. vorname\.nachname.example.com.
Die Seriennummer beträgt zur Zeit 2014031700. Bei der nächsten Änderung muss sie (manuell) auf mindestens 2014031701 erhöht werden. Dabei hat sich die Konvention eingebürgert, das Datum in der Form Jahr-Monat-Tag sowie einen nachfolgenden zweistelligen Versionszähler als Seriennummer zu verwenden.
Änderung der Seriennummer
Beim Ändern der Seriennummern haben sich zwei Verfahren etabliert:
- Man beginnt bei 1 und erhöht bei jeder Änderung.
- Man trägt das aktuelle Datum mit einem zweistelligen Zähler (zum Beispiel 2004052101 = 21. Mai 2004, erste Änderung an diesem Tag), seltener auch der Uhrzeit ein. Dieses Vorgehen wird in RFC 1912 2.2 empfohlen.
Einzelnachweise
- Peter Koch: Recommendations for DNS SOA Values. RIPE Network Coordination Centre, 7. Juni 1999, abgerufen am 4. März 2016: „These recommendations are aimed at small and stable DNS zones.“
- RFC 1912 - Common DNS Operational and Configuration Errors. Februar 1996, abgerufen am 4. März 2016.
- RFC 1035 – Domain Names – Implementation and Specification
- RFC 2308 – Negative Caching of DNS Queries (DNS NCACHE)
Recommended DNS SOA record TTL
We currently have our DNS SOA record set to the following for stackoverflow.com:
primary name server = ns1.p19.dynect.net
serial = 2009090909
refresh = 3600 (1 hour)
retry = 600 (10 mins)
expire = 604800 (7 days)
default TTL = 60 (1 min)
Are there better choices for our refresh / retry / expire / default TTL for a site like stackoverflow.com which receives close to 1M pageviews per day?
Answers
All of those settings (except for "default TTL") only affect how frequently your domain's secondary DNS servers poll the primary DNS server for updates.
If your zone only changes infrequently (which I believe yours does) then your value for "refresh" is currently a bit on the low side. Typically the primary should send a NOTIFY message to each of the secondaries whenever there's an update at which point the secondaries grab the zone file immediately. These days the "refresh / retry / expire" mechanism is only a backstop to that.
In any event, it's likely that your DNS provider is automatically syncing changes to all of the relevant DNS servers on the fly without using DNS's built-in synchronisation mechanisms so the actual values are probably irrelevant.
Note that the "default TTL" field no longer means what it says. The real default TTL is set (in BIND at least) with the $TTL directive, and that's only used when there isn't an explicit TTL set on each record.
The "default TTL" field's meaning was changed in RFC 2308 and it's actually a hint for negative caching. If your server returns a negative response (e.g. NXDOMAIN or NODATA) it's how long the remote server should wait before trying again.
The current value is a bit on the low side, but there's no harm leaving it as is. It's often ignored anyway. Interestingly, the DNS diagnostic page from the dyn guys (our DNS hosts)..http://dnscog.com/report/stackoverflow.com
Check SOA MINTTL
Your SOA minttl value is 60 seconds, which is lower than the recommended minimum for general DNS use. If you regularly make changes to your DNS zone, or use DNS-based load balancing services, a small value here is OK.
Recommendation
Consider putting value between 1800 and 86400 to your SOA minttl field.
and this on SOA refresh
Check SOA refresh
Your SOA refresh field is 3600 seconds, which is lower than the recommended minimum. Having a low refresh value can result in unnecessary query volume or unexpected behavior, especially if you use a value of 0. If you regularly make changes to your DNS zone, or use DNS-based load balancing services, a smaller value will help to ensure changes propagate as quickly as possible.
Recommendation
Consider putting value between 7200 and 10800 to your SOA refresh field.
Another diagnostic page at http://www.intodns.com/stackoverflow.com doesn't offer any real hints.
Their minttl recommendation is bogus. That field hasn't had that meaning for over a decade. Their explanation of refresh is also suspect. The refresh interval only affects primary -> secondary slaving, and with a small zone like yours this value would cause no problems whatsoever. Furthermore if the DNS provider is using an out-of-band sync mechanism then the actual value is moot. (NB: I do DNS for a living) – Alnitak Sep 29 '09 at 8:46
p.s. if someone actually gave this as their own explanation and recommendation for the values I'd give it a -1 vote. As you're quoting someone else I won't ;-) – Alnitak Sep 29 '09 at 12:56
To clarify, the SOA Minimum TTL field stores the TTL value to be used to cache a negative request - a request made to the zone for some resource which doesn't exist. Their explanation is sort of true but fails to clarify it's only for negative responses. Secondly, the SOA Refresh is never used by normal DNS queries, it's only used in situations where you have secondary (slave) nameservers updating themselves from your primary (master) nameserver. So their explanation of that field is definitely untrue. – thomasrutter Dec 4 '12 at 12:10
Really, there is so much misinformation about what these records mean online that it's hard to find anything that's actually true. In summary, most of the values in the SOA record are meaningless for actual DNS queries, and are intended instead for you to use for your own internal zone transfer mechanism from your primary to secondary nameservers. The exception is the MinTTL but that isn't, as the standards suggest, minimum TTL nor is it a "default" TTL, but instead a suggested TTL for caching negative results. What matters much more are the individual TTLs for records like A and NS. – thomasrutter Jun 21 '14 at 12:47
All those intodns / dnscog / dnsstuff etc type sites just copy the same misinformation from each other. You can tell because a lot of their text is copy-pasted. I've found MXToolbox (mxtoolbox.com/DNSCheck.aspx) to be a more reliable resource. For example, their explanation of the SOA MINTTL value here is accurate - a rare quality. –
SOA TTL recommended >= 3600. SOA refresh recommended >= 14400. SOA retry recommended >= 3600. SOA expire recommended >= 604800. SOA minimum recommended between 300 and 86400.
Configuring BIND9
BIND9 Configuration files are stored in:
/etc/bind/
The main configuration is stored in the following files:
/etc/bind/named.conf
/etc/bind/named.conf.options /etc/bind/named.conf.local
Caching Server configuration
The default configuration is setup to act as a caching server. All that is required is simply adding the IP numbers of your ISP's DNS servers.
Simply uncomment and edit the following in /etc/bind/named.conf.options:
[…]
forwarders {
1.2.3.4;
5.6.7.8;
};
[...]
(where 1.2.3.4 and 5.6.7.8 are the IP numbers of your ISP's DNS servers)
Now restart the bind daemon:
sudo /etc/init.d/bind9 restart
Testing
If you installed the dnsutils package you can test your setup using the dig command:
dig -x 127.0.0.1
If all goes well you should see output similar to:
; <<>> DiG 9.4.1-P1 <<>> -x 127.0.0.1 ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13427 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
[…]
;; Query time: 1 msec ;; SERVER: 172.18.100.80#53(172.18.100.80) ;; WHEN: Mon Nov 26 23:22:53 2007 ;; MSG SIZE rcvd: 93
The dig command can also be used to query other domains for example:
dig google.com
If you "dig" a domain name multiple times you should see a drastic improvement in the Query time: between the first and second query. This is due to the server caching the query.
Primary Master Server configuration
In this section BIND9 will be configured as the primary master for the domain example.com. Simply replace example.com with your fully qualified domain name.
Zone File
To add a DNS zone to BIND9, turning BIND9 into a Primary Master server, all you have to do is edit named.conf.local:
[…]
zone "example.com" {
type master;
file "/etc/bind/db.example.com";
};
[...]
Now use an existing zone file as a template:
sudo cp /etc/bind/db.local /etc/bind/db.example.com
Edit the new zone file /etc/bind/db.example.com change localhost. to the FQDN of your server, leaving the additional "." at the end. Change 127.0.0.1 to the nameserver's IP Address and root.localhost to a valid email address, but with a "." instead of the "@". also leaving the "." at the end.
Also, create an A record for ns.example.com the name server in this example:
;
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns.example.com. root.example.com. (
1 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns.example.com.
ns IN A 192.168.1.10
;also list other computers box IN A 192.168.1.21
You must increment the serial number every time you make changes to the zone file. If you make multiple changes before restarting BIND9, simply increment the serial once.
Now, you can add DNS records to the bottom of the zone.
Tip: Many people like to use the last date edited as the serial of a zone, such as 2005010100 which is yyyymmddss (where s is serial)
Once you've made a change to the zone file BIND9 will need to be restarted for the changes to take effect:
sudo /etc/init.d/bind9 restart
Reverse Zone File
Now that the zone file is setup and resolving names to IP Adresses a Reverse zone is also required. A Reverse zone allows DNS to convert from an address to a name.
Edit /etc/bind/named.conf.local and add the following:
zone "1.168.192.in-addr.arpa" {
type master;
notify no;
file "/etc/bind/db.192";
};
Note: replace 1.168.192 with the first three octets of whatever private network you are using. Also, name the zone file db.192 in the example appropriately.
Now create the db.192 file:
sudo cp /etc/bind/db.127 /etc/bind/db.192
Next edit /etc/bind/db.192 changing the basically the same options as in /etc/bind/db.example.com:
;
; BIND reverse data file for local loopback interface
;
$TTL 604800
@ IN SOA ns.example.com. root.example.com. (
2 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns.
10 IN PTR ns.example.com.
; also list other computers 21 IN PTR box.example.com.
The serial number in the reverse zone needs to be incremented on each changes as well. For each A record you configure in /etc/bind/db.example.com you need to create a PTR record in /etc/bind/db.192.
After creating the reverse zone file restart bind9:
sudo /etc/init.d/bind9 restart
Testing
You should now be able to ping example.com and have it resolve to the host configured above:
ping example.com
You can also use the named-checkzone utility that is part of the bind9 package:
named-checkzone example.com /etc/bind/db.example.com
and
named-checkzone 1.168.192.in-addr.arpa. /etc/bind/db.192
This is a great way to make sure you haven't made any mistakes before restarting bind9.
You can use the dig utility to test the reverse zone as well as the new domain name:
dig 1.168.192.in-addr.arpa. AXFR
You should see output resolving 1.168.192.in-addr.arpa. to your nameserver.
Secondary Master Server configuration
Once a Primary Master has been configured a Secondary Master is needed in order to maintain the availability of the domain should the Primary become unavailable.
First, on the primary master server, the zone transfer needs to be allowed. Add the allow-transfer option to the sample Forward and Reverse zone definition in /etc/bind/named.conf.local:
[…]
zone "example.com" {
type master;
file "/etc/bind/db.example.com";
allow-transfer { @ip_secondary; };
};
[…]
zone "1.168.192.in-addr.arpa" {
type master;
notify no;
file "/etc/bind/db.192";
allow-transfer { @ip_secondary; };
};
[...]
Note: replace @ip_secondary with the actual IP Address of your secondary server.
Next, on the Secondary Master, install the bind9 package the same way as the primary. Then edit the /etc/bind/named.conf.local and add the following declarations for the Forward and Reverse zones:
[…]
zone "example.com" {
type slave;
file "/var/cache/bind/db.example.com";
masters { @ip_master; };
};
[…]
zone "1.168.192.in-addr.arpa" {
type slave;
file "/var/cache/bind/db.192";
masters { @ip_master; };
};
[...]
Note: replace @ip_master with the IP Address of the Primary. The zone file must be in /var/cache/bind/ because, by default, AppArmor only allows write access inside it (this was made specifically for a slave configuration. See AppArmor's configuration in /etc/apparmor.d/usr.sbin.named).
Restart the server, and in /var/log/syslog you should see something similar to:
syslog.5.gz:May 14 23:33:53 smith named[5064]: zone example.com/IN: transferred serial 2006051401 syslog.5.gz:May 14 23:33:53 smith named[5064]: transfer of 'example.com/IN' from 10.0.0.202#53: end of transfer syslog.5.gz:May 14 23:33:35 smith named[5064]: slave zone "1.168.192.in-addr.arpa" (IN) loaded (serial 2006051401)
Note: A zone is only transfered if the Serial Number on the Primary is larger than the one on the Secondary.
Testing
Testing the Secondary Master can be done using the same methods as the Primary. Also, you could shutdown BIND9 on the Primary then try pinging example.com from a host configured to use the Secondary as well as the Primary for name resolution. If all goes well the Secondary should resolve example.com.
Chroot
Chrooting BIND9 is a recommended setup from a security perspective if you don't have AppArmor installed. In a chroot enviroment, BIND9 has access to all the files and hardware devices it needs, but is unable to access anything it should not need. AppArmor is installed by default on recent Ubuntu releases. Unless you've explicitly disabled AppArmor, you might want to read this before you decide to attempt a chrooted bind. If you still want to go forward with it, you'll need this information, which isn't covered in the instructions that follow here.
To chroot BIND9, simply create a chroot enviroment for it and add the additional configuration below
Chroot Enviroment
Create the following directory structure
# mkdir -p /chroot/named $ cd /chroot/named # mkdir -p dev etc/namedb/slave var/run
Set permissions for chroot environment
# chown root:root /chroot # chmod 700 /chroot # chown bind:bind /chroot/named # chmod 700 /chroot/named
Create or move the bind configuration file.
# touch /chroot/named/etc/named.conf
or
# cp /etc/bind/named.conf /chroot/named/etc
Give write permissions to the user bind for /chroot/named/etc/namedb/slave directory.
# chown bind:bind /chroot/named/etc/namedb/slave
This is where the files for all slave zones will be kept. This increases security, by stopping the ability of an attacker to edit any of your master zone files if they do gain access as the bind user. Accordingly, all slave file names in the /chroot/named/etc/named.conf file will need to have directory names that designate the slave directory. An example zone definition is listed below.
zone "my.zone.com." {
type slave;
file "slaves/my.zone.com.dns";
masters {
10.1.1.10;
};
};
Create the devices BIND9 requires
# mknod /chroot/named/dev/null c 1 3 # mknod /chroot/named/dev/random c 1 8
Give the user bind access to the /chroot/named/var/run directory that will be used to strore PID and statistical data.
# chown bind:bind /chroot/named/var/run
BIND9's Configuration
Edit the bind startup options found in /etc/default/bind9. Change the line the reads:
/etc/default/bind9:
OPTIONS="-u bind"
So that it reads
/etc/default/bind9:
OPTIONS="-u bind -t /chroot/named -c /etc/named.conf"
The -t option changes the root directory from which bind operates to be /chroot/named. The -c option tells Bind that the configuration file is located at /etc/named.conf. Remember that this path is relative to the root set by -t.
The named.conf file must also recieve extra options in order to run correctly below is a minimal set of options:
/chroot/named/etc/named.conf:
options {
directory "/etc/namedb";
pid-file "/var/run/named.pid";
statistics-file "/var/run/named.stats";
};
Ubuntu's syslod Daemon Configuration
/etc/init.d/sysklogd:
[…]
SYSLOGD="-u syslog -a /chroot/named/dev/log"
[...]
(Author Note: Check this config)
Restart the syslog server and BIND9
# /etc/init.d/sysklogd restart # /etc/init.d/bind9 restart
At this point you should check /var/log/messages for any errors that may have been thrown by bind.
Starting, Stopping, and Restarting BIND9
Use the following command to start BIND9 :
# /etc/init.d/bind9 start
To stop it, use :
# /etc/init.d/bind9 stop
Finally, to restart it, run
# /etc/init.d/bind9 restart
Status
To check the status of your BIND9 installation:
$ host localhost
or
$ dig @localhost
(where localhost is the system you are setting BIND9 up on. If not localhost, use the appropriate IP number.)
Logging
BIND9 has a wide variety of logging configuration options available. There are two main options to BIND9 logging the channel option configures where logs go, and the category option determines what to log.
If no logging option is configured for the default option is:
logging {
category default { default_syslog; default_debug; };
category unmatched { null; };
};
Next we will configure BIND9 to send debug messages related to DNS queries to a separate file.
Channel Option
First, we need to configure a channel to specify which file to send the messages to. Edit /etc/bind/named.conf.local and add the following:
logging {
channel query.log {
file "/var/log/query.log";
// Set the severity to dynamic to see all the debug messages.
severity dynamic;
};
};
Category Option
Next, configure a category to send all DNS queries to the query file:
logging {
channel query.log {
file "/var/lib/bind/query.log";
// Set the severity to dynamic to see all the debug messages.
severity debug 3;
};
category queries { query.log; };
};
Note: the debug option can be set from 1 to 3. If a level isn't specified level 1 is the default.
Now restart BIND9 for the changes to take affect:
# /etc/init.d/bind9 restart
You should see the file /var/log/query.log fill with BIND9 log information. This is a simple example of the BIND9 logging options available see bind9.net manual for more information.
Slave Name Server
You need to set up another name server for robustness. You can (and probably will eventually) set up more than two authoritative name servers for your zones. Two name servers are the minimum -- if you have only one name server and it goes down, no one can look up domain names.
A second name server splits the load with the first server or handles the whole load if the first server is down. You could set up another primary master name server, but we don't recommend it. Instead, set up a slave name server. You can always change a slave name server into a primary master name server later if you decide to expend the extra effort it takes to run multiple primary master name servers.
How does a server know if it's the primary master or a slave for a zone? The named.conf file tells the name server whether it is the primary master or a slave on a per-zone basis. The NS records don't tell us which server is the primary master for a zone and which servers are slaves -- they only say who the servers are. (Globally, DNS doesn't care; as far as the actual name resolution goes, slave servers are as good as primary master servers.)
What's the difference between a primary master name server and a slave name server? The crucial difference is where the server gets its data. A primary master name server reads its data from zone data files. A slave name server loads its data over the network from another name server. This process is called a zone transfer.
A slave name server is not limited to loading zones from a primary mastername server; it can also load from another slave server.
The big advantage of slave name servers is that you maintain only one set of zone data files for a zone, the ones on the primary master name server. You don't have to worry about synchronizing the files among name servers; the slaves do that for you. The caveat is that a slave does not resynchronize instantly -- it polls to see if its zone data is current. The polling interval is one of those numbers in the SOA record that we haven't explained yet. (BIND Versions 8 and 9 support a mechanism to speed up the distribution of zone data, which we'll describe later.)
A slave name server doesn't need to retrieve all its zone data over the network; the overhead files, db.cache and db.127.0.0, are the same as on a primary master, so keep a local copy on the slave. That means that a slave name server is a primary master for 0.0.127.in-addr.arpa. Well, you could make it a slave for 0.0.127.in-addr.arpa, but that zone's data never changes -- it may as well be a primary master.
Setup
To set up your slave name server, create a directory for the zone data files on the slave name server host (e.g., /var/named ) and copy over the files /etc/named.conf, db.cache, and db.127.0.0 :
# rcp /etc/named.conf host:/etc # rcp db.cache db.127.0.0 host:db-file-directory
You must modify /etc/named.conf on the slave name server host. For BIND 4, change every occurrence of primary to secondary except for the 0.0.127.in-addr.arpa zone. Before the filename on each of these lines, add the IP address of the primary master server you just set up. For example, if the original BIND 4 configuration file line was this:
primary movie.edu db.movie.edu
then the modified line looks like this:
secondary movie.edu 192.249.249.3 db.movie.edu
If the original BIND 8 or 9 configuration file line was:
zone "movie.edu" in {
type master;
file "db.movie.edu";
};
change master to slave and add a masters line with the IP address of the master server:
zone "movie.edu" in {
type slave;
file "bak.movie.edu";
masters { 192.249.249.3; };
};
This tells the name server that it is a slave for the zone movie.edu and that it should track the version of this zone kept on the name server at 192.249.249.3. The slave name server keeps a backup copy of this zone in the local file bak.movie.edu.
For Movie U., we set up our slave name server on wormhole.movie.edu. Recall that the configuration file on terminator.movie.edu (the primary master) looks like this:
directory /var/named
primary movie.edu db.movie.edu primary 249.249.192.in-addr.arpa db.192.249.249 primary 253.253.192.in-addr.arpa db.192.253.253 primary 0.0.127.in-addr.arpa db.127.0.0 cache . db.cache
We copy /etc/named.conf, db.cache, and db.127.0.0 to wormhole.movie.edu, and edit the configuration file as previously described. The BIND 4 configuration file on wormhole.movie.edu now looks like this:
directory /var/named
secondary movie.edu 192.249.249.3 bak.movie.edu secondary 249.249.192.in-addr.arpa 192.249.249.3 bak.192.249.249 secondary 253.253.192.in-addr.arpa 192.249.249.3 bak.192.253.253 primary 0.0.127.in-addr.arpa db.127.0.0 cache . db.cache
The equivalent BIND 8 or 9 configuration file looks like this:
options {
directory "/var/named";
};
zone "movie.edu" in {
type slave;
file "bak.movie.edu";
masters { 192.249.249.3; };
};
zone "249.249.192.in-addr.arpa" in {
type slave;
file "bak.192.249.249";
masters { 192.249.249.3; };
};
zone "253.253.192.in-addr.arpa" in {
type slave;
file "db.192.253.253";
masters { 192.249.249.3; };
};
zone "0.0.127.in-addr.arpa" in {
type master;
file "db.127.0.0";
};
zone "." in {
type hint;
file "db.cache";
};
This causes the name server on wormhole.movie.edu to load movie.edu, 249.249.192.in-addr.arpa, and 253.253.192.in-addr.arpa over the network from the name server at 192.249.249.3 (terminator.movie.edu). It also saves a backup copy of these files in /var/named. You may find it handy to isolate the backup zone data files in a subdirectory. We name them with a unique prefix like bak, since on rare occasions, we may have to delete all of the backup files manually. It's also helpful to be able to tell at a glance that they're backup zone data files so that we're not tempted to edit them. We'll cover more on backup files later.
Now start up the slave name server. Check for error messages in the syslog file as you did for the primary master server. As on the primary master, the command to start up a name server is:
# /usr/sbin/named
One extra check to make on the slave that you didn't have to make on the primary master is to see that the name server created the backup files. Shortly after we started our slave name server on wormhole.movie.edu, we saw bak.movie.edu, bak.192.249.249, and bak.192.253.253 appear in the /var/named directory. This means the slave has successfully loaded these zones from the primary master and saved a backup copy.
To complete setting up your slave name server, try looking up the same domain names you looked up after you started the primary master server. This time, you must run nslookup on the host running the slave name server so that the slave server is queried. If your slave is working fine, add the proper lines to your system startup files so that the slave name server is started when your system boots up and hostname(1) is set to a domain name.
Backup Files
Slave name servers are not required to save a backup copy of the zone data. If there is a backup copy, the slave server reads it on startup and later checks with the master server to see if the master server has a newer copy instead of loading a new copy of the zone immediately. If the master server has a newer copy, the slave pulls it over and saves it in the backup file.
Why save a backup copy? Suppose the master name server is down when the slave starts up. The slave will be unable to transfer the zone and therefore won't function as a name server for that zone until the master server is up. With a backup copy, the slave has zone data, although it might be slightly out of date. Since the slave does not have to rely on the master server always being up, it's a more robust setup.
To run without a backup copy, omit the filename at the end of the secondary lines in the BIND 4 configuration file. In BIND 8 or 9, remove the file line. However, we recommend configuring all your slave name servers to save backup copies. There is very little extra cost to saving a backup zone data file, but there is a very high cost if you get caught without a backup file when you need it most.
SOA Values
Remember this SOA record?
movie.edu. IN SOA terminator.movie.edu. al.robocop.movie.edu. (
1 ; Serial
3h ; Refresh after 3 hours
1h ; Retry after 1 hour
1w ; Expire after 1 week
1h ) ; Negative caching TTL of 1 day
We never explained what the values between the parentheses were for.
The serial number applies to all the data within the zone. We chose to start our serial number at 1, a logical place to start. But many people find it more useful to use the date in the serial number instead, like 1997102301. This format is YYYYMMDDNN, where YYYY is the year, MM is the month, DD is the day, and NN is a count of how many times the zone data was modified that day. These fields won't work in any other order, since no other order gives a value that always increases as the date changes. This is critical: whatever format you choose, it's important that the serial number always increase when you update your zone data.
When a slave name server contacts a master server for zone data, it first asks for the serial number on the data. If the slave's serial number for the zone is lower than the master server's, the slave's zone data is out of date. In this case, the slave pulls a new copy of the zone. If a slave starts up and there is no backup file to read, it will always load the zone. As you might guess, when you modify the zone data files on the primary master, you must increment the serial number. Updating your zone data files is covered in Chapter 7, "Maintaining BIND".
The next four fields specify various time intervals, in seconds by default:
refresh
The refresh interval tells a slave for the zone how often to check that the data for this zone is up to date. To give you an idea of the system load this feature causes, a slave makes one SOA query per zone per refresh interval. The value we chose, three hours, is reasonably aggressive. Most users will tolerate a delay of half a working day for things like zone data to propagate when they are waiting for their new workstation to become operational. If you provide one-day service for your site, you could consider raising this value to eight hours. If your zone data doesn't change very often or if all of your slaves are spread over long distances (as the root name servers are), consider a value that is even longer, say 24 hours.
retry
If the slave fails to reach the master name server after the refresh interval (the host could be down), it starts trying to connect every retry seconds. Normally, the retry interval is shorter than the refresh interval, but it doesn't have to be.
expire
If the slave fails to contact the master name server for expire seconds, the slave expires the zone. Expiring the zone means that the slave stops giving out answers about the zone because the zone data is too old to be useful. Essentially, this field says that at some point, the data is so old that giving out no data is better than giving out stale data. Expire times on the order of a week are common -- longer (up to a month) if you frequently have problems reaching your updating source. The expiration time should always be much larger than the retry and refresh intervals; if the expire time is smaller than the refresh interval, your slaves will expire the zone before trying to load new data.
negative caching TTL
TTL stands for time to live. This value applies to all negative responses from the name servers authoritative for the zone.
TIP: On versions of BIND before BIND 8.2, the last field in the SOA record is both the default time to live and the negative caching time to live for the zone.
Those of you who have read earlier versions of this book may have noticed the change in the format we used for the SOA record's numeric fields. Once upon a time, BIND only understood units of seconds for the four fields we just described. (Consequently, a whole generation of administrators know that there are 608400 seconds in a week.) Now, with all but the oldest BIND name servers (4.8.3), you can specify units besides seconds for these fields and as arguments to the TTL control statement, as we saw early in this chapter. For example, you can specify a three-hour refresh interval with 3h, 180m, or even 2h60m. You can also use d for days and w for weeks.
The right values for your SOA record depend upon the needs of your site. In general, longer times cause less load on your name servers and can delay the propagation of changes; shorter times increase the load on your name servers and speed up the propagation of changes. The values we use in this book should work well for most sites. RFC 1537 recommends the following values for top-level name servers:
Refresh 24 hours Retry 2 hours Expire 30 days Default TTL 4 days
There is one implementation feature you should be aware of. Older versions (pre-4.8.3) of BIND slaves stop answering queries during a zone load. As a result, BIND was modified to spread out the zone loads, reducing the periods of unavailability. So, even if you set a low refresh interval, your slaves may not check as often as you request. BIND attempts a certain number of zone loads and then waits 15 minutes before trying another batch.
Now that we've told you all about how slave name servers poll to keep their data up to date, BIND 8 and 9 change how zone data propagates! The polling feature is still there, but BIND 8 and 9 add a notification when zone data changes. If both your primary master server and your slaves run BIND 8 or 9, the primary master notifies the slave that a zone has changed within 15 minutes of loading a new copy of that zone. The notification causes the slave server to shorten the refresh interval and attempt to load the zone immediately. We'll discuss this more in Chapter 10, "Advanced Features".
Multiple Master Servers
Are there other ways to make your slave name server's configuration more robust? Yes -- you can specify up to 10 IP addresses of master servers. In a BIND 4 configuration file, just add them after the first IP address and before the backup filename. In a BIND 8 or 9 configuration file, add them after the first IP address and separate them with semicolons:
masters { 192.249.249.3; 192.249.249.4; };
The slave will query the master server at each IP address in the order listed until it gets a response. Through BIND 8.1.2, the slave would always transfer the zone from the first master name server to respond if that master had a higher serial number. The slave would try successive master servers only if the previous master didn't respond. From BIND 8.2 on, however, the slave actually queries all of the master name servers listed and transfers the zone from the one with the highest serial number. If multiple master servers tie for the highest serial number, the slave transfers the zone from the first of those masters in the list.
The original intent of this feature was to allow you to list all the IP addresses of the host running the primary master name server for the zone if that host were multihomed. But since there is no check to determine whether the contacted server is a primary master or a slave, you can list the IP addresses of hosts running slave servers for the zone if that makes sense for your setup. That way, if the first master server is down or unreachable, your slave can transfer the zone from another master name server.
Slave DNS and Plesk
Preface
There are several reasons why you might need at least two DNS servers for serving your sites:
- You purchased a domain name from a domain registrar. To delegate the domain, many registrars require the domain zone to be served by at least two name servers residing in different IP subnets.
- You have several hosting servers, and you have not grown enough to use the products like PPA or PA, but you want to use a single set of name servers for all the domains you host.
- You want to have your own name servers and not depend on third parties.
- You want the WHOIS records for your domains to list your name servers.
Usually you would set up a couple of name servers in the Master/Slave mode. Then you create domain zones on both servers, but administer resource records of the domain zones only on the master server. The secondary (slave) server automatically downloads the changes from the master. Thus, you always have two active name servers with the same set of domain zones and resource records.
The only trifle annoyance is that you have to create and delete each zone on both servers. This does not happen automatically. That’s why you create a domain zone on the master, and then you create this domain zone on the slave and specify the master server’s address. After that, when you add the domain resource records on the master, you can be sure that your slave server will automatically get them from the master.
For many years, integration of Plesk with a slave DNS server has not been obvious. A Plesk server is supposed to be the master. In Plesk, we have the slave and master modes for a domain zone and the list of IP addresses that can retrieve domain zones. But there is no mechanism for creation of new domain zones on the slave server. And it will never appear, because Plesk’s concept presumes automation of hosting operations on a single server. For integration of several servers that are dedicated to running individual services, Parallels offers PPA and PA.
Still there are a lot of Plesk users for whom PPA or PA are more than they actually need. They just want integration with a slave name server. Previously, to solve this problem, each Plesk administrator had to write their own scripts, purchase commercial ones, or manually created and deleted domain zones on the slave server.
Seemingly, there are no complications. Plesk has got its local name server – let it be the master, and there is a system of event triggers – let us associate our script execution with the events “DNS zone creation” and “DNS zone deletion”. The problem will be solved. Unfortunately, Plesk does not support such events.
Not only Plesk software engineers develop Plesk, but they also use the product they develop. That’s why we created an extension that allows Plesk users to integrate Plesk with an external slave name server running BIND9. You can download this extension here.
How it works
Plesk uses BIND as a local name server. It can be managed remotely with the native rndc utility. There’s no reason why we could not install BIND on a remote server and manage it with rndc. Plesk 11.5 introduced the “Custom DNS backend” mechanism. It can be used to connect an external DNS service, for example AWS Route53. You can learn more in our doc.
Briefly, this feature allows us to register a script with Plesk. The script will receive a DNS zone description in JSON format with instructions what to do to a zone upon creation, modification, and deletion of any DNS zone in Plesk. That’s all we need. While implementing this feature, we assumed that you would use an external DNS service instead of installing the BIND server with Plesk. However, you do not necessarily have to delete the local BIND. The script can operate concurrently with a local DNS service. This is the idea that our extension uses.
The extension works according to the following algorithm:# It registers a slave server in the extension settings.
- The slave server’s IP address is automatically added to the list of addresses allowed to transfer domain zones from the Plesk server.
- When you create, modify, or delete an active domain zone in Plesk, Plesk creates, modifies, or deletes the domain zone in the local DNS service.
- Then the script starts and receives the domain name and the command to create, modify, or delete.
- The script initiates the rndc command for each connected slave server.
- Slave servers synchronize domain zones with the ones on the Plesk server.
Thus, we get a simple and very reliable scheme of working with slave name servers. All issues with zone files format, connection, and service restart are handled by the DNS service. The administrator should set up a slave server to work with an external Plesk only once. After that you can go to the registrar and say that the Plesk server and the slave server are name servers for your domains. Thus, we resolved all the issues stated at the beginning of the article.
Technical details
To set up a slave name server, using the example of a server with Debian 7:
- Install BIND.
apt-get install bind9* Allow creating new zones with rndc. In the /etc/bind/named.conf.options file, in the options {} directive, type:
allow-new-zones yes;* Specify the IP address from which control instructions should be accepted and set BIND to listen on all accessible network interfaces. Specify rndc key which will used by Plesk. In the /etc/bind/named.conf.local file, type:
key "plesk-key" {
algorithm hmac-md5;
secret "vwOxonI4n4CVRUhKAOAAIA==";
};
controls {
inet * port 953 allow { <plesk_ip>; <another_plesk_ip>; 127.0.0.1; } keys {"rndc-key", "plesk-key"; };
};* That’s it, the slave name server is set up.
After that, install the extension on the Plesk server. In the extension settings, add the slave server and specify its IP address and the pass key. The extension will create a configuration file with the slave server settings for the rndc utility. From now on, Plesk will automatically transfer all created, modified, and deleted zones to the slave server by executing the following command for each slave server:
Creation
/usr/sbin/rndc -c slave.config addzone example.com '{ type slave; file "example.com"; masters { <plesk_ip>; }; };'
Modification
/usr/sbin/rndc -c slave.config refresh example.com
Deletion
/usr/sbin/rndc -c slave.config delzone example.com
Now, when you add a domain in Plesk, a DNS zone is automatically created on the slave server as well as on the master server. Extension is available for download direct by link Slave DNS manager.
Troubleshooting
DNS (Domain name system) may not be known to most people who use the Internet but it is the real invisible force driving the Internet without which everyone would be seeing numbers and IPs. The whole meaning of domain names exists today just because of DNS.
Introduction
The simplest way of explaining DNS in one line is to map domain name to IP address. I am not sure how many would know that when somebody types a domain name in IE/firefox, the browser forwards the DNS request asking for ip address from the resolver of ISP (ISP Provider) and the resolver contacts the root servers and then systematically retrieves the IP address within a matter of few milliseconds.
Understanding DNS and its working is one of the most difficult computer engineering subject and yet most experienced network administrators struggle in this topic when it comes to DNS zone file writing.
Before I proceed with this article, the following are the MOST IMPORTANT points you should remember as otherwise you wouldnt understand bit.
Points To Remember
- Whenever you specify A record it must contain IP address on the Right side. The A record is so important in DNS without which the meaning of mapping hostnames to IP would be absurd. So remember this!
- CNAME (Alias) must contain hostnames. No IPs here
- NS an MX records must contain host names. No IPs allowed.
- Why DOT? simply because it tells to start query from root servers (denoted by dot)
- MX records (for mail servers) should contain hostnames NOT IPs.
Common DNS Terms
Glue Records
Glue records are A records that are associated with NS records to provide "bootstrapping" information to the NS records nameserver. (see RFC 1912 section 2.3)
domain.com. IN NS ns1.domain.com.
domain.com. IN NS ns2.domain.com.
ns1 IN A 11.33.55.77 ns2 IN A 22.44.66.88
In the above example we are mapping each NS records to IP address (A record) thus binding nameservers to IP (that is glue them).
LAME Nameserver Delegation
A nameserver which gives non-authoritative answer is usually called 'LAME'. Every domain must have atleast 2 nameservers and if i ask each of them, and if they have domain zone information, I will get authoritative answer. If not it's a 'lame delegation'. Refer to RFC 1912 section 2.8.
An example of lame delegation is
domain.com IN NS ns1.domain.com
domain.com IN NS ns2.example-server.net
ns1.domain.com is configured to have zone information about domain but ns2.exserver.net was not configured properly and does not have any information about the domain. So ns1 will answer authoritatively wheras ns2 won't which will be 'lame' until it is set up properly.
To get more in depth understanding, let's use dig tool for example.com.
1. First we find the nameservers of example.com:
dig example.com NS
;; ANSWER SECTION:
example.com. 158240 IN NS a.iana-servers.net. example.com. 158240 IN NS b.iana-servers.net.
2. Since we have received 2 nameservers, we ask each of them whether they give authoritative answer. If it's authoritative 'aa' flag in the header will be set in the answer received ('aa' is authoritative answer).
> dig @b.iana-servers.net example.com NS
> dig @a.iana-servers.net example.com NS
;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60896 ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION: ;example.com. IN NS
;; ANSWER SECTION: example.com. 172800 IN NS a.iana-servers.net. example.com. 172800 IN NS b.iana-servers.net.
Look in the flags.
flags: qr aa rd
Since 'aa' is set in the answer, then both the nameservers of example.com provide authoritative answer. If it is lame delegation you won't get the authoritative answer.
CAUTION
You should not use CNAME (alias) along with NS records and it often confuses most resolvers causing loops and often leads to 'lame' delegation.
domain.com. IN NS ns1.domain.com.
domain.com. IN NS ns2.domain.com. domain.com. In CNAME ns9.example-server.net
So never use CNAME along with NS records.
Stealth Nameservers
Stealth Nameservers (or hidden nameservers) are mismatched/conflicting nameservers which exist at root level against of nameservers in the domain.
To illustrate this, when I ask parent servers about your domain for NS records at root level I get
ns0.domain.com ns2.domain.com ns3.domain.com
but when I query nameservers of your domain for the NS records are not the same and comes like
ns0.domain.com ns2.domain.com ns.example-dns.net
Since ns.example-dns.net and ns3.domain.com is hidden both are a 'stealth nameservers'. Although there is nothing wrong in it, it is advisable not to have any stealth nameservers both at root level and in your dns server.
You can use dig command to lookup NS records at root server level.
dig +trace @K.root-servers.net example.com NS
and to ask one of the nameservers of the domain.
dig @ns0.domain.com example.com NS
Look for any NS mismatch between the two queries. If there is a nameserver missing at root level, add the missing nameserver to your domain registrar. If the nameserver missing at domain level, add the nameserver to the zone file of the domain and update all your secondary nameservers.
Open DNS Server
Running the dns server 'open' is a big security risk since it answers recursive queries both from inside and outside your network. It means anyone can query your server for IP address and your dns server will answer them.
To illustrate this, we have two nameservers running bind for domain example.com.
ns1.example.comns2.example.com
We ask ns1.example to resolve outside domain google.com and if we get IP address (A record) in the answer section, then it means it is an 'open dns server'.
dig @ns1.example.com google.com
dig @ns2.example.com google.com
;; global options: printcmd
;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 12107 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION: ;google.com. IN A
;; Query time: 32 msec
Since there is no ANSWER section or IP address both the nameservers does not constitute open dns server.
If you happen to run bind8 or later, all you have to do is set 'recursion no' within options to disable dns server answering recursive queries.
options {
.... recursion no; }
Zone Transfers (AXFR request)
Zone transfers are done by secondary nameservers to retrieve latest and updated zone information for domain from master or primary nameserver. Zone transfers should only be made available to secondary nameservers and not to the open world as it is a big security risk and may expose the internals of your network to the attacker.
To request a zone transfer for example.com we need to ask the master nameserver first. See the below example with dig.
dig @ns1.example.com example.com
If you see the output with full zone file, then you have to disable the zone transfer. In most cases you will see connection failed or REFUSED which means zone transfer is not allowed and its a good thing.
Common DNS Errors in Zone file Writing
No CNAME pointing to NS records
domain.com. IN NS ns1.domain.com.
domain.com. IN NS ns2.domain.com. domain.com. In CNAME ns9.example-server.net -----> WRONG
Placing CNAME along with NS the all of namservers will fail and will result in lame delegation. Don't do that!
Refer to RFC1912 2.4 and RFC2181 10.3.
DNS servers on IPs on same subnet (/24) or on same server
The whole purpose of DNS is for nameservers to be spread over different geographical locations so that if one dns fails the other would work. Although it is very common practice to run both nameservers on same server or subnet, it would not provide fault tolerance. If the server fails your nameservers will fail and your site wont load.
ns1 IN A 75.33.22.xx -----> same subnet /24
ns2 IN A 75.33.22.xx -----> same subnet /24
Proper GLUE
Always add glue to your NS records to the IP addresses using A record, failing which one of your nameservers will fail.
domain.com. IN NS ns1.domain.com.
domain.com. IN NS ns2.domain.com.
ns1 IN A 1.2.3.4 -----> GLUE ns2 IN A 2.4.6.9 -----> GLUE
Refer to RFC1912.
No duplicate MX records
domain.com. IN MX mail.domain.com.
domain.com. IN MX mail.domain.com ----> DUPLICATE
Allow Port 53 for both UDP and TCP connections
If you use firewall make sure you do not block port 53 for DNS tcp and udp requests. By default dns lookups use UDP protocol while zone transfers and notifications use TCP protocol of port 53.
Port 53 UDP = Dns Requests
Port 53 TCP = Zone transfers
CNAMEs cannot co-xist with MX hosts.
Do not specify CNAME or aliases pointing to MX records.
domain.com. IN MX 10 mail.domain.com.
mail IN CNAME domain.com. ----------> WRONG
Instead use A record to map directly to IP address. mail IN A 11.33.55.77 ---> CORRECT
Refer to RFC1912.
MX Records should not contain IP addresses
domain.com. IN 10 MX mail.domain.com. ----> CORRECT
domain.com. IN 20 MX 11.22.33.44 -----> WRONG
The correct way of doing this is glue the mx host to A record.
domain.com. IN MX 10 mail.domain.com. -----> CORRECT
mail IN A 11.33.55.77 ----------> CORRECT
NS records should NOT contain IP address
Always specify nameservers for your domain with NS records. It should be a name and not ip address.
domain.com. IN NS dns0.domain.com. -----> CORRECT
domain.com. IN NS 75.xx.xx.xx -----------> WRONG
REVERSE DNS FOR MAIL DELIVERY
For proper mail delivery, the following anti-spam methos are very important to make sure the email is delivered to users inbox. Most public email service providers yahoo, hotmail and gmail do use these parameters to flag email is spam or not.
(i) Setup Reverse IP for your mail server with PTR in DNS (needs Dedicated IP)
(ii) Setup SPF Record in your DNS (iii) Setup Domain Keys
I have seen on many occasions if you use shared hosting plan, most emails do land up in spam/bulk folder in the users inbox. So use a dedicated server.
Set up reverse IPs for Mailserver IPs
In order to setup reverse IP, first you will need to place a request to your hosting provider (since they own Ip address) and ask them to setup a reverse IP to your mail server. Once that is done you have to place a line using PTR in your domain zone file.
To test reverse ip lookup:
host <ip-address>
will show the output of reverse dns.
Set up SPF record
SPF record is setup using TXT record in your dns zone file. It looks like what is shown below. Visit http://openspf.org for more information about setup and configuration.
domain.com. IN TXT "v=spf1 a mx ip4:11.33.55.77 -all"
To query SPF record using dig:
dig domain.com TXT
Domain Keys
It basically contains 2 records (with and without selector) placed under TXT using underscore along with generated public key.
The ’sel’ is a selector and can be selector name.
Logging Clause
This section describes the logging clause which prior to BIND 9 needed to appear first in the named.conf file. This no longer the case and it may appear anywhere convenient. BIND uses syslogd before a valid logging clause is available so named.conf parse errors and other information will appear in /var/log/messages (depending on syslog.conf) prior to, or in the absence of, a valid logging clause. In the case of windows parse errors are written to the Event Log. Only one logging clause can be defined but multiple channels may be defined to stream logs.
= logging Clause Syntax =
BIND provides comprehensive logging features. Values in bold type below are keywords;
logging {
[ channel channel_name {
( file path name
[ versions ( number | unlimited ) ]
[ size size_spec ]
| syslog syslog_facility
| stderr
| null );
[ severity (critical | error | warning | notice |
info | debug [ level ] | dynamic ); ]
[ print-category yes | no; ]
[ print-severity yes | no; ]
[ print-time yes | no; ]
}; ]
[ category category_name {
channel_name ; [ channel_name ; ... ]
}; ]
...
};
The following notes describe the various fields and values:
| channel channel_name | BIND will accept multiple channel definitions in a single logging statement. 'channel_name' is normally written as a non-space name, for instance, my_channel but it can be written as a quoted string, for instance, "my channel". It is an arbitrary but unique name used to associate the category statement with this channel definition or it may take one of the standard (pre-defined) values below:
| ||||||||||||||||||||||||||||||||||||||||||||
| file | 'path_name' is a quoted string defining the absolute path to the logging file, for example, "/var/log/named/namedlog.log". From the grammar above 'file', 'syslog', 'stderr' and 'null' are mutually exclusive for a 'channel'. | ||||||||||||||||||||||||||||||||||||||||||||
| versions | 'versions' may take the parameter 'number' or 'unlimited' and defines the number of file versions that should be kept by BIND. Version files are created by BIND by appending .0, .1 etc to the file named defined by the file parameter. Files are 'rolled' (renamed or overwritten) so .0 will always contain the last log information prior to commencing the new log., .1 the next and so on. 'unlimited' currently implies 'versions 99'. Unless a size parameter is used new log versions will only be 'rolled' when BIND is restarted. If no versions statement is defined a single log file of unlimited size is used and on restart new data is appended to the defined file. This can get to be a very big file. | ||||||||||||||||||||||||||||||||||||||||||||
| size size_spec | 'size' allows you to define a limit to the file size created. A numeric only size_spec value is assumed to be the size in bytes, you may use the short forms k or K, m or M, g or G e.g. 25m = 25000000. size and versions are related in the following way: # If you specify a size value and NO versions parameter when the size limit is reached BIND will stop logging until the file size is reduced to below the threshold defined i.e. by deleting or truncating the file.
| ||||||||||||||||||||||||||||||||||||||||||||
| syslog syslog_facility | 'syslog' indicates that this channel will use syslogd logging features (as defined in syslog.conf). The syslog_facility is the facility definition for 'syslog' and may be found in syslog's man pages. From the grammar above 'file', 'syslog', 'stderr' and 'null' are mutually exclusive for a 'channel'. | ||||||||||||||||||||||||||||||||||||||||||||
| stderr | 'stderr' writes to the current standard out and would typically be only used for debug purposes. From the grammar above 'file', 'syslog', 'stderr' and 'null' are mutually exclusive for a 'channel'. | ||||||||||||||||||||||||||||||||||||||||||||
| null | 'null' writes to /dev/null - the bit bucket, nowhere. It does not produce a log. From the grammar above 'file', 'syslog', 'stderr' and 'null' are mutually exclusive for a 'channel'. | ||||||||||||||||||||||||||||||||||||||||||||
| severity | Controls the logging levels and may take the values defined. Logging will occur for any message equal to or higher than the level specified (=>) lower levels will not be logged.
| ||||||||||||||||||||||||||||||||||||||||||||
| print-time yes | no | Controls whether the date and time are written to the output channel (yes) or not (no). The default is 'no'. | ||||||||||||||||||||||||||||||||||||||||||||
| print-severity yes | no | Controls whether the severity level is written to the output channel (yes) or not (no). The default is 'no'. | ||||||||||||||||||||||||||||||||||||||||||||
| print-category yes | no | Controls whether the severity level is written to the output channel (yes) or not (no). The default is 'no'. | ||||||||||||||||||||||||||||||||||||||||||||
| category category_name | Controls what categories are logged to the various defined or default 'channel_names'. The category_name (a quoted string, for example, "default") may take one of the following values:
|
= Examples =
The first example shows a minimal logging configuration that will work and generate modest log volumes.
Logging{
channel simple_log {
file "/var/log/named/bind.log" versions 3 size 5m;
severity warning;
print-time yes;
print-severity yes;
print-category yes;
};
category default{
simple_log;
};
};
Reading BIND Debugging Output
Turning On Debugging Reading Debugging Output The Resolver Search Algorithm and Negative Caching (BIND 8) The Resolver Search Algorithm and Negative Caching (BIND 9) Tools
"O Tiger-lily!" said Alice, addressing herself to one that was waving gracefully about in the wind, "I wish you could talk!"
"We can talk," said the Tiger-lily, "when there's anybody worth talking to."
One of the tools in your troubleshooting toolchest is the name server's debugging output. As long as your name server has been compiled with DEBUG defined, you can get query-by-query reports of its internal operation. The messages you get are often quite cryptic; they were meant for someone who has the source code to follow. We'll explain some of the debugging output in this chapter. Our goal is to cover just enough for you to follow what the name server is doing; we aren't trying to supply an exhaustive compilation of debugging messages.
As you read through the explanations here, think back to material covered in earlier chapters. Seeing this information again, in another context, should help you understand more fully how a name server works.
Debugging Levels
The amount of information the name server provides depends on the debugging level. The lower the debugging level, the less information you get. Higher debugging levels give you more information, but they also fill up your disk faster.
After you've read a lot of debugging output, you'll develop a feel for how much information you'll need to solve any particular problem. Of course, if you can easily recreate the problem, you can start at level 1 and increase the debugging level until you have enough information. For the most basic problem -- why a name can't be looked up -- level 1 will often suffice, so you should start there.
What Information Is at Each Level?
Here's a list of the information that each debugging level produces for BIND 8 and BIND 9 name servers. The debugging information is cumulative; for example, level 2 includes all of level 1's debugging information. The data is divided into the following basic areas: starting up, updating the database, processing queries, and maintaining zones. We won't cover updating the name server's internal database -- problems almost always occur elsewhere. However, what the name server adds or deletes from its internal database can be a problem, as you'll see in Chapter 14, "Troubleshooting DNS and BIND".
BIND 8 and 9 have a whopping 99 debug levels, but most of the debugging messages are logged at just a few of those levels. We'll look at those now.
BIND 9 debugging levels
Level 1
Level 1 shows you basic name server operation: zone loading, maintenance (including SOA queries, zone transfers and zone expiration, and cache cleaning), NOTIFY messages, queries received, and high-level tasks dispatched (such as looking up addresses for a name server).
Level 2
Level 2 logs multicast requests.
Level 3
Level 3 shows you low-level task creation and operation. Unfortunately, most of these tasks don't have particularly descriptive names (requestmgr_detach ?) and the arguments they report are awfully cryptic. Level 3 also shows you journal activity, such as when the name server writes a record of a zone change to the zone's journal or when the name server applies a journal to a zone at startup. Operation of the DNSSEC validator and checking of TSIG signatures also come in at debug level 3.
Level 4
Level 4 logs when a master name server falls back to using AXFR because the transferred zone's journal isn't available.
Level 5
Level 5 logs which view was used while satisfying a particular request.
Level 6
A handful of outbound zone transfer messages are logged at level 6, including checks of the query that initiated the transfer.
Level 7
There are only a couple of new debugging messages at this level (logging of journal adds and deletes, and a count of how many bytes were returned by a zone transfer).
Level 8
Many dynamic update messages are logged at level 8: prerequisite checks, writing journal entries, and rollbacks. Several low-level zone transfer messages also appear here, including a log of resource records sent in a zone transfer.
Level 10
Level 10 reports a couple of messages about zone timer activity.
Level 20
Level 20 reports an update to a zone's refresh timer.
Level 90
Low-level operation of the BIND 9 task dispatcher is logged at level 90.
With BIND 8 and BIND 9, you can configure the name server to print out the debug level with the debug message. Just turn on the logging option print-severity as explained in Section 7.5, "Logging in BIND 8 and 9" in Chapter 7, "Maintaining BIND".
Keep in mind that this is debugging information -- it was used by the authors of BIND to debug the code, so it is not as readable as you might like. You can use it to figure out why the name server isn't doing what you think it should be or just to learn how the name server operates -- but don't expect nicely designed, carefully formatted output.
Reading Debugging Output
We'll cover five examples of debugging output. The first example shows the name server starting up. The next two examples show successful name lookups. The fourth example shows a secondary name server keeping its zone up to date. And in the last example, we switch from showing you name server behavior to showing you resolver behavior: the resolver search algorithm. After each trace (except the last one) we killed the name server and started it again so that each trace started with a fresh, nearly empty cache.
You might wonder why we've chosen to show normal name server behavior for all our examples; after all, this chapter is about debugging. We're showing you normal behavior because you have to know what normal operation is before you track down abnormal operation. Another reason is to help you understand the concepts (retransmissions, roundtrip times, etc.) we described in earlier chapters.
Name Server Startup (BIND 9, Debug Level 1)
Here's what a BIND 9 name server looks like starting up:
1) Sep 15 15:34:53.878 starting BIND 9.1.0 -d1 2) Sep 15 15:34:53.883 using 1 CPU 3) Sep 15 15:34:53.899 loading configuration from './named.conf' 4) Sep 15 15:34:53.920 the default for the 'auth-nxdomain' option is now 'no' 5) Sep 15 15:34:54.141 no IPv6 interfaces found 6) Sep 15 15:34:54.143 listening on IPv4 interface lo, 127.0.0.1#53 7) Sep 15 15:34:54.151 listening on IPv4 interface eth0, 192.249.249.3#53 8) Sep 15 15:34:54.163 command channel listening on 0.0.0.0#953 9) Sep 15 15:34:54.180 now using logging configuration from config file 10) Sep 15 15:34:54.181 dns_zone_load: zone 0.0.127.in-addr.arpa/IN: start 11) Sep 15 15:34:54.188 dns_zone_load: zone 0.0.127.in-addr.arpa/IN: loaded 12) Sep 15 15:34:54.189 dns_zone_load: zone 0.0.127.in-addr.arpa/IN: dns_journal _rollforward: no journal 13) Sep 15 15:34:54.190 dns_zone_maintenance: zone 0.0.127.in-addr.arpa/IN: enter 14) Sep 15 15:34:54.190 dns_zone_maintenance: zone version.bind/CHAOS: enter 15) Sep 15 15:34:54.190 running
The first difference you probably noticed between BIND 9's debugging output and BIND 8's is BIND 9's terseness. Remember that BIND 8 has been around for three years, and the authors have had plenty of time to add debugging messages to the code. BIND 9 is brand-spanking-new, so there aren't as many debugging messages yet.
You probably also noticed that BIND 9 includes a timestamp for each debugging message, which can be handy if you're trying to correlate messages to real-world events.
Lines 1 and 2 show the version of BIND we're running (9.1.0) and the configuration file it's reading. As with the previous example, we're using named.conf in the current directory. Line 3 tells us we're using only one CPU -- to be expected on a box with just one processor.
Line 4 gives us a simple warning that the default for the auth-nxdomain substatement (covered in Chapter 10, "Advanced Features") has changed. Line 5 reminds us that our host doesn't have any IP Version 6 network interfaces; if it did, BIND 9 could listen on those interfaces for queries.
Lines 6 and 7 show the name server listening on two network interfaces: lo, the loopback interface, and eth0, the Ethernet interface. BIND 9 displays the address and port in the format address#port, unlike BIND 8, which uses [address].port. Line 8 shows named listening on port 953, the default port, for control messages.
Lines 10-12 show the name server loading 0.0.127.in-addr.arpa. The start and loaded messages are self-explanatory. The no journal message indicates that no journal was present. (A journal, described in Chapter 10, "Advanced Features", is a record of dynamic updates the name server received for the zone.)
Finally, lines 13 and 14 show the name server doing maintenance on the 0.0.127.in-addr.arpa and version.bind zones. (version.bind is a built-in CHAOSNET zone that contains a single TXT record, attached to the domain name version.bind.) Zone maintenance is the process that schedules periodic tasks, such as SOA queries for slave and stub zones or NOTIFY messages.
A Successful Lookup (BIND 9, Debug Level 1)
We'll show you the debugging output produced by looking up the same domain name on a BIND 9 name server at debug level 1, but it's almost laughably short. Still, as we said, it's important to know what debugging output looks like under correct operation. Anyway, here goes:
Sep 16 17:20:57.193 client 192.249.249.3#1090: query: galt.cs.purdue.edu A Sep 16 17:20:57.194 createfetch: galt.cs.purdue.edu. A
The first line tells us that a client at IP address 192.249.249.3 (that is, the local host), running on port 1090, sent us a query for galt.cs.purdue.edu's address. The second line is logged by the portion of the name server that does name resolution to let us know what it's up to.
A Slave Name Server Checking Its Zone (BIND 9 Debug Level 1)
The equivalent debugging output from a BIND 9.1.0 name server at level 1 is, as usual, more concise. Here's what it looks like:
Sep 18 15:05:00.059 zone_timer: zone movie.edu/IN: enter Sep 18 15:05:00.059 dns_zone_maintenance: zone movie.edu/IN: enter Sep 18 15:05:00.059 queue_soa_query: zone movie.edu/IN: enter Sep 18 15:05:00.059 soa_query: zone movie.edu/IN: enter Sep 18 15:05:00.061 refresh_callback: zone movie.edu/IN: enter Sep 18 15:05:00.062 refresh_callback: zone movie.edu/IN: Serial: new 2000010923, old 2000010922 Sep 18 15:05:00.062 queue_xfrin: zone movie.edu/IN: enter Sep 18 15:05:00.070 zone_xfrdone: zone movie.edu/IN: success Sep 18 15:05:00.070 transfer of 'movie.edu' from 192.249.249.3#53: end of transfer Sep 18 15:05:01.089 zone_timer: zone movie.edu/IN: enter Sep 18 15:05:01.089 dns_zone_maintenance: zone movie.edu/IN: enter Sep 18 15:05:19.121 notify_done: zone movie.edu/IN: enter Sep 18 15:05:19.621 notify_done: zone movie.edu/IN: enter
The message at 15:05:00.059 shows the refresh timer popping, causing the name server to begin maintenance for the zone on the next line. First the name server queues a query for the SOA record for the IN class zone movie.edu (queue_soa_query at the same timestamp), which it sends.
At 15:05:00.062, the name server finds that the master name server has a higher serial number than it does (2000010923 to its 2000010922), so it queues an inbound zone transfer (queue_xfrin). All of eight milliseconds later (at 15:05:00.070) the transfer is done, and at 15:05:01.089 the name server resets the refresh timer (zone_timer).
The next three lines show the name server doing maintenance on movie.edu again. If, for example, some of movie.edu's name servers were outside the movie.edu zone, the name server would use this opportunity to look up their addresses (not just A, but also A6 and AAAA records!) so that it could include them in future responses. On the last two lines, our name server sends NOTIFY messages -- two, to be exact -- to the name servers listed in the NS records for movie.edu.
Turning On Debugging
Name server debugging can be started either from the command line or with control messages. If you need to see the startup information to diagnose your current problem, you'll have to use the command-line option. If you want to start debugging on a name server that is already running or if you want to turn off debugging, you'll have to use controls. The name server writes its debugging output to named.run. BIND 4 name servers create named.run in /usr/tmp (or /var/tmp), and BIND 8 and 9 name servers create it in the name server's working directory.
Debugging Command-Line Option
When troubleshooting, you sometimes need to see the sortlist, know which interface a file descriptor is bound to, or find out where in the initialization stage the name server was when it exited (if the syslog error message wasn't clear enough). To see this kind of debugging information, you'll have to start debugging with a command-line option; by the time you send a control message, it will be too late. The command-line option for debugging is -d level. When you use the command-line option to turn on debugging, a BIND 4 name server will not go into the background as it does normally; you'll have to add the & at the end of your command line to get your shell prompt back. Here's how to start a BIND 4 name server at debugging level 1:
# /etc/named -d 1 &
BIND 8 and 9 name servers go into the background even when you specify -d, so there's no need for the &.
Changing the Debugging Level with Control Messages
If you don't need to see the name server's initialization, start your name server without the debugging command-line option. You can later turn debugging on and off by using ndc to send the appropriate control message to the name server process. Here, we set debugging to level 3, then turn debugging off:
# ndc trace 3 # ndc notrace
And, as you might expect, if you turn on debugging from the command line, you can still use ndc to change the name server's debug level.
BIND 9.1.0's rndc doesn't implement the trace or notrace arguments yet (nor does the 9.1.0 named ), but a future version will. So if you're running BIND 9, use the -d command-line option.
Additional Possibilities
You can monitor your BIND9 server usage by installing the bindgraph package from the Universe (To enable Universe - see AddingRepositoriesHowto) and following configuration details as outlined in bindgraph's README documents
Further Information
Online Recources
- "ISC's BIND9 Manual" http://www.bind9.net/manuals
- TLDP's "DNS HOWTO" (For General Overview) http://www.tldp.org/HOWTO/DNS-HOWTO.html
- "Chroot BIND Howto" http://www.tldp.org/HOWTO/Chroot-BIND-HOWTO-4.html
- Debian BIND Wiki http://wiki.debian.org/Bind9
- BIND reference guide http://www.oit.uci.edu/dcslib/linux/rh-7.3/rhl-rg-en-7.3/ch-bind.html
Printed Resources
- "DNS & BIND" - Paul Albitz & Cricket Liu - 5th Edition - "O'Reilly Press" http://www.oreilly.com/catalog/dns5/index.html
- DNS & BIND Cookbook - Cricket Liu - 4th Edition - "O'Reilly Press"http://www.oreilly.com/
Controls clause
This section describes the controls clause in BIND 9.x. The controls clause is used to define access information and controls when using remote administration services, for example, the rndc utility. The controls clause takes a single inet statement type, though more than one inet statement may be defined. Full list of statements.
Controls {
inet inet_spec [inet_spec] ;
};
A controls clause is always defaulted and generates a TCP listen on port 953 (the default control port) of the loopback address for either or both of IPv4 and IPv6 (127.0.0.1 and/or ::1). If the remote administration will not be used, that is the rndc utility will not be used this control interface should be explicitly disabled by defining an empty controls clause as shown below:
controls {};
The primary access control method for remote administration, for example rndc in BIND 9, is via the use of keys defined within the inet statement (see below). To retain compatibility with previous versions of BIND or to run without a user generated key, a default key may be generated using the following command:
rndc-confgen -a
This command will create a file called rndc.key containing a default key clause with the name rndc-key in same directory as the named.conf file for the version of BIND being used and which is used for subsequent access to the control channel. If this command is not executed before BIND is loaded the following message will appear:
named [39248] none:0: open: /path/to/default/rndc.key: file not found
BIND will continue to run in this state but the control channel will not be operable. For full configuration of the inet statement and examples of its use in the controls clause see inet statements below.
inet
The inet statement defines a method to control access to the rndc (remote administration) utility. More than one inet statement may be included in a controls clause.
inet inet_spec [inet_spec] ..;
Each inet_spec parameter has the following format:
inet_spec = ( ip_addr | * ) [ port ip_port ] allow { address_match_list }
keys { key_list };
The ip_address parameter defines the IP address of the local server interface on which rndc connections will be accepted. The wildcard value ("*") will allow connection on any of the server's IP addresses including the loopback address. The optional ip_port parameter allows a specific port to be nominated for use by rndc connections.
The address_match_list defines the permitted hosts that can connect to the rndc channel. The key_list parameter contains a reference to one or more key clauses containing the list of permitted users who are allowed access. While address_match_lists can include a key parameter if one is present in the referenced address_match_list it is ignored, only keys defined in the key_list of the inet statement are permitted access.
The key_list can be omitted in which case the file rndc.key in the same directory as named.conf and which contains a default key clause with the name rndc-key will be used to provide default access. The rndc.key file is created by running the command:
rndc-confgen -a
The following example shows that a user on the loopback address can use the default key for access while all other users must use the rndc-remote key, in all cases localhost will use port 953 (the default) and external connection port 7766. An acl clause is used as the source of the address_match_list:
// named.conf fragment
acl "rndc-users" {
10.0.15.0/24;
!10.0.16.1/24; // negated
2001:db8:0:27::/64; // any address in subnet
};
....
key "rndc-remote" {
algorithm hmac-md5;
secret "OmItW1lOyLVUEuvv+Fme+Q==";
};
controls {
// local host - default key
inet 127.0.0.1 allow {localhost;};
inet * port 7766 allow {"rndc-users";} keys {"rndc-remote";};
};
Note: The keys clause above would normally be placed in a separate secure file and included into the named.conf file.
Problems, comments, suggestions, corrections (including broken links) or something to add? Please take the time from a busy life to 'mail us' (at top of screen), the webmaster (below) or [javascript:mailus('info-support','zytrax.com','Support%20Issue') info-support at zytrax]. You will have a warm inner glow for the rest of the day.
Bind9
Introduction
Putting a DNS server on a network allows for the replacement of IP addresses of individual machines by a name. As a result, it's even possible to associate multiple names to the same machine to update the different available services.
For example, www.example.com and pop.example.com, could both point to the primary server where the mail server and the business intranet reside, and the domain could be example.com. It's easy to remember that these two services are running on the same machine whose IP address is 192.168.0.1.
Now imagine that our network administrator decides for some reason or another to move the mail server to the machine 192.168.0.11. The only thing that has to be changed is the DNS server configuration file. You could always go and modify the host configuration for all the users, but that would be time consuming and inconvenient.
Network Layout
We get internet access through an xxxbox (192.168.1.1), two DNS servers provided by our ISP (80.10.249.2, 80.10.246.129). In fact, these two latter servers will ever be referred to in the configuration because the xxxbox will be in charge of resolving names if the packet destination isn't known. Consequently, I consider the xxxbox like a primary server outside of our domain.
The “sid” server (192.168.1.10) is connected to the xxxbox via its primary network card. It's also connected to the LAN (192.168.0.0/24) by its secondary network interface(192.168.0.1). It's on this that we are going to install the primary DNS server for our domain example.com (RFC 2606)
All the computers on the LAN are automatically assigned a single address by the DHCP service. The DHCP also provides the primary DNS server's address for our domain, and updatees the host names for the zone example.com so they can be associated with an ip address.
Server Management
Installation
The package bind9 will be used for installation.
# apt-get install bind9
and then if you want to also install the documentation (very useful):
# apt-get install bind9-doc
Configuration
After installation, you might want to get familiar with some of the configuration files. They are in the directory /etc/bind/
TSIG Signature
The purpose of this signature is to authenticate transactions with BIND. Thus, the DHCP server cannot update the example.com domain if it loses this key. Copy and paste an existing key
# cd /etc/bind/
# cat rndc.key
key "rndc-key" {
algorithm hmac-md5;
secret "QJc08cnP1xkoF4a/eSZZbw==";
};
# cp rndc.key ns-example-com_rndc-key
You can generate a new key with the following options:
- algorithm HMAC-MD5 - identifies 157 (required for a TSIG signature and only algorithm supported by BIND)
- length of 512 octets (multiple of 64 with a maximum length of 512 for the above algorithm)
- name : ns-example-com_rndc-key
dnssec-keygen -a HMAC-MD5 -b 512 -n USER ns-example-com_rndc-key Kns-example-com_rndc-key.+157+53334
The footprint associated with the key is 53334. We get two files, one with an extension key and the other with a private extension. This substitutes the key in the file ns-example-com_rndc-key with the one in one of these two files.
# cat Kns-example-com_rndc-key.+157+53334.private
Private-key-format: v1.2
Algorithm: 157 (HMAC_MD5)
Key: LZ5m+L/HAmtc9rs9OU2RGstsg+Ud0TMXOT+C4rK7+YNUo3vNxKx/197o2Z80t6gA34AEaAf3F+hEodV4K+SWvA===
Bits: AAA==
# cat ns-example-com_rndc-key
key "ns-example-com_rndc-key" {
algorithm hmac-md5;
secret "LZ5m+L/HAmtc9rs9OU2RGstsg+Ud0TMXOT+C4rK7+YNUo3vNxKx/197o2Z80t6gA34AEaAf3F+hEodV4K+SWvA==";
};
The file ns-example-com_rndc-key should not be made world readable for security reasons. This should be inserted into the bind configuration by an include because the bind configuration itself is world-readable. Also, it's a good idea to delete the key and private files generated before.
File /etc/bind/named.conf
This file is the main configuration file for the DNS file.
// Managing acls
acl internals { 127.0.0.0/8; 192.168.0.0/24; };
// Load options include "/etc/bind/named.conf.options";
// TSIG key used for the dynamic update include "/etc/bind/ns-example-com_rndc-key";
// Configure the communication channel for Administrative BIND9 with rndc
// By default, they key is in the rndc.key file and is used by rndc and bind9
// on the localhost
controls {
inet 127.0.0.1 port 953 allow { 127.0.0.1; };
};
// prime the server with knowledge of the root servers
zone "." {
type hint;
file "/etc/bind/db.root";
};
include "/etc/bind/named.conf.default-zones"; include "/etc/bind/named.conf.local";
Note : with Debian Jessie the 'zone "." {...}' part is inside the file "named.conf.default-zones". You don't need to add it in the file "named.conf".
File /etc/bind/named.conf.default-zones
Note: as of Debian 7 "Wheezy" bind9 ships with a file containing default forward, reverse, and broadcast zones.
// be authoritative for the localhost forward and reverse zones, and for
// broadcast zones as per RFC 1912
zone "localhost" {
type master;
file "/etc/bind/db.local";
};
zone "127.in-addr.arpa" {
type master;
file "/etc/bind/db.127";
};
zone "0.in-addr.arpa" {
type master;
file "/etc/bind/db.0";
};
zone "255.in-addr.arpa" {
type master;
file "/etc/bind/db.255";
};
File /etc/bind/named.conf.options
This file contains all the configuration options for the DNS server
options {
directory "/var/cache/bind";
// Exchange port between DNS servers
query-source address * port *;
// Transmit requests to 192.168.1.1 if
// this server doesn't know how to resolve them
forward only;
forwarders { 192.168.1.1; };
auth-nxdomain no; # conform to RFC1035
// From 9.9.5 ARM, disables interfaces scanning to prevent unwanted stop listening
interface-interval 0;
// Listen on local interfaces only(IPV4)
listen-on-v6 { none; };
listen-on { 127.0.0.1; 192.168.0.1; };
// Do not transfer the zone information to the secondary DNS
allow-transfer { none; };
// Accept requests for internal network only
allow-query { internals; };
// Allow recursive queries to the local hosts
allow-recursion { internals; };
// Do not make public version of BIND
version none;
};
The port associated with the query-source option must not in any case be frozen because it jeopardizes the DNS transactions in the case of a resolver. * Vulnerability Note VU#800113 http://www.kb.cert.org/vuls/id/800113
M. Rash wrote an interesting article about this and how to force the source port randomly via the iptables: Mitigating DNS Cache Poisoning Attacks with iptables
To reduce the delay timeout for UDP connections, and thus highlight the randomization, which by default is 30s by tuple, simply update the parameter net.netfilter.nf_conntrack_udp_timeout
# sysctl -w net.netfilter.nf_conntrack_udp_timeout=10
to get timeout of 10s.
File /etc/bind/named.conf.local
This file contains the local DNS server configuration, and this is where you declare the zones associated with this server's domain(s).
// Manage the file logs include "/etc/bind/named.conf.log";
// Domain Management example.com
// ------------------------------
// - The server is defined as the master on the domain.
// - There are no forwarders for this domain.
// - Entries in the domain can be added dynamically
// with the key ns-example-com_rndc-key
zone "example.com" {
type master;
file "/var/lib/bind/db.example.com";
//forwarders {};
// If we do not comment the forwarders "empty" clients of the local subnet in my case don't have access to the upstream DNS ?
//allow-update { key ns-example-com_rndc-key; };
allow-update { key rndc-key; };
//confusion between the file name to import (ns-example-com_rndc-key) and the key label (rndc-key) ?
};
zone "0.168.192.in-addr.arpa" {
type master;
file "/var/lib/bind/db.example.com.inv";
//see comment below (zone "example.com")
//forwarders {};
//allow-update { key ns-example-com_rndc-key; };
allow-update { key rndc-key; };
};
// Consider adding the 1918 zones here, if they are not used in your // organization include "/etc/bind/zones.rfc1918";
NOTE: if you create a local non-FQDN and call it .local it clashes with some other packages (which?). Edit /etc/nsswitch.conf and move dns right after the files on the host line makes .local domains work.
File /etc/bind/named.conf.log
With Debian Jessie, you need to create this file in /etc/bind
logging {
channel update_debug {
file "/var/log/update_debug.log" versions 3 size 100k;
severity debug;
print-severity yes;
print-time yes;
};
channel security_info {
file "/var/log/security_info.log" versions 1 size 100k;
severity info;
print-severity yes;
print-time yes;
};
channel bind_log {
file "/var/log/bind.log" versions 3 size 1m;
severity info;
print-category yes;
print-severity yes;
print-time yes;
};
category default { bind_log; };
category lame-servers { null; };
category update { update_debug; };
category update-security { update_debug; };
category security { security_info; };
};
Here we define different log methods for the different categories. The first category is, as its name indicates the default category that is usually assigned to syslog. All categories not mentioned, are similar to the default category. For a list of the different categories, see the bind9 administrator reference manual. In terms of blade-servers, it ignores all the logs associated with them. It may be necessary to create /var/log in the chroot later.
Resource Records (RR)
DNS is made up of several registrations, RR or Resource Records, defining the various domain information. The first is dedicated to name resolution, in our case, it is the file db.example.com. The second will be used for reverse name resolution, it is the file db.example.com.inv.
Files in var/cache/bind/
- RR for name reso (db.example.com file)
$TTL 3600
@ IN SOA sid.example.com. root.example.com. (
2007010401 ; Serial
3600 ; Refresh [1h]
600 ; Retry [10m]
86400 ; Expire [1d]
600 ) ; Negative Cache TTL [1h]
;
@ IN NS sid.example.com.
@ IN MX 10 sid.example.com.
sid IN A 192.168.0.1 etch IN A 192.168.0.2
pop IN CNAME sid www IN CNAME sid mail IN CNAME sid* RR for inverse name resol ( db.example.com.inv file)
@ IN SOA sid.example.com. root.example.com. (
2007010401 ; Serial
3600 ; Refresh [1h]
600 ; Retry [10m]
86400 ; Expire [1d]
600 ) ; Negative Cache TTL [1h]
;
@ IN NS sid.example.com.
1 IN PTR sid.example.com. 2 IN PTR etch.example.com.
Some Explanations :
$TTL : (Time To Live) expresses the duration (in seconds) validity, by default, of the information contained in the RRs. Once this time expires, it is necessary to recheck the data. Types :
- SOA : Show romanization
to define information about the area. In this case the name of the primary DNS server "sid.example.com." and the email address of technical contact (root.example.com.; the @ is replaced by a dot). It is composed of several fields:
- 1. Serial : is the whole non-signed 32 bits. This is the serial number to increment with each change of file. It allows the secondary server to reload the information they have. The general purpose is to format it this way YYYYMMDDXX, either for the first amendment 01/04/2007 -> 2007040101, for the second 2007040102.
- 2. Refresh : defines the data refresh period.
- 3. Retry : if an error occurs during the last refresh, it will be repeated at the end of time Retry.
- 4. Expires': the server is considered unavailable after the time expires.
- 5. Negative cache TTL': set the lifetime of a NXDOMAIN response from us.
- NS': information on behalf of nameservers for the domain.
- 'X.: information on the mail server. Many can be defined. Thus, it is possible to give them a priority, assigning a number. The lower the number, the higher the priority.
- A': associates a host name to an IPv4 address (32 bits)
- 'YYYY: associates a host name to an IPv6 address (128 bits)
- CNAME': identifies the canonical name of an alias (a name that points to another name)
- 'PTR: This is simply the inverse resolution (the opposite of type A).
The classes in the association determines the Internet class. Other classes are available (CH and HS). For more information please consult the RFC 1035
/etc/resolv.conf File
search example.com
It's no more complicated than that !
Chroot
The named daemon is started using the bind user by default.
This option is found in the bind service config file /etc/default/bind9 (NOTE: this is not valid for jessie who used systemd):
OPTIONS="-u bind"
The bind start script /etc/init.d/bind9 reads this config file when the service is started.
Starting bind as a non root user is good practice but to run the daemon in a chroot environment we also need specify the chroot directory. This is done using the same OPTIONS variable in /etc/default/bind9.
To begin, start by stopping the bind service:
/etc/init.d/bind9 stop
Then edit /etc/default/bind9 (not for jessie):
OPTIONS="-u bind -t /var/bind9/chroot"
For Jessie, create the file /etc/systemd/system/bind9.service with options "-t /var/bind9/chroot":
[Unit] Description=BIND Domain Name Server Documentation=man:named(8) After=network.target
[Service] ExecStart=/usr/sbin/named -f -u bind -t /var/bind9/chroot ExecReload=/usr/sbin/rndc reload ExecStop=/usr/sbin/rndc stop
[Install] WantedBy=multi-user.target
For Jessie, after creating the above unit file, update the symlink to the unit file with:
systemctl reenable bind9
Now create the chroot directory structure:
mkdir -p /var/bind9/chroot/{etc,dev,var/cache/bind,var/run/named}
Create the required device special files and set the correct permissions:
mknod /var/bind9/chroot/dev/null c 1 3
mknod /var/bind9/chroot/dev/random c 1 8
chmod 660 /var/bind9/chroot/dev/{null,random}
Move the current config directory into the new chroot directory:
mv /etc/bind /var/bind9/chroot/etc
Now create a symbolic link in /etc for compatibility:
ln -s /var/bind9/chroot/etc/bind /etc/bind
If you want to use the local timezone in the chroot (e.g. for syslog):
cp /etc/localtime /var/bind9/chroot/etc/
Change the ownership on the files you've just moved over and the rest of the newly created chroot directory structure:
chown bind:bind /var/bind9/chroot/etc/bind/rndc.key
chmod 775 /var/bind9/chroot/var/{cache/bind,run/named}
chgrp bind /var/bind9/chroot/var/{cache/bind,run/named}
Edit the PIDFILE variable in /etc/init.d/bind9 to the correct path:
PIDFILE=/var/bind9/chroot/var/run/named/named.pid
Finally tell rsyslog to listen to the bind logs in the correct place:
echo "\$AddUnixListenSocket /var/bind9/chroot/dev/log" > /etc/rsyslog.d/bind-chroot.conf
Restart rsyslog and start bind:
/etc/init.d/rsyslog restart; /etc/init.d/bind9 start
Client Manage
As I mentioned at the beginning, the assignment of IP addresses on the LAN is performed by the DHCP server. Thus, to set our DNS server to different clients, it is necessary to add the DHCP configuration file the following two lines:
option domain-name "example.com"
option domain-name-server sid.example.com
It must be added to the file (I think) the areas for which DHCP should automatically perform updates.
Syntax (everything after "=>" is my comments) :
zone [name.of.the.zone.] { * primary 127.0.0.1; => the primary DNS server is on the same machine as the DHCP
key rndc-key; => it's necessary to provide the security key (via an include) in the beginning of the DHCP server configuration file,
- this must be the same key that secures the allow-update for the zone in the named.conf.local of Bind9.
}
Examples de [name.of.the.zone.] (with the "." at the end) :
- example.com. : for the direct zone of this article,
- 0.168.192.in-addr.arpa. : for the inverse zone of this article.
For more information on the implementation of dynamic update of DNS records through DHCP is here
Testing tools
Dig Command
This can directly search the DNS server of your choice and get a lot of information in addition to name resolution and contrast resolution. $ dig nomade-frjo.stones.lan ; <<>> DiG 9.4.2 <<>> nomade-frjo.stones.lan ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15760 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
;; QUESTION SECTION: ;nomade-frjo.stones.lan. IN A
;; ANSWER SECTION: nomade-frjo.stones.lan. 900 IN A 192.168.0.242
;; AUTHORITY SECTION: stones.lan. 604800 IN NS emerald.stones.lan. stones.lan. 604800 IN NS diamond.stones.lan.
;; ADDITIONAL SECTION: diamond.stones.lan. 604800 IN A 192.168.0.1 emerald.stones.lan. 604800 IN A 192.168.0.2
;; Query time: 20 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Fri Mar 28 20:53:09 2008 ;; MSG SIZE rcvd: 131
$ dig -x 192.168.0.242 ; <<>> DiG 9.4.2 <<>> -x 192.168.0.242 ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37702 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
;; QUESTION SECTION: ;242.0.168.192.in-addr.arpa. IN PTR
;; ANSWER SECTION: 242.0.168.192.in-addr.arpa. 900 IN PTR nomade-frjo.stones.lan.
;; AUTHORITY SECTION: 0.168.192.in-addr.arpa. 604800 IN NS diamond.stones.lan. 0.168.192.in-addr.arpa. 604800 IN NS emerald.stones.lan.
;; ADDITIONAL SECTION: diamond.stones.lan. 604800 IN A 192.168.0.1 emerald.stones.lan. 604800 IN A 192.168.0.2
;; Query time: 19 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Fri Mar 28 20:53:31 2008 ;; MSG SIZE rcvd: 155
nslookup
- Kind of slow but still useful.
$ nslookup etch Server: 192.168.0.1 Address: 192.168.0.1#53 Name: etch.example.com Address: 192.168.0.2
$ nslookup 192.168.0.2 Server: 192.168.0.1 Address: 192.168.0.1#53 2.0.168.192.in-addr.arpa name = etch.example.com.* named-checkconf : Verifies the syntax of the configuration files for Bind9.
# named-checkconf -z zone localhost/IN: loaded serial 1 zone 127.in-addr.arpa/IN: loaded serial 1 zone 0.in-addr.arpa/IN: loaded serial 1 zone 255.in-addr.arpa/IN: loaded serial 1 zone estar.lan/IN: loaded serial 20080315 zone 0.168.192.in-addr.arpa/IN: loaded serial 20080315 zone 10.in-addr.arpa/IN: loaded serial 1 zone 16.172.in-addr.arpa/IN: loaded serial 1 zone 17.172.in-addr.arpa/IN: loaded serial 1 zone 18.172.in-addr.arpa/IN: loaded serial 1 zone 19.172.in-addr.arpa/IN: loaded serial 1 zone 20.172.in-addr.arpa/IN: loaded serial 1 zone 21.172.in-addr.arpa/IN: loaded serial 1 zone 22.172.in-addr.arpa/IN: loaded serial 1 zone 23.172.in-addr.arpa/IN: loaded serial 1 zone 24.172.in-addr.arpa/IN: loaded serial 1 zone 25.172.in-addr.arpa/IN: loaded serial 1 zone 26.172.in-addr.arpa/IN: loaded serial 1 zone 27.172.in-addr.arpa/IN: loaded serial 1 zone 28.172.in-addr.arpa/IN: loaded serial 1 zone 29.172.in-addr.arpa/IN: loaded serial 1 zone 30.172.in-addr.arpa/IN: loaded serial 1 zone 31.172.in-addr.arpa/IN: loaded serial 1 zone 168.192.in-addr.arpa/IN: loaded serial 1* named-checkzone : Verifies the validity of zone files before resetting the configuration.
# named-checkzone example.com /var/lib/bind/db.example.com
zone example.com/IN: loaded serial 20080315 OK # named-checkzone 0.168.192.in-addr.arpa /var/lib/bind/db.example.com.inv zone 0.168.192.in-addr.arpa/IN: loaded serial 20080315 OK