Bind check zone file for errors

bind check zone file for errors

A. You need to use named- checkzone command as zone file validity checking tool. It is useful for checking zone files before configuring. sprers.eu › i-MSCP Support Area › Documentation. Using BIND, I need to determine why my newly created zone file fails the named-checkzone check. Here in order is the sprers.eu file.

youtube video

02 03 Understanding Zone Files

Bind check zone file for errors - advise

Howto check Bind9 zone files and main configuration?

@sfsolutions

You should really consider to read the man page. Your command is wrong.

With i-MSCP x branch for which zone files are now dumped in format and for which zone location has changed: sprers.eu…sprers.eu#dns-server-bind9

  1. [email&#;protected]:~# named-checkzone -f raw sprers.eu /var/cache/bind/imscp/master/sprers.eu sprers.eu: 'sprers.eu' found SPF/TXT record but no SPF/SPF record found, add matching type SPF recordzone sprers.eu: 'sprers.eu' found SPF/TXT record but no SPF/SPF record found, add matching type SPF recordzone sprers.eu: 'sprers.eu' found SPF/TXT record but no SPF/SPF record found, add matching type SPF recordzone sprers.eu: loaded serial [email&#;protected]:~#

Note: Here, the warnings about SPF are expected. SPF records are deprecated but older versions of Bind9 are not aware of that fact ;)

With current stable or older i-MSCP versions the command is identical but without the option and the root directory for zone files is simply ;)

Now, for all i-MSCP versions you can also simply do:

  1. [email&#;protected]:~# named-checkzone sprers.eu /etc/imscp/bind/working/sprers.eu sprers.eu: 'sprers.eu' found SPF/TXT record but no SPF/SPF record found, add matching type SPF recordzone sprers.eu: 'sprers.eu' found SPF/TXT record but no SPF/SPF record found, add matching type SPF recordzone sprers.eu: 'sprers.eu' found SPF/TXT record but no SPF/SPF record found, add matching type SPF recordzone sprers.eu: loaded serial [email&#;protected]:~#

In which case, there is no need to specify the zone file format ;)

