BIND
| BIND | |
|---|---|
| Basic data
|
|
| developer | Internet Systems Consortium |
| Publishing year | September 16, 2000 (version 9.0.0) |
| Current version |
9.15.5 ( October 2, 2019 ) |
| Current preliminary version | 9.15.1 (June 19, 2019) |
| operating system | unixoid system , Microsoft Windows , OpenBSD |
| programming language | C. |
| category | DNS software |
| License | Mozilla Public License |
| German speaking | No |
| isc.org/software/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 , or BIND Server for short . In addition to the server , the program package includes a client and test programs. The server is by far the most widely used of its kind on the Internet . Due to its widespread use and the timely implementation of the current DNS RFCs , BIND has been used as DNS reference software for years.
history
Before DNS existed, names were resolved into IP addresses using lists (/etc/hosts.txt, cf. / etc / hosts on today's Unix systems), which had to be available on every computer on the Internet. Changes were initially made manually on a master server and then distributed to the individual computers via file download. As the number of IP subscribers increased, this method became increasingly unwieldy.
In 1983 Paul Mockapetris specified the Domain Name System (DNS). In the same year, the first DNS software - JEEVES - was implemented on a DEC computer. A little later, the first three Internet root servers went into operation.
In the early 1980s, the University of Berkeley was working on the further development of UNIX. Some students began writing DNS software for UNIX, which they named BIND (Berkeley Internet Name Domain). BIND was constantly evolving, and version 4 became the worldwide standard. After Berkeley University stopped developing the software, responsibility was briefly taken over by DEC and then by Vixie Enterprises . Paul Vixie was the driving force behind the project at the time.
From version 4.9.3, BIND became the responsibility of the non-profit organization ISC ( Internet Software Consortium - from 2004: Internet Systems Consortium ). Version 8 was completed in 1997. In 1999 ISC commissioned Nominum Inc. to develop version 9. Its first version, BIND 9.0.0, appeared on September 16, 2000. BIND 9 has been the standard since 2007 and, together with version 8, which is still widespread, forms the backbone of the global domain name system .
From August 2007 version 8 was no longer maintained ( deprecated ) and ISC advised all users to switch to version 9.
On April 1st, 2009 the development of Bind 10 began, on February 21st 2013 the version BIND 10: 1.0.0 was published.
On April 23, 2014, the ISC surprisingly announced that it would stop further development of BIND10. One wants to concentrate on the further development of BIND9 in the future.
safety
Version 4 has long been considered obsolete and the continued operation of BIND 4 servers as a security risk; The further development of BIND 8 was also discontinued in 2007. ISC recommends that all DNS administrators migrate to BIND 9 as quickly as possible; extensive information is available on the ISC website. Due to the extensive interoperability between the versions, there is no technical need to migrate, which is why the developers often have to persuade them, e.g. B. on the bind-users@isc.org mailing list .
In February 2008, Dan Kaminsky discovered a new type of attack method that enables cache poisoning to take place in a short time, in order to redirect the user to other servers using fake DNS responses. This is a loophole in the design of the domain name system that affected several other name servers in addition to BIND. In collaboration with name server developers and operators, including Paul Vixie , patches were developed to reduce the likelihood of a successful attack. In July 2008, Kaminsky published details of the vulnerability and estimated that 41% of the DNS servers were still vulnerable.
configuration
The behavior of BIND's central program component, the daemon " named", is determined by configuration and zone files, which can be created or changed manually by the administrator or automatically via scripts, but also with the help of front ends . At least two files are required for basic operation, once the configuration file, often called " named.conf", and one zone file for each zone , the name of which is usually formed from the zone name and the file extension " .db". Instead of plain text files, databases, for example BDB , can also be used as the source; a suitable driver module must be compiled in for this.
The official BIND documentation is the BIND 9 Administrator Reference Manual , or ARM for short. There you get a comprehensive, yet easy to understand overview of all configuration directives and the structure of the zone files.
Zone files
The term zone was coined in contrast to the domain because, although they are related to each other, they are not necessarily congruent : a zone can definitely represent a subset of a domain and, on the other hand, can not be restricted to host declarations within a domain, but rather references to hosts contained in "foreign" domains.
The master zone files contain at least one SOA resource record and one or more name servers ( NS resource records ) that are meaningful for the zone , as well as any number of other resource records (RRs) such as A resource records or PTR resource records . In general, RRs are noted as follows:
Left side [optional: time to live value] [optional: class name] Type right side
LeftSide and RightSide are basically character strings whose format is determined by the type . The RRs therefore represent pairs of values, separated by the type assignment - A, NS, SOAetc. - and optional additional attributes, namely a time-to-live value and a class designation (" IN" for Internet , which is assumed as the default if the class is not specified , and " CH" For CHAOSnet and " HS" for Hesiod , two names for historical preliminary stages of Internet development, meanwhile irrelevant). LeftSide can also be empty (as white space , i.e. blank or tabulator characters), in which case the LeftSide value of the previous RR applies .
This means that the information that can be queried is always noted on the left and the associated response values on the right. An A-RR returns the IP address assigned to a host name (“ localhost IN A 127.0.0.1”); PTR-RRs, on the other hand, are used for the reverse case, the assignment of specific host names to queried IP addresses ( reverse DNS , " 127.0.0.1 IN PTR localhost.").
Zone files for forward and backward resolution must be formulated consistently; As well as in principle, an RR must be present in the relevant zone file for each individual information that can be queried: there is no automatic, deductive derivation of any DNS information, as would be conceivable for the provision of reverse DNS resolution (by adding e.g. PTR inquiries through "inverse" resolution of existing A-RRs - right side : question, left side : answer - would answer).
However, so-called " wildcard " RRs are possible, in which an asterisk (" *") stands for any host name on the left. However, these are generally considered problematic because they open up a further scenario for attacks on the integrity of a network or service: it is made easier for any computer to assume a false identity.
The zone files thus define the content of a zone, essentially - but not exclusively - these are the host names within a domain (i.e. A-RRs, which are naturally most frequently queried by DNS clients). The mail server responsible for a domain ( MX Resource Record , Mail Exchanger), alias names for existing host names (CNAME-RRs, Canonical Names) or meta-information (TXT-RRs) are also defined.
Subdomains
Subdomains are defined by so-called zone delegation : the desired subdomain name is registered in the zone file of the higher-level domain as a reference to the authoritative, i.e. binding, meaningful name server for the subdomain (i.e. an NS-RR), which is often supplemented with an A record with the IP address of the subdomain name server in question, the so-called glue record (the term “glue” - symbolizes that the hierarchical connection between domain and subdomain is established in this way ).
The latter can (or even has to) be omitted if the subdomain name server itself is not anchored in either the sub or the superordinate domain (i.e. in a “third” domain for which the name server just queried is not authoritative; rejects such A-RRs as “ out-of-zone data” and refuses to load the relevant zone and thus possibly the program start). While such a constellation can otherwise be implemented without any problems, in most cases - from an organizational point of view - it will be preferable to either delegate the hosting of the subdomain zone to a name server in this subdomain or to "do it yourself", in other words: to be available on the name server of the higher-level domain.
If there is a glue record, it enables the name server to give so-called smart answers : If in the following example ns.example.com" sub.example.com" is asked for the host name " " (a client usually does not differentiate between host and domain names), the answer is similarly: “ sub.example.comI don't know an IP address for . But it ns.sub.example.comcan help, you can find it under the IP address 192.168.50.1. ”Without a glue record, the last sub-sentence would be omitted, or it would have to be:“ Find out the IP address ns.sub.example.comyourself! ” If his actual request has received a negative response, it is optional (with appropriately “smarter” programming of his resolver library) to evaluate the additional information transmitted instead and thus ns.sub.example.comsave a DNS request to resolve “ ”. At this point it is always the responsibility of the resolver to "work through" to the desired subdomain name server, whether the glue record is available or not (although it uses the recursion capability of a name server, which is considered below may , provided that this is the client in question allowed).
Example of a zone file
The example applies to a domain with " example.com"
- Associated SOA and NS RR ("
ns.example.com") - a host "
www.example.com" - a subdomain "
sub.example.com"
The " example.com" domain is hosted as a zone file " example.com.db" on " ns.example.com":
; die Time-to-live-Direktive ist seit BIND v8 am Beginn einer Zonen-
; datei vorgeschrieben; sie gilt für alle RRs ohne explizites TTL-Feld:
$TTL 1d
; optionale Direktive; alle Hostnamen OHNE nachgestellten "." in dieser Zone sind rela-
; tiv zur ff. Domain (anders ausgedrueckt: werden implizit durch $ORIGIN ergaenzt):
$ORIGIN example.com.
; sofern hier nicht angegeben, ist der Wert von $ORIGIN implizit durch den in der zugehoe-
; rigen zone-Direktive (in named.conf) deklarierten Domainnamen bestimmt, ggf. kann letz-
; terer aber auch durch $ORIGIN ueberschrieben werden, daher ist auf Konsistenz zu achten
; Start of Authority und zustaendiger Nameserver sind obligatorisch für eine
; Zonendefinition ("@" ist ein Joker-Symbol für den Wert von $ORIGIN):
@ SOA ns.example.com. hostmaster.example.com. 42 3600 1800 604800 1800
NS ns.example.com.
; weist dem Domainnamen example.com eine IP-Adresse zu (was ihn somit auch zu
; einem Hostnamen macht):
A 192.168.0.100
AAAA 2001:db8::100
; macht der Welt die IP-Adresse des oben im SOA eingefuehrten ns.example.com bekannt:
ns A 192.168.0.1
ns AAAA 2001:db8::1
; definiert den Host www.example.com als Alias von example.com:
www CNAME @
; definiert die Domain sub.example.com mit dem
; zustaendigen Nameserver ns.sub.example.com:
sub NS ns.sub
; Glue: Anfragen nach der IP-Adresse dieses Nameservers
; können direkt von ns.example.com beantwortet werden:
ns.sub A 192.168.50.1
Another name server for the zone " sub.example.com" must then reside on 192.168.50.1 . However, you could just as easily have it ns.example.commanaged by “ ” - the penultimate RR of the example changes to “ sub NS ns”, the glue record can still be omitted, since BIND automatically recognizes that you are authoritative for the subdomain (this term is will be discussed in more detail shortly).
Below the second-level domain hierarchy, each operator can define a name server at will subdomains, in the same that is the domain registrars reserved, which in turn have access to the name servers of top level domains.
Master and slave zones
Since, according to the DNS specification, name servers should be provided redundantly, but maintaining identical zone files on two or more independent computers is very cumbersome and error-prone, a distinction is made between master and slave servers. The latter fetch a zone file from an assigned master server via zone transfer . The serial number defined in the SOA record of the zone is checked for changes; the zone data is only accepted on the slave side after it has been incremented; Since BIND v8 there has also been a notify procedure in which the master server notifies slaves of changes to zone files (in order to minimize the latency of zone updates). The administrator can use " notify" and " allow-notify" directives to specify which slave is to be notified by which master. In the “named.conf” example below there is a pattern for a master (“ zone "example.com" ...”) and a slave zone definition (“ zone "example.net" ...”).
Authoritative servers
Name servers or their answers are referred to as authoritative if the DNS queries can be answered directly from an existing zone file - in contrast to DNS data obtained through recursion or forwarding, which is held in the server's cache. Master and slave name servers can generate equally authoritative responses to each other (even if a slave “only” holds copies of the master zones).
Recursion and forwarding
In addition to access to the host names anchored in their zone files, name servers also master the recursive resolution of "unknown" host or domain names, starting from the right, breaking them down and sending them to the name servers responsible for the respective top-level and subdomains . The query begins with the root name servers , whose IP addresses must be known to each name server in advance and which in turn return references to the name servers of the top-level domains.
Responsible DNS administrators now configure their server in such a way that one or more (network) topologically "neighboring" (or "higher-level") name servers are queried (so-called forwarding) before a full recursion via the root server is initiated (to relieve the latter). One speculates that the forwarders are more likely to have the required information (or parts of it, such as the resolution of the queried top-level domain) already in their cache.
The optimized, cooperative operation of the Internet-wide domain name system results from the traffic-minimizing meshing of interacting name servers and the intermediate storage (caching) of the information obtained with well-defined minimum and maximum "durability periods".
While forwarding is activated by default in a “brand new” BIND distribution (option “ Forward first;”), caution is advised when activating recursion. When a name server that both the intra - can be reached as well as from the Internet, one recursion should only to users from the Intranet allow (for example, by an option like ". allow-recursion { 192.168.0.0/16; };"), Otherwise it will as a gateway for denial of -Service and cache poisoning attacks from the Internet can be exploited.
Configuration file ( named.conf )
The information is housed in different areas. The most important are:
- Global area
- exactly one "
options {...};" directive - Server list
- any number of "
server {...};" directives - Zone list
- any number of "
zone {...};" directives - controls area
- a "
controls {...};" directive - logging area
- a "
logging {...};" directive
In the global area access permissions, encryption keys and options are defined (see Section BIND Options in the online documentation). The (optional) server list contains information about partner servers (e.g. whether a server supports incremental zone transfer). The zone list contains an entry for each zone to be provided, which contains the name of the zone, the name of the assigned zone file, the zone type (master or slave), access rights and options. The latter can also be used to overwrite globally already defined options (and are then only valid in the context of the respective zone). A minimal configuration of a name server contains a zone file for resolving the host name " localhost" into the IP address 127.0.0.1 and the related reverse zone. In the “named.conf” example below, these are the first two “ zone” directives. The associated zone files are trivial and have e.g. B. the following appearance (a possible zone file for the domain " example.com" was already 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) can be omitted if necessary, since a corresponding list of the root servers is already anchored in the program code. However, by downloading a current " named.root" file and including it as shown, it is easy, i. H. changes can be reacted to without source code modification or recompilation (the list of root servers is rarely changed, but most recently on December 12, 2008).
The format of the " named.root" file corresponds to that of a normal zone file with NS and A RRs, but without a prefixed SOA RR. In addition to downloading it from IANA , it can be e . B. by the command
$> dig NS . @a.root-servers.net >named.root
provided that the current address of the A-Root name server is known.
The controls area defines a control port as an interface for the rndc control program and in the logging area various types of log files and their assignment of program events (queries, errors, etc.) are 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" {
algorithmus 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 { queries-log; };
};
functionality
After reading in the configuration files, BIND receives all packets that arrive via UDP or TCP at port 53 of the configured interfaces or IP addresses . These packets can be DNS queries, dynamic updates, or zone transfers. Normally, DNS requests use UDP (individual IP packets), only if the server responses exceed the maximum IP packet size, especially in the case of zone transfers, is the system switched to TCP.
If there is a DNS query, BIND tries to resolve it using the entries in the zone files. In the case of unknown domain names (requests for non-authoritative host names), first the own cache is checked , then the forwarder's cache and finally a recursive resolution is attempted via the root server.
In the case of dynamic DNS updates , the zone file in question is updated during the runtime of the named daemon (RRs are added or removed again), provided that the initiating client is authorized and verified to do so. Dynamic DNS updates are used in particular to make them accessible under their current host name, which is not specified by a statically configured zone , in an intranet in which the TCP / IP protocol stacks of newly added computers are automatically configured.
Installation and operation
BIND is sometimes included with UNIX or Linux systems. New versions can be downloaded from the Internet either as binary packages (for Windows) or as source code. Medium UNIX knowledge is sufficient to install and operate a BIND server. Windows NT / 2000 downloads a compressed binary file that contains a utility that helps set up named as a system service.
When making changes to zone files, do not forget to increment their serial number and make this change known to BIND, be it through a complete restart of the server, a SIGHUP (UNIX) or via the management tools ndc (BIND 8) or rndc (BIND 9). Without this signaling, the time-to-live period entered in the zone must pass before named reloads the zone.
The utility name ndc or rndc means ( r emote) n ame d aemon c ontroller . In addition to commands for starting and stopping the daemon and for reloading the configuration and zone files, a number of logging and statistics functions are available with which the work of the software can be checked. Especially when BIND runs under operating systems that support threads or when dynamic zone updates are supported, the command rndc stop should always be used to stop the service. Before the name server works with rndc , the authorized hosts must be entered in "named.conf"; the data exchange between the daemon and rndc is cryptographically secured by a key that must be entered in “named.conf” and “rndc.conf”. By default, rndc works via port 953 (based on port 53 reserved for DNS); if necessary, firewall rules must be set up for this.
Web links
- dnstop and DNS statistics collector (English) (dsc)
- DNS server survey (English): 70% of all domains use Bind as a name server
- Secure BIND template . Information on securing a BIND server.
Individual evidence
- ↑ gitlab.isc.org . (accessed on October 28, 2019).
- ↑ Download free open source software from ISC - BIND, Kea, ISC DHCP | Internet Systems Consortium ( English ) 19 June 2019. Accessed July 8 of 2019.
- ↑ src / usr.sbin / bind / . (accessed on October 10, 2018).
- ↑ License text . (English, accessed July 24, 2018).
- ↑ The Berkeley Internet Name Domain Server (PDF; 532 kB) University of California, Berkeley . Retrieved July 17, 2011.
- ↑ BIND software status. (No longer available online.) In: isc.org. Archived from the original on August 17, 2013 ; accessed on August 17, 2013 .
- ↑ BIND 10 The Story So Far… (No longer available online.) In: irc.org. September 5, 2009, archived from the original on May 8, 2012 ; accessed on March 22, 2012 (English).
- ↑ Documentation BIND 10 1.0.0 ( Memento from April 21, 2017 in the Internet Archive )
- ↑ BIND10 1.0.0 is now available
- ↑ Dusan Zivadinovic: ISC stops development on its BIND10 DNS server. In: heise online . April 23, 2014, accessed April 23, 2014 .
- ↑ Information on migrating to BIND 9. (No longer available online.) Archived from the original on November 11, 2008 ; Retrieved April 20, 2017 . Info: The archive link was inserted automatically and has not yet been checked. Please check the original and archive link according to the instructions and then remove this notice.
- ↑ DNS bug discoverer: "Almost half the Internet is still vulnerable" . derStandard.at . Retrieved April 20, 2017.
- ↑ BIND 9 Administrator Reference Manual ( Memento of November 18, 2008 in the Internet Archive )
- ↑ BIND options. (No longer available online.) Archived from the original on November 11, 2008 ; Retrieved April 20, 2017 .
