BIND
BIND is an open source software package for name resolution in the Domain Name System. Its name goes back to the Berkeley Internet Name Domain Server, short BIND server. In addition to the server, the program package comprises a client and test programs. The server is by far the most widespread of its kind on the Internet. Due to its widespread use and the timely implementation of the current DNS RFCs BIND applies for years as a DNS reference software.
History
Before there was DNS name resolution to IP addresses on lists was (/ etc / hosts.txt, see / etc / hosts on today's Unix systems ) made that had to be present on every computer on the Internet. Changes were first carried out manually on a master server and then distributed file download to the individual computers. With an increasing number of IP subscribers, this method has become increasingly unwieldy.
1983 has been specified by Paul Mockapetris the Domain Name System (DNS). Jeeves - - In the same year, the first DNS software has been implemented on a DEC computer. A little later the first three Internet root servers went into operation.
Early 1980s was working at the University of Berkeley in the development of UNIX. Some students began to write a UNIX DNS software that they named BIND (Berkeley Internet Name Domain ). BIND has been constantly evolving, and version 4 was the global standard. After the Berkeley university had set the development of the software, the responsibility for a short time by the DEC and then taken over by Vixie Enterprises was. Paul Vixie at the time was the driving force behind the project.
As of version 4.9.3 BIND was the responsibility of the non-profit organization ISC ( Internet Software Consortium - from 2004: Internet Systems Consortium) on. Version 8 was completed in 1997. 1999 ISC commissioned the company Nominum Inc., to develop the Version 9. Its first version of BIND 9.0.0 was released on 16 September 2000. BIND 9 is now ( early 2007 ) standard and, together with the still widespread version 8 the backbone of the global domain name system.
On 1 April 2009 the development of BIND 10 began the BIND version was 10 on February 21, 2013: 1.0.0 released
Security
Version 4 has long been considered outdated and the continued operation of BIND 4 servers as a security risk; the further development of BIND 8 was set in 2007. ISC recommends that all DNS administrators the fastest possible migration to BIND 9, this extensive information is provided on the ISC web site. Because of the given widest possible interoperability between the different versions there is no technical constraint to migration, which is why developers sometimes have to convince people this, eg [email protected] on the mailing list.
In February 2008, Dan Kaminsky discovered a new attack method to allow cache poisoning in a short time to redirect the user through fake DNS responses to other servers. This is to fill a gap in the design of the Domain Name System, the next BIND also several other name servers were affected. In collaboration with Name Server developers and operators, including Paul Vixie, patches have been developed to reduce the likelihood of a successful attack. In July 2008, Kaminsky published details of the vulnerability and estimated that there were 41% of DNS servers vulnerable.
Configuration
The behavior of BIND's central program component, the daemon "named" is determined by the configuration and zone files, which can be manually created or modified by the administrator or automatically via scripts, but also with the help of front ends. For the basic operation of at least two files are necessary, once the configuration file, often called " named.conf ", and each zone has a zone file whose name is usually formed from the zone name and the file extension ". Db". Instead of plain text files can also databases that are used as a source, for example, BDB, setting up an appropriate driver module must be compiled with.
The official BIND documentation is the BIND 9 Administrator Reference Manual, shortly called ARM. They will give you a comprehensive, yet comprehensible overview of all the configuration directives as well as the construction of the zone files.
Zone files
The concept of zone was coined in contrast to domain because, although they related to each other, but are not necessarily congruent: a zone can by no means be limited to host declarations within a domain represent a subset of a domain and on the other, but references to hosts included in " foreign " domains.
The master zone files contain at least one SOA resource record and one or more meaningful for the zone name server (NS Resource Records) to continue any number of other Resource Records ( RRs) such as A or PTR resource records Resource Records. In general, it is listed as RRs:
Left side [optional: time-to -live value ] [optional: Class- Name ] Type Right
Left side and Right side are basically strings whose format is determined by the type. Thus, the RRs provide pairs of values is separated by the type assignment - A, NS, SOA, etc. - and optional additional attributes, namely a time-to -live value and a class name ( "IN" for the Internet, which in the absence of the class specified is assumed by default, and " CH " for CHAOSNET and " HS" for Hesiod, two names for historical precursors of Internet development, now irrelevant). Left side can also be empty ( as white space, ie a space or tab character ), then whichever is the left - side value of the previous RR.
Consequently, the possible queryable information and the right the corresponding response values are listed to the left forever. Thus provides an A RR to a host name assigned IP address back ( "localhost IN A 127.0.0.1 "); PTR RRs, however, serve the reverse case, the assignment of specific host names to IP addresses queried (reverse DNS, "127.0.0.1 IN PTR localhost. ").
Zone files for forward and reverse lookup must be formulated consistently; as well as principle is that for each queryable information a RR must be present in the relevant zone file: there is no automatic deductive derivation of any DNS information, as it would be conceivable as for providing the reverse DNS resolution ( by would answer ) - Answer: - eg PTR requests by " inverse" resolution of existing A RRs right: question left side.
However, so-called " wildcard" RRs are possible in which an asterisk ( "*") is on the left side for any host name. However, these are generally considered problematic because they open up another scenario for attacks on the integrity of a network or service: it will facilitate any computer to assume a false identity.
The zone files are defining the contents of a zone, mainly - but not exclusively - those are the hostnames within a domain ( A RRs, which are by nature most often consulted by DNS clients ). Similarly, one defines the charge of a domain mail server ( MX resource record, mail exchanger ), alias names to existing host name ( CNAME RRs, Canonical Names) or meta- information ( TXT RRs).
Subdomains
Subdomains are defined by so-called zone delegation in the zone file of the parent domain will be to the desired sub-domain name registered as a reference to authoritative for the subdomain, so authentic meaningful name server (and hence an NS RR), these are supplemented often by an A record with the IP address of the subdomain name server for the so-called glue record (the term " glue" - engl for glue -. symbolizes that the hierarchical links between domain and subdomain is produced in this way ).
The latter may (or even must ) be omitted if the subdomain name server is anchored itself neither in the sub- nor the parent domain ( hence lies in a " third " domain for which the just queried name server is not authoritative; BIND 9 has such A RRs as "out -of- zone data" back and refuses to load the relevant zone and thus possibly the program start). While such a situation is otherwise easily implemented, but it will be in most cases - in organizational terms - prefer either to delegate the hosting of the subdomain zone to a name server in this subdomain or " even to do ", in other words: vorzuhalten on the name server of the parent domain.
If a glue record exists, the name server to enable the so-called Smart Answers: in the following example " ns.example.com " after the hostname " sub.example.com " asked ( a different client usually not between host - and domain names), the answer is something like: " An IP address for sub.example.com I do not know. But ns.sub.example.com can help, you can find it at the IP address 192.168.50.1 "Without glue record of the last phrase would disappear, or should be: ". Find the IP address of ns.sub. example.com but yourself! " to the client, who has here provided, upon request itself a negative response, it is ( in accordance with " smart " programming of its resolver library ) optional, instead of evaluating the additional information provided and thus a DNS request to the dissolution of " ns.sub.example.com " save. At this point it is, both in existing and missing glue record, anyway always the responsibility of the resolver to " durchzuhangeln " to the desired sub-domain name server (where he, however, which - considered below - Ability of a name server for recursion use may, if only this is the client in question allowed).
Example of a zone file
The example applies to a domain " example.com" with
- Associated SOA and NS RR ( " ns.example.com " )
- Host a " www.example.com "
- A subdomain " sub.example.com "
The "example.com " domain is " example.com.db " hosted as a zone file to " ns.example.com ":
; time-to -live - directive since BIND v8 at the beginning of a zone; file required; it applies to all RRs without an explicit TTL field: $ TTL 1d; optional directive; all hostnames WITHOUT trailing ". " in this zone are rela -; tive to ff domain (in other words: be implicitly by $ ORIGIN supplemented ): $ ORIGIN example.com. ; unless specified here, the value of $ ORIGIN is implicitly defined by the in - zugehoe; ring zone statement, declared ( in named.conf ) domain name determined, if necessary, can last; Exploder but will be overwritten by $ ORIGIN, so pay attention to consistency; Start of Authority and the competent nameservers are mandatory for a; Zone definition ( "@ " is a wild symbol for the value of $ ORIGIN): @ SOA ns.example.com. hostmaster.example.com. 42 3600 1800 604800 1800 NS ns.example.com. ; has the domain name example.com thus an IP address (which it also; a host name does ): A 192.168.0.100 AAAA 2001: db8 :: 100; makes the world the IP address of the above is conducted in the SOA ns.example.com known: ns A 192.168.0.1 ns AAAA 2001: db8 :: 1; defines the host www.example.com as an alias of example.com: www CNAME @; defines the domain sub.example.com with the; special responsibility nameservers ns.sub.example.com: sub NS ns.sub; Glue: requests for the IP address of the name server; can be answered directly from ns.example.com: ns.sub A 192.168.50.1 On 192.168.50.1 then " sub.example.com " reside another name server for the zone. However, this could just as well be from " ns.example.com " Manage - this is the penultimate example of the RR changes in "sub NS ns ", continues to be the glue record can be omitted since BIND seen here own that one for the subdomain is authoritative ( this term is equal to or discussed further ).
Below the second-level domain hierarchy can define any operator of a name server to taste subdomains, in the same that is the domain registrars reserved, in turn, have access to the name servers of the top - level domains.
Master and slave zones
Since according to the DNS name server specification should be kept redundantly, but grooming identical zone files on two or more independent computers is very cumbersome and error-prone, a distinction is master and slave servers. The latter pick a zone file via zone transfer from an assigned master server. The defined in the SOA record of the zone serial number is checked for changes, only after incrementing the same is done, a slave - sided Apply the zone data; Since BIND v8 a Notify method in which the master server slave notifies the change of zone files exist ( in order to minimize the latency of the zone update ). The administrator can by "notify " - specify exactly which slave must be informed by what the master and "allow -notify " directives. In Example " named.conf " below there is ever a pattern for a master ( "zone " example.com "...") and a slave zone definition ( "zone " example.net "...").
Authoritative Server
We call name server or their responses as authoritative, if the DNS queries can be answered directly from an existing zone file - unlike obtained by recursion and forwarding DNS data that is held in the cache of the server. Master as slave name server can generate equivalent to each other authoritative answers ( even if a slave "only" copies of the master zone holds up ).
Recursion and forwarding
In addition to access to the rights enshrined in their zone files hostname master name server and the recursive dissolving "unknown " host or domain names, while they are, starting from the right, split and directed to the name servers responsible for each top-level and sub-domains. The query starts here at the root name servers whose IP addresses to each server name must be known in advance and which in turn return references to the name servers for the top- level domains.
Configure Responsible DNS administrators their server now, however, so that first one or more ( net ) topologically "neighboring" (or " parent " ) name servers are questioned ( the so-called forwarding ) before a full recursion on the root servers is caused ( to relieve the latter ). It is speculated that in the forwarders, the probability is higher that the needed information ( or parts of it, such as the resolution of the retrieved top-level domain ) is already present in its cache.
From the traffic -minimizing meshing interacting nameservers as well as the caching ( caching) the information obtained with well-defined minimum and maximum " durability periods " result in the optimized, collaborative operation of the Internet-wide domain name system.
While forwarding is enabled by default when a " brand new " BIND distribution (option "forward first; " ), when you enable recursion caution is advised. When a name server, which is accessible from both the intra- as well as from the Internet, you should recursion only to users from the Intranet allow (for example, by a like " option allow-recursion { 192.168.0.0/16 ;}; " ), as this can otherwise be used as a gateway for denial -of-Service and cache poisoning attacks from the Internet.
Configuration file ( named.conf )
The information is stored in different areas. The most important are:
In the Global Access Permissions area, crypto keys and options are defined (see Section BIND option in the online documentation ). In the (optional) server list information about the partner server are included (for example, if a server supports incremental zone transfer ). In the zones list is to be provided for each zone entry included the includes the name of the zone the name of the associated zone files, the Zone Type (master or slave), access permissions, and Options. With the latter already globally defined options can be overwritten (and then only in the context of the respective zone valid). In a minimal configuration of a name server are each a zone file for the resolution of the host name " localhost" in the IP address 127.0.0.1 and the related reverse zone included. In the " named.conf " example below, these are the first two "zone " directives. The associated zone files are trivial and have for example the following appearance ( a possible zone file for the domain " example.com " has already been shown above):
; File " localhost.db ": $ ORIGIN localhost. $ TTL 1d @ IN SOA @ root ( 42; serial nr, a tribute to Douglas Adams 1h; refresh 5m; retry 7d; expire 1d ); minimum TTL IN NS @ IN A 127.0.0.1 IN AAAA :: 1; File " localhost rev.db ": $ ORIGIN 0.0.127.in - addr.arpa. $ TTL 1d @ IN SOA localhost. hostmaster.localhost. ( 42; serial 4h; refresh 30m; retry 7d; expire 1d ); minimum TTL NS localhost. 1 PTR localhost.; File " localhost rev6.db ": $ ORIGIN 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa. $ TTL 1d @ IN SOA localhost. hostmaster.localhost. ( 42; serial 4h; refresh 30m; retry 7d; expire 1d ); minimum TTL NS localhost. 1 PTR localhost. The "root" - or " hint" Zone (. Directive "zone " " IN { type hint; ...}; " in the " named.conf " example ) may be omitted, since a corresponding list of root server is already anchored in the program code. By downloading an actual " named.root " file and embedding as shown but can easily, ie without source code modification and recompilation, to respond to changes (the list of root servers is indeed rarely changed, but in the last December 12, 2008 ).
The format of the " named.root " file corresponds to a normal zone file with NS and A RRs, but without a leading SOA RR. You can - in addition to the downloads IANA - for example, by the command
$ > NS dig. @ a.root - servers.net > named.root be procured, if the current address of the A root name server is known.
The controls section defines a control port as an interface for the rndc control program and in the logging area different types of log files and the assignment of program events ( queries, errors, etc. ) can be set.
Example of a named.conf:
Options { allow-transfer { localhost; 172.27.157.16; }; host -statistics YES; notify YES; forward first; forwarders { 172.27.157.16; }; }; server 172.27.157.16 { bogus no; support- ixfr yes; }; zone " localhost" IN { type master; file " localhost.db "; notify no; }; zone " 0.0.127.in -addr.arpa " IN { type master; file " localhost rev.db "; notify no; }; zone " 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa " IN { type master; file " localhost rev6.db "; notify no; }; zone ". " IN { type hint; file " named.root "; }; zone " example.com" { type master; file " example.com.db "; notify explicit; also-notify { 172.27.157.16; }; }; zone " example.net " { type slave; masters " ns.example.net "; file " slave / example.net.db "; allow- notify " ns.example.net "; }; controls { inet * port 953 allow { localhost; } keys { " rndc -key"; }; }; key " rndc -key" { algorithm hmac -md5; secret " password"; }; logging { channel default- log { file " logs / named.log "; severity debug; print -severity yes; }; category default {default -log; }; channel queries -log {file " logs / queries.log "; severity info; }; category queries { -log queries; }; }; operation
After reading the configuration files BIND accepts all packets that arrive via UDP or TCP on port 53 of the configured interfaces or IP addresses. These packets may be DNS queries and dynamic updates or zone transfers. Normally DNS queries use UDP ( individual IP packets ) only when zone transfers especially in the server responses exceed the maximum IP packet size is changed to TCP.
If a DNS query, so BIND is trying to resolve it using the entries in the zone files. For unknown domain names ( requests for non -authoritative host name ) first of its own, then the cache of the forwarder is checked and last attempted a recursive resolution via the root server in general.
With dynamic DNS update the zone file in question is the runtime of the named daemon updates (RRs are added or even removed ) if the initiating client is authorized and verified it. Dynamic DNS updates are used in particular to make an intranet, where the TCP / IP protocol stack of newly added computers are automatically configured, these prescribed under its current, not of a statically configured zone hostname accessible.
Installation and Operation
On UNIX or Linux systems, BIND is often included. New versions can be downloaded from the Internet, either as a binary package ( for Windows) or as source code. Mean UNIX knowledge is sufficient for the installation and operation of a BIND server. For Windows NT/2000, a compressed binary file is downloaded that contains a utility that supports the creation of named as a system service.
When changes in zone files must not forget to increment the serial number and make known this change BIND, whether through a complete restart of the server a SIGHUP (UNIX ) or the management tools ndc (BIND 8 ) or rndc (BIND 9). Without this signaling only the registered in the zone time-to- live period must elapse before the zone named reloads.
The utility name ndc or rndc means (remote ) name daemon controller. In addition to commands for starting and stopping the daemon and to reload the configuration and zone files, a number of logging and statistical functions available with which the work of the software can be verified. Particularly if BIND is running under operating systems that support threads, or when dynamic zone updates are supported, always, the command rndc stop should definitely be used to stop the service. Before the name server works with rndc which to authorized hosts must be entered in " named.conf "; Data exchange between daemon and rndc is cryptographically protected by a key that must be entered in " named.conf " and " rndc.conf ". By default rndc works on port 953 (based on the area reserved for DNS port 53 ); where appropriate firewall rules need to be adapted.