For viewing all records from a specific zone, you can also do:

  1. [email&#;protected]:~# dig axfr sprers.eu; <<>> DiG +deb8uDebian <<>> axfr sprers.eu;; global options: +sprers.eu IN SOA sprers.eu sprers.eu sprers.eu IN A <ip>sprers.eu IN NS sprers.eu IN TXT "v=spf1 a mx -all"sprers.eu IN MX 10 sprers.eu IN TXT "v=spf1 include:sprers.eu -all"sprers.eu IN MX 10 sprers.eu 60 IN A <ip>sprers.eu IN A <ip>sprers.eu IN A <ip>sprers.eu IN A <ip>sprers.eu IN A <ip>sprers.eu IN A <ip>sprers.eu IN A <ip>sprers.eu IN A <ip>sprers.eu IN CNAME sprers.eu IN A <ip>sprers.eu IN A <ip>sprers.eu IN A <ip>sprers.eu IN A <ip>sprers.eu IN TXT "v=spf1 include:sprers.eu -all"sprers.eu IN MX 10 sprers.eu IN A <ip>sprers.eu IN A <ip>sprers.eu IN A <ip>sprers.eu IN A <ip>sprers.eu IN A <ip>sprers.eu IN A <ip>sprers.eu IN A <ip>sprers.eu IN A <ip>sprers.eu IN CNAME sprers.eu IN A <ip>sprers.eu IN A <ip>sprers.eu IN A <ip>sprers.eu IN A <ip>sprers.eu IN CNAME sprers.eu IN SOA sprers.eu sprers.eu ;; Query time: 0 msec;; SERVER: #53();; WHEN: Mon May 29 CEST ;; XFR size: 37 records (messages 1, bytes )[email&#;protected]:~#

Now, if you want check your :

  1. [email&#;protected]:~# named-checkconf -p -z /etc/bind/sprers.eu
  2. zone sprers.eu: loaded serial
  3. zone sprers.eu: loaded serial
  4. zone localhost/IN: loaded serial 2
  5. zone sprers.eu: loaded serial 1
  6. zone sprers.eu: loaded serial 1
  7. zone sprers.eu: loaded serial 1
  8. options {
  9. directory "/var/cache/bind";
  10. listen-on {
  11. "any";
  12. };
  13. listen-on-v6 {
  14. "none";
  15. };
  16. version "i-MSCP DNS Server";
  17. allow-query-cache {
  18. "localhost";
  19. };
  20. allow-recursion {
  21. "localhost";
  22. };
  23. auth-nxdomain no;
  24. dnssec-enable no;
  25. dnssec-validation no;
  26. minimal-responses yes;
  27. allow-transfer {
  28. "none";
  29. };
  30. check-spf ignore;
  31. };
  32. zone "sprers.eu" {
  33. type master;
  34. file "imscp/master/sprers.eu";
  35. allow-transfer {
  36. "localhost";
  37. };
  38. masterfile-format raw;
  39. notify yes;
  40. };
  41. zone "sprers.eu" {
  42. type master;
  43. file "imscp/master/sprers.eu";
  44. allow-transfer {
  45. "localhost";
  46. };
  47. masterfile-format raw;
  48. notify yes;
  49. };
  50. zone "." {
  51. type hint;
  52. file "/etc/bind/sprers.eu";
  53. };
  54. zone "localhost" {
  55. type master;
  56. file "/etc/bind/sprers.eu";
  57. };
  58. zone "sprers.eu" {
  59. type master;
  60. file "/etc/bind/db";
  61. };
  62. zone "sprers.eu" {
  63. type master;
  64. file "/etc/bind/db.0";
  65. };
  66. zone "sprers.eu" {
  67. type master;
  68. file "/etc/bind/db";
  69. };
  70. managed-keys {
  71. "sprers.eu" initial-key "BEAAAAPHMu/5onzrEE7z1egmhg/WPO0+juoZrW3euWEn4MxDCE1+lLy2
  72. brhQv5rN32RKtMzX6Mj70jdzeND4XknW58dnJNPCxn8+jAGl2FZLK8t+
  73. 1uq4W+nnA3qO2+DL+k6BD4mewMLbIYFwe0PG73Te9fZ2kJb56dhgMde5
  74. ymX4BI/oQ+cAK50/xvJv00Frf8kw6ucMTwFlgPe+jnGxPPEmHAte/URk
  75. Y62ZfkLoBAADLHQ9IrS2tryAe7mbBZVcOwIeU/Rw/mRx/vwwMCTgNboM
  76. QKtUdvNXDrYJDSHZws3xiRXF1Rf+al9UmZfSav/4NWLKjHzpT59k/VSt
  77. TDN0YUuWrBNh";
  78. "." initial-key "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
  79. FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
  80. bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHLM/QZxkjf5/Efucp2gaD
  81. X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
  82. W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
  83. Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq
  84. QxA+Uk1ihz0=";
  85. };
  86. [email&#;protected]:~#
Display More

See the man page.

BIND zone file backend¶

  • Native: Yes
  • Master: Yes
  • Slave: Yes
  • Superslave: Experimental
  • DNSSEC: Yes
  • Disabled data: No
  • Comments: No
  • API: Read-only
  • Zone caching: Yes (except in hybrid mode)
  • Module name: bind
  • Launch:

The BIND backend started life as a demonstration of the versatility of PowerDNS but quickly gained in importance when there appeared to be demand for a BIND ‘work-alike’.

The BIND backend parses a BIND-style and extracts information about zones from it. It makes no attempt to honour other configuration flags, which you should configure (when available) using the PowerDNS native configuration.

Unique to this PowerDNS backend is that it serves from plain zone files, which allows for hand-crafting zone files, only takes a tiny footprint in terms of server resource usage while being performant efficiently.

Note

Because this backend retrieves its configuration from plain files and not a database, the HTTP API is unable to process changes for this backend. This effectively makes the API read-only for zones hosted by the BIND backend.

Configuration Parameters¶

Location of the BIND configuration file to parse.

PowerDNS does not support every directive supported by BIND. It supports the following blocks and directives:

    Interval in seconds to check for zone file changes. Default is 0 (disabled).

    See Operation section for more information.

    Filename to store and access our DNSSEC metadatabase, empty for none. To slave DNSSEC-enabled domains (where the RRSIGS are in the AXFR), a is required. This is because the PRESIGNED domain metadata is set during the zonetransfer.

    You can use to make this database file for you.

    Warning

    If this is left empty on slaves and a presigned zone is transferred, it will (silently) serve it without DNSSEC. This in turn results in serving the domain as bogus.

    SQLite3 journal mode to set. The default is WAL. Set to empty to leave the journal mode alone.

    Setting this option to makes PowerDNS ignore out of zone records when loading zone files.

    Specifies file where to read list of autoprimaries. BIND backend only checks IP address of primary server.

    The file must contain one IP and account per line, separated by whitespace.

    BIND backend can only read this file, not write it.

    When a new zone is configured via the autosecondary mechanism, bindbackend writes a zone entry to this file.

    Your file should have an statement to make sure this file is read on startup.

    Operation¶

    On launch, the BIND backend first parses the to determine which zones need to be loaded. These will then be parsed and made available for serving, as they are parsed. So a with zones may take 20 seconds to load, but after 10 seconds, zones will already be available. While a domain is being loaded, it is not yet available, to prevent incomplete answers.

    Reloading is currently done only when a request (or zone transfer) for a zone comes in, and then only after bind-check-interval seconds have passed after the last check. If a change occurred, access to the zone is disabled, the file is reloaded, access is restored, and the question is answered. For regular zones, reloading is fast enough to answer the question which lead to the reload within the DNS timeout.

    If bind-check-interval is specified as zero, no checks will be performed until the is given.

    Please note that also the slave-cycle-interval setting controls how often a master would notify a slave about changes. Especially in ‘hidden master’ configurations, where servers usually don’t receive regular queries, you may want to lower that setting to a value as low as bind-check-interval.

    pdns_control commands¶

    Add zone from to PowerDNS’s BIND backend. Zone will be loaded at first request.

    Note

    This does not add the zone to the bind-config file.

    Output an extended status of a domain or domains, containing much more information than the simple domain status, like the number of records currently loaded, whether pdns is master or slave for the domain, the list of masters, various timers, etc

    Output status of domain or domains. Can be one of:

    • ,
    • or
    • .

    Lists all zones that have problems, and what those problems are.

    Reloads a zone from disk NOW, reporting back results.

    Reread the BIND configuration file (). If parsing fails, the old configuration remains in force and reports the error. Any newly discovered domains are read, discarded domains are removed from memory.

    All zones with a changed timestamp are reloaded at the next incoming query for them.

    Performance¶

    The BIND backend does not benefit from the packet cache as it is fast enough on its own. Furthermore, on most systems, there will be no benefit in using multiple CPUs for the packetcache, so a noticeable speedup can be attained by specifying in .

    Master/slave/native configuration¶

    Master¶

    Works as expected. At startup, no notification storm is performed as this is generally not useful. Perhaps in the future the BIND backend will attempt to store zone metadata in the zone, allowing it to determine if a zone has changed its serial since the last time notifications were sent out.

    Changes which are discovered when reloading zones do lead to notifications however.

    Slave¶

    Also works as expected. The BIND backend expects to be able to write to a directory where a slave domain lives. The incoming zone is stored as ‘sprers.eu’ and atomically renamed if it is retrieved successfully, and parsed only then.

    In the future, this may be improved so the old zone remains available should parsing fail.

    Native¶

    PowerDNS has the concept of “native” zones that have the in the BIND configuration file. These zones are neither a master (no notifies are sent) nor a slave zone (it will never be AXFR’d in). This means that the replication mechanism for these zone is not AXFR but out of band, e.g. using . Changes to native zones are picked up in the same way as master and slave zones, see Operation.

    Native zones in the BIND backend are supported since version of the PowerDNS Authoritative Server.

    Note

    Any zone with no set (an error in BIND) is assumed to be native.

    BIND9ServerHowto

    Tag/sprers.eu

    Content Cleanup Required
    This article should be cleaned-up to follow the content standards in the Wiki Guide. More info

    Note: There are some issues with this Howto, too numerable to fix quickly, and it requires bringing up to standard. I'm mentioning this to help anyone to avoid the unnecessary time trying to resolve their DNS, owing the the inconsistencies in this document, particularly if you're new to DNS configuration. One example is here

    box IN A

    in all other places, the document uses the machine name example ns. Here it changes to box (I believe the author was simply trying to show that additional computers would be listed, but failed to use a different address for box. I modified the example file to give box an address of ).

    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.

    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.

    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.

    There are lots of different DNS record types, but some of the most common types are covered below.

    Address Records

    The most commonly used type of record. This record maps an IP Address to a hostname.

    www IN A

    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

    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 sprers.eu [] mail IN A

    Name Server Records

    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 sprers.eu [] ns IN A

    BIND9 Configuration files are stored in:

    /etc/bind/

    The main configuration is stored in the following files:

    /etc/bind/sprers.eu /etc/bind/sprers.eus /etc/bind/sprers.eu

    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 :

    [] forwarders { ; ; }; []

    (where and 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

    If all goes well you should see output similar to:

    ; <<>> DiG P1 <<>> -x ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 [] ;; Query time: 1 msec ;; SERVER: #53() ;; WHEN: Mon Nov 26 ;; MSG SIZE rcvd: 93

    The dig command can also be used to query other domains for example:

    dig sprers.eu

    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 sprers.eu. Simply replace sprers.eu 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 :

    [] zone "sprers.eu" { type master; file "/etc/bind/sprers.eu"; }; []

    Now use an existing zone file as a template:

    sudo cp /etc/bind/sprers.eu /etc/bind/sprers.eu

    Edit the new zone file change to the FQDN of your server, leaving the additional "." at the end. Change to the nameserver's IP Address and to a valid email address, but with a "." instead of the "@". also leaving the "." at the end.

    Also, create an A record for sprers.eu the name server in this example:

    ; ; BIND data file for local loopback interface ; $TTL @ IN SOA sprers.eu sprers.eu ( 1 ; Serial ; Refresh ; Retry ; Expire ) ; Negative Cache TTL ; @ IN NS sprers.eu ns IN A ;also list other computers box IN A

    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 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 and add the following:

    zone "sprers.eu" { type master; notify no; file "/etc/bind/db"; };

    Note: replace with the first three octets of whatever private network you are using. Also, name the zone file db in the example appropriately.

    Now create the file:

    sudo cp /etc/bind/db /etc/bind/db

    Next edit changing the basically the same options as in :

    ; ; BIND reverse data file for local loopback interface ; $TTL @ IN SOA sprers.eu sprers.eu ( 2 ; Serial ; Refresh ; Retry ; Expire ) ; Negative Cache TTL ; @ IN NS ns. 10 IN PTR sprers.eu ; also list other computers 21 IN PTR sprers.eu

    The serial number in the reverse zone needs to be incremented on each changes as well. For each A record you configure in you need to create a PTR record in .

    After creating the reverse zone file restart bind9:

    sudo /etc/init.d/bind9 restart

    Testing

    You should now be able to ping sprers.eu and have it resolve to the host configured above:

    ping sprers.eu

    You can also use the named-checkzone utility that is part of the bind9 package:

    named-checkzone sprers.eu /etc/bind/sprers.eu

    and

    named-checkzone sprers.eu /etc/bind/db

    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 sprers.eu AXFR

    You should see output resolving sprers.eu 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 :

    [] zone "sprers.eu" { type master; file "/etc/bind/sprers.eu"; allow-transfer { @ip_secondary; }; }; [] zone "sprers.eu" { type master; notify no; file "/etc/bind/db"; 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 and add the following declarations for the Forward and Reverse zones:

    [] zone "sprers.eu" { type slave; file "/var/cache/bind/sprers.eu"; masters { @ip_master; }; }; [] zone "sprers.eu" { type slave; file "/var/cache/bind/db"; masters { @ip_master; }; }; []

    Note: replace @ip_master with the IP Address of the Primary. The zone file must be in because, by default, AppArmor only allows write access inside it (this was made specifically for a slave configuration. See AppArmor's configuration in ).

    Restart the server, and in you should see something similar to:

    sysloggz:May 14 smith named[]: zone sprers.eu: transferred serial sysloggz:May 14 smith named[]: transfer of 'sprers.eu' from # end of transfer sysloggz:May 14 smith named[]: slave zone "sprers.eu" (IN) loaded (serial )

    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 sprers.eu from a host configured to use the Secondary as well as the Primary for name resolution. If all goes well the Secondary should resolve sprers.eu.

    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

    The Chroot Enviroment

    Create the following directory structure

    $ sudo mkdir -p /chroot/named $ cd /chroot/named $ sudo mkdir -p dev etc/namedb/slave var/run

    Set permissions for chroot environment

    $ sudo chown root:root /chroot $ sudo chmod /chroot $ sudo chown bind:bind /chroot/named $ sudo chmod /chroot/named

    Create or move the bind configuration file.

    $ sudo touch /chroot/named/etc/sprers.eu

    or

    $ sudo cp /etc/bind/sprers.eu /chroot/named/etc

    Give write permissions to the user bind for /chroot/named/etc/namedb/slave directory.

    $ sudo 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/sprers.eu file will need to have directory names that designate the slave directory. An example zone definition is listed below.

    zone "sprers.eu" { type slave; file "slaves/sprers.eu"; masters { ; }; };

    Create the devices BIND9 requires

    $ sudo mknod /chroot/named/dev/null c 1 3 $ sudo 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.

    $ sudo 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/sprers.eu"

    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/sprers.eu Remember that this path is relative to the root set by -t.

    The sprers.eu file must also recieve extra options in order to run correctly below is a minimal set of options:

    /chroot/named/etc/sprers.eu: options { directory "/etc/namedb"; pid-file "/var/run/sprers.eu"; statistics-file "/var/run/sprers.eu"; };

    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

    $ sudo /etc/init.d/sysklogd restart $ sudo /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 :

    $ sudo /etc/init.d/bind9 start

    To stop it, use :

    $ sudo /etc/init.d/bind9 stop

    Finally, to restart it, run

    $ sudo /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.)

    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 and add the following:

    logging { channel sprers.eu { file "/var/log/sprers.eu"; // 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 sprers.eu { file "/var/lib/bind/sprers.eu"; // Set the severity to dynamic to see all the debug messages. severity debug 3; }; category queries { sprers.eu; }; };

    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:

    sudo /etc/init.d/bind9 restart

    You should see the file fill with BIND9 log information. This is a simple example of the BIND9 logging options available see sprers.eu manual for more information.

    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

    Online Recources

    "ISC's BIND9 Manual"

    TLDP's "DNS HOWTO" (For General Overview)

    "Chroot BIND Howto"

    Debian BIND Wiki

    BIND reference guide

    Printed Resources

    "DNS & BIND" - Paul Albitz & Cricket Liu - 5th Edition - "O'Reilly Press" (sprers.eu)

    DNS & BIND Cookbook - Cricket Liu - 4th Edition - "O'Reilly Press" (sprers.eu)


    CategoryNetworkingCategoryInternet

    BIND9 check zone file &#; How we do it

    Do you want to check your BIND9 zone file in your Ubuntu server? We can help you.

    BIND9 is the DNS server used in Ubuntu servers and the zone file holds the domain details.

    The command named-checkzone checks BIND9 zone files in the server to avoid DNS errors.

    At Bobcares, we get requests to check BIND9 zone files, as a part of our Server Management Services.

    Today, let&#;s see how our Support Engineers check the zone file in an Ubuntu server.

     

    What is BIND9?

    Basically, a DNS lookup resolves a domain name into an IP address. A web browser displays a webpage after a DNS lookup. This is where BIND has a role to play.

    BIND aka Berkeley Internet Name Domain is a flexible, full-featured DNS system. Above all, this open-source software allows a user to publish the DNS information on the Internet. Hence it resolves DNS queries quickly.

    BIND is a commonly used DNS server. And BIND9 is the package used for Ubuntu servers. The named is the service that executes the DNS server daemon. The default port of the named service is

     

    A quick look at zone file in BIND9

    A zone file is a text-based file stored in a DNS server. This file contains the mapping between the domain name and IP address. A zone file can be a DNS master file or a file authoritatively describing a zone.

    The file usually contains A record, MX record, domain name, mail servers, nameservers details and so on. So, this file is critically important as it holds the domain details.

    Any error in this file can cause trouble while loading the domain. Because DNS lookup resolves a domain with the help of this zone file.

    Let&#;s see how our Support Engineers check a DNS zone file.

     

    How to check the zone file?

    A zone file is a text file so it can contain syntax errors. Hence we need to check the syntax and integrity of this important configuration file. For this, we can make use of the command, .

    The command checks named as it does, while loading a zone. And the command usage is as,

    The output gives an OK status if the zone file does not have any error. Here is a sample output,

    BIND9 check zone file.

    Alternatively, we can check the configuration file of BIND. For this, we can make use of the command, . The command usage is as,

    If the file has any syntax error, the output will mention this.

     

    [Still, having trouble in checking BIND9 configuration? &#; We can help you.]

     

    Conclusion

    In short, to check the BIND9 zone file we can use the command named-checkzone. Today, we saw how our Support Engineers check the zone file in an Ubuntu server.

    PREVENT YOUR SERVER FROM CRASHING!

    Never again lose customers to poor server speed! Let us help you.

    Our server experts will monitor & maintain your server 24/7 so that it remains lightning fast and secure.

    GET STARTED

    var google_conversion_label = "owonCMyG5nEQ0aD71QM";

    BIND Configuration Files

    Sample Zone Statements

    Most changes to the file of a master or slave nameserver concerns adding, modifying, or deleting statements. While these statements can contain many options, most nameservers use few of them. The following statements are very basic examples that may be used in a master-slave nameserver relationship.

    A statement on a primary nameserver hosting the domain may look like Figure

    Figure Example of a simple master statement

    This statement names the zone , sets the as , tells to read the file to configure the zone, and to allow no updates by any other hosts.

    A slave server's statement for might look like Figure

    Figure Example of a simple slave statement

    This statement tells on the slave server to look to the master server to find out the configuration information for the zone called . The information the slave server receives from the master server is saved in the file.

    Error in named-checkzone: DNS zone error:( out of zone) has no addresses records (A or AAAA)

    If you pass or , will succeed fully. Look in the man page for the explanation of .

    Basically does post-load zone integrity checks, and defaults to :

    Mode "full" checks that delegation NS records refer to A or AAAA record (both in-zone and out-of-zone hostnames). It also checks that glue address records in the zone match those advertised by the child. Mode "local" only checks NS records which refer to in-zone hostnames or that some required glue exists, that is when the nameserver is in a child zone.

    First this explains why the zone still loads even if named-checkzone fails in your run: the errors you get come from checks done after the zone, by doing here real DNS queries.

    In fact, it tries to query for and it fails, hence your error, if you do you can see:

    answered Nov 26, at

    user avatar
    Patrick MevzekPatrick Mevzek

    1, gold badges silver badges bronze badges

    bind9 named-checkzone failing with SOA record not at top of zone

    I set up bind9 perfectly a year ago but neglected to document exactly what I done, and now something has changed and I am struggling to fix it. The problem manifested itself first from the DHCP clients which are now unable to resolve the DHCP/NS host on the LAN.

    Checking my bind config with gives an error:

    Of course doesn't load the zones either.

    This is the zone file:

    and my only other zone file gives the same result:

    This is the bind config:

    and the zones:

    I'm not quite sure what other config is relevant here so I'm going to show everything I can think of.

    could be a worry:

    The msg is irrelevant I assume, but doing a status shows this:

    Running a simple look-up on the host:

    asked Sep 8, at

    user avatar
    AdamAdam

    silver badge77 bronze badges

    bind check zone file for errors

    Read these next

    This is absolutely killing me. I've been pulling my hair out trying to find the "syntax" error, but I can't seem to. I thought I knew how to read/write zone files

    I decided a couple of days ago that I needed to learn Linux more, so I decided to build a sinkhole DNS server. I found this article here:

    sprers.eu

    but wanted to use CentOS to do it. So I whipped up a CentOS machine on an old PC I had laying around. Got Bind installed, and trying to get this to work.

    Basically, what I want this box to do is forward legitimate requests from my internal DNS to my ISP's DNS. The blocked domains file has syntax like this:

    zone "sprers.eu"  {type master; file "/var/named/chroot/etc/namedb/sprers.eu";};

    When I try to start bind (service named start) each zone in the file above records the following error:

    dns_rdata_fromtext: /etc/namedb/sprers.eu near 'NS' : syntax error

    I can't find it.

    My sprers.eu file is configured to answer queries  from the local network, and forward to my ISP.

    The final line is

    include "/etc/namedb/blackhole/sprers.eu"; if I comment this out, bind starts properly, and I can run nslookup with 0 errors.

    I've attached the file sprers.eu Basically, all of the domains named in the sprers.eu file need to be pointed to an IP that I control. For this test, I wanted it pointed back to the box I'm configuring. Eventually, this will be in my DMZ and I'll point the bad requests to a web server so I can track the hosts attempting to access bad domains.

    I'd appreciate some help either a.) finding the syntax error in the hosts file, or b.) rewriting the hosts file to accomplish the task at hand.

    Thanks ahead!

    Mike

    attach_sprers.eu Bytes

    bind9 named-checkzone failing with SOA record not at top of zone

    I set up bind9 perfectly a year ago but neglected to document exactly what I done, and now something has changed and I am struggling to fix it. The problem manifested itself first from the DHCP clients which are now unable to resolve the DHCP/NS host on the LAN.

    Checking my bind config with gives an error:

    Of course doesn't load the zones either.

    This is the zone file:

    and my only other zone file gives the same result:

    This is the bind config:

    and the zones:

    I'm not quite sure what other config is relevant here so I'm going to show everything I can think of.

    could be a worry:

    The msg is irrelevant I assume, but doing a status shows this:

    Running a simple look-up on the host:

    asked Sep 8, at

    user avatar
    AdamAdam

    silver badge77 bronze badges

    BIND9ServerHowto

    Tag/sprers.eu

    Content Cleanup Required
    This article should be cleaned-up to follow the content standards in the Wiki Guide. More info

    Note: There are some issues with this Howto, too numerable to fix quickly, and it requires bringing up to standard. I'm mentioning this to help anyone to avoid the unnecessary time trying to resolve their DNS, owing the the inconsistencies in this document, particularly if you're new to DNS configuration. One example is here

    box IN A

    in all other places, the document uses the machine name example ns. Here it changes to box (I believe the author was simply trying to show that additional computers would be listed, but failed to use a different address for box. I modified the example file to give box an address of ).

    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, bind check zone file for errors. 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.

    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, bind check zone file for errors.

    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.

    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 direct3d virtualbox error 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 Bind check zone file for errors, 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.

    There are bind check zone file for errors of different DNS record types, but some of the most common types are covered below.

    Address Records

    The most commonly used type of record. This record maps an IP Address to a hostname.

    www IN A

    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

    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 sprers.eu [] mail IN A

    Name Server Records

    Used to define which servers serve copies of this zone. It must point to an A record, not a CNAME, bind check zone file for errors.

    This is where Primary and Secondary servers are defined. Stealth servers are intentionally omitted.

    IN NS sprers.eu [] ns IN A

    BIND9 Configuration files are stored in:

    /etc/bind/

    The main configuration is stored in the following files:

    /etc/bind/sprers.eu /etc/bind/sprers.eus /etc/bind/sprers.eu

    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 :

    [] forwarders { ; ; }; []

    (where and 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

    If all goes well you should see output similar to:

    ; <<>> DiG P1 <<>> -x ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 [] ;; Query time: 1 msec ;; SERVER: #53() ;; WHEN: Mon Nov 26 ;; MSG SIZE rcvd: 93

    The dig command can also be used to query other domains for example:

    dig sprers.eu

    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 sprers.eu. Simply replace sprers.eu 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 :

    [] zone "sprers.eu" { type master; file "/etc/bind/sprers.eu"; }; []

    Now use an existing zone file as a template:

    sudo cp /etc/bind/sprers.eu /etc/bind/sprers.eu

    Edit the new zone file change to the FQDN of your server, leaving the additional "." at the end. Change to the nameserver's IP Address and to a valid email address, but with a "." instead of the "@". also leaving the "." at the end.

    Also, create an A record for sprers.eu the name server in this example:

    ; ; BIND data file for local loopback interface ; $TTL @ IN SOA sprers.eu sprers.eu ( 1 ; Serial ; Refresh ; Retry ; Expire ) ; Negative Cache TTL ; @ IN NS sprers.eu ns IN A ;also list other computers box IN A

    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 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 and add the following:

    zone "sprers.eu" { type master; notify no; file "/etc/bind/db"; };

    Note: replace with the first three octets of whatever private network you are using. Also, bind check zone file for errors, name the zone file db in the example appropriately.

    Now create the file:

    sudo cp /etc/bind/db /etc/bind/db

    Next edit changing the basically the same options as in :

    ; ; BIND reverse data file for local loopback interface ; $TTL @ IN SOA sprers.eu sprers.eu ( 2 ; Serial ; Refresh ; Retry ; Expire ) ; Negative Cache TTL ; @ IN NS ns. 10 IN PTR sprers.eu ; also list other computers 21 IN PTR sprers.eu

    The serial number in the reverse zone needs to be incremented on each changes as well. For each A record you configure in you need to create a PTR record in.

    After creating the reverse zone file restart bind9:

    sudo /etc/init.d/bind9 restart

    Testing

    You should now be able to ping sprers.eu and have it resolve to the host configured above:

    ping sprers.eu

    You can also use the named-checkzone utility that is part of the bind9 package:

    named-checkzone sprers.eu /etc/bind/sprers.eu

    and

    named-checkzone sprers.eu /etc/bind/db

    This is a great way to make sure you bind check zone file for errors 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 sprers.eu AXFR

    You should see output resolving sprers.eu to your nameserver.

    Secondary Master Server configuration

    Once a Primary Bind check zone file for errors 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, bind check zone file for errors, the zone transfer needs to be allowed. Add the allow-transfer option to the sample Forward and Reverse zone definition in :

    [] zone "sprers.eu" { type master; file "/etc/bind/sprers.eu"; 2012 burst error correction .aspx id { @ip_secondary; }; }; [] zone "sprers.eu" { type master; notify no; file "/etc/bind/db"; allow-transfer { @ip_secondary; }; }; []

    Note: replace @ip_secondary with the actual IP Bind check zone file for errors of your secondary server.

    Next, on the Secondary Master, install the bind9 package the same way as the primary. Then edit the and add the following declarations for the Forward and Reverse zones:

    [] zone "sprers.eu" { type slave; file "/var/cache/bind/sprers.eu"; masters { @ip_master; }; }; [] zone "sprers.eu" { type slave; file "/var/cache/bind/db"; masters { @ip_master; }; }; []

    Note: replace @ip_master with the IP Address of the Primary. The zone file must be in because, by default, AppArmor only allows write access inside it (this was made specifically for a slave configuration. See AppArmor's configuration in ).

    Restart the server, and in you should see something similar to:

    sysloggz:May 14 smith named[]: zone sprers.eu: transferred serial sysloggz:May 14 smith named[]: transfer of 'sprers.eu' from # end of transfer sysloggz:May 14 smith named[]: slave zone "sprers.eu" (IN) loaded (serial )

    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 sprers.eu from a host configured to use the Secondary as well as the Primary for name resolution. If all goes well the Secondary should resolve sprers.eu.

    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

    The Chroot Enviroment

    Create the following directory structure

    $ sudo mkdir -p /chroot/named $ cd /chroot/named $ sudo mkdir -p dev etc/namedb/slave var/run

    Set permissions for chroot environment

    $ sudo chown root:root /chroot $ sudo chmod /chroot $ sudo chown bind:bind /chroot/named $ sudo chmod /chroot/named

    Create or move the bind configuration file.

    $ sudo touch /chroot/named/etc/sprers.eu

    or

    $ sudo cp /etc/bind/sprers.eu /chroot/named/etc

    Give write permissions to the user bind for /chroot/named/etc/namedb/slave directory.

    $ sudo 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/sprers.eu file will need to have directory names that designate the slave directory. An example zone definition is listed below.

    zone "sprers.eu" { type slave; file "slaves/sprers.eu"; masters { ; }; };

    Create the devices BIND9 requires

    $ sudo mknod /chroot/named/dev/null c 1 3 $ sudo 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.

    $ sudo 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/sprers.eu"

    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/sprers.eu Remember that this path is relative to the root set by -t.

    The sprers.eu file must also recieve extra options in order to run correctly below is a minimal set of options:

    /chroot/named/etc/sprers.eu: options { directory "/etc/namedb"; pid-file "/var/run/sprers.eu"; statistics-file "/var/run/sprers.eu"; };

    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

    $ sudo /etc/init.d/sysklogd restart $ sudo /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 :

    $ sudo /etc/init.d/bind9 start

    To stop it, use :

    $ sudo /etc/init.d/bind9 stop

    Finally, to restart it, run

    $ sudo /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.)

    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 and add the following:

    logging { channel sprers.eu { file "/var/log/sprers.eu"; // 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 sprers.eu { file "/var/lib/bind/sprers.eu"; // Set the severity to dynamic to see all the debug messages. severity debug 3; }; category queries { sprers.eu; }; };

    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:

    sudo /etc/init.d/bind9 restart

    You should see the file fill with BIND9 log information. This is a simple example of the BIND9 logging options available see sprers.eu manual for more information.

    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

    Online Recources

    "ISC's BIND9 Manual"

    TLDP's "DNS HOWTO" (For General Overview)

    "Chroot BIND Howto"

    Debian BIND Wiki

    BIND reference guide

    Printed Resources

    "DNS & BIND" - Paul Albitz & Cricket Liu - 5th Edition - "O'Reilly Press" (sprers.eu)

    DNS & BIND Cookbook - Cricket Liu - 4th Edition - "O'Reilly Press" (sprers.eu)


    CategoryNetworkingCategoryInternet

    Finding a Syntax Error in a Zone Data File

    Problem

    You need to find a syntax error in a zone data file.

    Solution

    Find the log messages from the most recent restart or reload of the name server, reloading again if necessary, as described in Section Then look for a message indicating the line of the zone data file that contains the error. For example:

    Jun 25 ns1 named[]: starting BIND Jun 25 ns1 named[]: using 1 CPU Jun 25 ns1 named[]: loading configuration from /etc/sprers.eu Jun 25 ns1 named[]: listening on IPv4 interface fxp0, #53 Jun 25 ns1 named[]: listening on IPv4 interface lo0, #53 Jun 25 ns1 named[]: command channel listening on # Jun 25 ns1 named[]: dns_rdata_fromtext: sprers.eue near eol: unexpected end of input Jun 25 ns1 named[]: zone sprers.eue/IN: loading master file sprers.eu example: unexpected end of input Jun 25 ns1 named[]: running

    And, of course, you can start your BIND 9 name server with -g to force it to run in the foreground and print errors to stderr.

    If youd rather not start a new named process, you can use the BIND 9 named-checkzone program, as described in Recipe Section Like named-checkconf, named-checkzone is built with the same routines that named uses. To run bind check zone file for errors, specify the domain name of the zone and the name of the zone data file as arguments:

    # named-checkzone sprers.eue sprers.eue dns_rdata_fromtext: sprers.eue near eol: unexpected end of input zone sprers.eue/IN: loading master file sprers.eue: unexpected end of input

    Discussion

    Since the master file format didn change between BIND 8 and BIND 9, you can also use named-checkzone on zone data files you load on your BIND 8 name server. The only difference you might encounter is that BIND 8 name servers can be configured to allow multiple CNAME records attached to the same domain name, while BIND 9 name servers can .

    See Also

    Sectionfor using named-checkzone to check a zone data file.


    Getting Started

    Zone Data

    BIND Name Server Configuration

    Electronic Mail

    BIND Name Server Operations

    Delegation and Registration

    Security

    Interoperability and Upgrading

    Resolvers and Programming

    Logging and Troubleshooting

    IPv6

    show all menu

    BIND Configuration Files

    Sample Zone Statements

    Most changes to the file of a master or slave nameserver concerns adding, modifying, or deleting statements. While these statements can contain many options, most nameservers use few of them. The following statements are very basic examples that may be used in a master-slave nameserver relationship.

    A statement on a primary nameserver hosting the domain may look like Figure

    Figure Example of a simple master statement

    This statement names the zone sets the astells to read the file to configure the zone, and to allow no updates by any other hosts.

    A slave server's statement for might look like Figure

    Figure Example of a simple slave statement

    This statement tells on the slave server to look to the master server to find out the configuration information for the zone called . The information the slave server receives from the master server is saved in the file.

    Command named-checkconf checks the syntax only of a DNS (bind) configuration file, bind check zone file for errors. The file is parsed and checked for syntax errors, along with all files included by it. If there is no file specified with the command, /etc/sprers.eu is read by default.

    1. Check bind9 (DNS) Configuration

    In case of any changes done in the bind configuration, I recommend checking the DNS configuration file before restarting the service.

    If the bind is running in chroot environment use the below command also along with the above command

    The above command will show nothing if there is no error found in the configuration file. In case of any error will be displayed as output.

    2. Check Bind Zone File

    To check the syntax of the zone file using the command below. It will show the result in both cases.

    Sample output;

    zone sprers.eu: loaded serial OK

    3. Check Configuration file in Older version of Bind

    If you are using an older version of the bind, bind check zone file for errors, you can have also checked the configuration using the below command.

    Sample Outut:

    zone sprers.eu: loaded serial 42 zone localhost/IN: loaded serial 42 zone sprers.eu: loaded serial zone sprers.eu: bind check zone file for errors serial zone sprers.eu: loaded serial 42 zone sprers.eu: loaded bind check zone file for errors 42

    BIND zone file backend¶

    • Native: Yes
    • Master: Yes
    • Slave: Yes
    • Superslave: Experimental
    • DNSSEC: Yes
    • Disabled data: No
    • Comments: No
    • API: Read-only
    • Zone caching: Yes (except in hybrid mode)
    • Module name: bind
    • Launch:

    The BIND backend started life as a demonstration of the versatility of PowerDNS but quickly gained in importance when there appeared to be demand for a BIND ‘work-alike’.

    The BIND backend parses a BIND-style and extracts information about zones from it, bind check zone file for errors. It makes no attempt to honour other configuration flags, which you should configure (when available) using the PowerDNS native configuration.

    Unique to this PowerDNS backend is that it serves from plain zone files, which allows for hand-crafting zone files, only takes a tiny footprint in terms of server resource usage while being performant efficiently.

    Note

    Because this backend retrieves its configuration from plain files and not a database, the HTTP API is unable to process changes for this backend. This effectively makes the API read-only for zones hosted by the BIND backend.

    Configuration Parameters¶

    Location of the BIND configuration file to parse.

    PowerDNS does not support every directive supported by BIND. It supports the following blocks and directives:

      Interval in seconds to check for zone file changes. Default is 0 (disabled).

      See Operation section for more information.

      Filename to store and access our DNSSEC metadatabase, empty for none. To slave DNSSEC-enabled domains (where the RRSIGS are in the AXFR), a is required. This is because the PRESIGNED domain metadata is set during the zonetransfer.

      You can use to make this database file for you.

      Warning

      If this is left empty on slaves and a presigned zone is transferred, it will (silently) serve it without DNSSEC. This in turn results in serving the domain as bogus.

      SQLite3 journal mode to set. The default is WAL. Set to empty to leave the journal mode alone.

      Setting this option to makes PowerDNS ignore out of zone records when loading zone files.

      Specifies file where to read list of autoprimaries. BIND backend only checks IP address of primary server.

      The file must contain one IP and account per line, separated by whitespace.

      BIND backend can only read this file, not write it.

      When a new zone is configured via the autosecondary mechanism, bindbackend writes a zone entry to this file.

      Your file should have an statement to make sure this file is read on startup.

      Operation¶

      On launch, the BIND backend first parses the to determine which zones need to be loaded. These will then be parsed and made available for serving, as they are parsed. So a with zones may take 20 seconds to load, but after 10 seconds, zones will already be available. While a domain is being loaded, it is not yet available, to prevent incomplete answers.

      Reloading is currently done only when a request (or zone transfer) for a zone comes in, and then only after bind-check-interval seconds have passed after the last check. If a change occurred, access to the zone is disabled, the file is reloaded, access is restored, and the question is answered. For regular zones, reloading is fast enough to answer the question which lead to the reload within the DNS timeout.

      If bind-check-interval is specified as zero, no checks will be performed until the is given.

      Please note that also the slave-cycle-interval setting controls how often a master would notify a slave about changes, bind check zone file for errors. Especially in ‘hidden master’ configurations, where servers usually don’t receive regular queries, you may want to lower that setting to a value as low as bind-check-interval.

      pdns_control commands¶

      Add zone from to PowerDNS’s BIND backend. Zone will be loaded at first request.

      Note

      This does not add the zone to the bind-config file.

      Output an extended status of a domain or domains, containing much more information than the simple domain status, like the number of records currently loaded, whether pdns is master or slave for the domain, the list of masters, various timers, etc

      Output status of domain or domains. Can be one of:

      • ,
      • or
      • .

      Lists all zones that have problems, and what those problems are.

      Reloads a zone from disk NOW, reporting back results.

      Reread the BIND configuration file (), bind check zone file for errors. If parsing fails, the old configuration remains in force and reports the error. Any newly discovered domains are read, bind check zone file for errors, discarded domains are removed from memory.

      All zones with a changed timestamp are reloaded at the next incoming query for them.

      Performance¶

      The BIND backend does not benefit from the packet cache as it is fast enough on its own. Furthermore, on most systems, there will be no benefit in using multiple CPUs for the packetcache, so a noticeable speedup can be attained by specifying in .

      Master/slave/native configuration¶

      Master¶

      Works as expected. At startup, bind check zone file for errors, no notification storm is performed as this is generally not useful. Perhaps in the future the BIND backend will attempt to store zone metadata in the zone, allowing it to determine if a zone has changed its serial since the last time notifications were sent out.

      Changes which are discovered when reloading zones do lead to notifications however.

      Slave¶

      Also works as expected. The BIND backend expects to be able to write bind check zone file for errors a directory where a slave domain lives. The incoming zone is stored as ‘sprers.eu’ and atomically renamed if it is retrieved successfully, and parsed only then.

      In the future, this may be improved so the old zone remains available should parsing fail.

      Native¶

      PowerDNS has the concept of “native” zones that have the in the BIND configuration file. These zones are neither a master (no notifies are sent) nor a slave zone (it will never be AXFR’d in). This means that the replication mechanism for these zone is not AXFR but out of band, e.g. using. Changes to native zones are picked up in the same way as master and slave zones, see Operation.

      Native zones in the BIND backend are supported since version of the PowerDNS Authoritative Server.

      Note

      Any zone with no set (an error in BIND) is assumed to be native.

      2 Comments

      Leave a Comment