ABSTRACT: der betrieb eines eigenen nameservers wird anhand von "bind" erklaert. AUDIENCE: junior admin SYSTEM: any unix SECTION: basic unix commands AUTHOR: mond COPYRIGHT: GNU Free Documentation Licence http://www.gnu.org/licenses/fdl.txt der betrieb eines eigenen nameservers ist nicht besonders schwer und benoetigt auch kaum resourcen. so kann ein alter 486er problemlos fuer einige 1000 oder mehr domains nameserver sein. warum sollte man eingenen nameserver haben wollen? * um sich selbst ohne lange ruecksprache mit anderen hostnamen, mailgateways, subdomains eintragen zu koennen. * als nameserver fuer ein internes netz. damit man dort hostnamen und IP addressen vergeben kann und fuer die eigenen rechner einen unabhaengigen nameserver hat. worauf man achten sollte: die IP addresse eines nameserver zu aendern ist meist aufwendig. man sollte ihn also auf jeden fall auf einer IP addresse haben die man langfristig behalten kann. wie wir schon gehoert haben gibt es fuer jede domain i.a. mehrere nameserver die anfragen beantworten koennen. zur wartung ist es allerdings praktisch die daten nur auf einem nameserver eintragen zu muessen und die anderen gleichen dann ihre daten mit dem ersten ab. der nameserver einer domain auf dem man die namen eintraegt wird "primary nameserver genannt" die anderen die die daten von dort wegkopieren nennt man "secundary" server. (man kann mehrere secundary server haben) das bind packet das den "named" nameserer enthaelt ist ueblicherweise bestandteil jeder distribution und laesst sich somit leicht installieren. im file: /etc/bind/named.conf (manchmal auch /etc/named.conf ) liegt das haupt configurationsfile des named. die mit den distributionen mitgelieferten files enthaltn meist schon alle wichtigen standardeintraege. wichtige konfigurationen die man machen will sind: forwarders { 194.152.178.1 ; 194.152.178.10 ; }; mit obigen eintrag wuerde man den named zu einem reinen "forwarder" machen. er wuerde dann nicht selbst abfragen mithilfer der root nameserver und anderer nameserver machen sondern alle anfragen nur an einen der obigen server weiterleiten. ergebnisse wuerde er aber cachen so dass oft gestellte anfragen damit natuerlich schnell beantwortet werden. ohne "forwarders" eintrag ist der nameserver "stand alone" und befraegt selbst die root nameserver und andere nameserver (die root server findet er anhand eines mit der distribution mitgelieferten files das die IP addressen dieser server enthaelt.) zone "maxmeier.at" { type master; file "/etc/bind/maxmeiers.at"; }; obiger eintrag besagt dass dieser named ein primary (master) server fuer die domain "maxmeiers.at" ist und dass sich die daten zu dieser domain im file: /etc/bind/maxmeiers.at befinden ("zone file" genannt). (der filename ist beliebig aber die konvention den filenamen noch der domain zu nennen die er enthaelt ist durchaus sinvoll. der selbe named koennte jetzt gleichzeitig fuer andere domains ein secundary server sein: zone "dorismueller.at" { type slave; file "doris.mueller.at.bak"; masters { 123.45.67.89; }; }; obiger eintrag wuerde besagen dass dieser nameserver ein "secundary" (slave) nameserer fuer die domain dorismueller.at ist und dass der dazugehoerige master server die IP 123.45.67.89 hat. der named wuerde damit versuchen die daten fuer die zone "dorismueller.at" vom nameserver auf 123.45.67.89 abzuholen und eine kopie dieser daten im file "doris.mueller.at.bak" im arbeitsverzeichniss dess nameservers (z.b /var/cache/bind oder /var/named abzulegen. der name des files ist wieder beliebig. die konvention es mit .bak aendern zu lassen deutet darauf hin dass das file nicht das master file sondern nur eine kopie ist. killall -HUP named oder ndc reload sagen dem "named" dass es das named.conf neu lesen soll. (auf grossen nameservern mit vielen zonen sollte man wenn sich nur einzelne zonen geaendert haben nicht den ganzen server restarten) danach empfiehlt sich ein blick in die logfiles (syslog, message, .. ) ob der named irgendetwas an der configuration zu beanstanden hatte. hat man einen neuen secundary eintrag so sollte man schaun ob das entsprechende zonefile nach einigen sekunden geladen wurde. weiters mit nslookup, dig, host oder aehnlichem ueberpruefen ob der nameserver wirklich auf anfragen antwortet. laufen primary und alle secundary server einer neuen domain zur zufriedenheit so muss man diese natuerlich noch bei der darueberliegenden domain ankuendigen. fuer die ISO laender domain .at, .de, ... erledigen das die domainvergabestellen der jeweiligen laender. .com, .net, .org werden inzwischen von mehreren verwaltern betrieben. die meistern provider haben mit einem davon vertraege die es ihenen erlauben kostenguenstig domains anzumelden. d.h. man fragt am besten zuerst beim eigenen provider nach. erst wenn der uebergeordente domain inhaber die nameserver eingetragen hat weiss der rest der welt wer fuer die domain verantwortlich ist und anfragen landen beim eigenen server. der transfer zwischen primary und secundary server passiert indem named ein programm namens "named-xfer" aufruft. man kann es testweise auch haendisch verwenden: /usr/sbin/named-xfer -f bla.txt -z maxmeier.at ns1.meierprovider.at wuerde versuchen das zonenfile fuer die domain maxmeier.at vom ns1.meierprovider.at abzuholen und in die datei bla.txt zu schreiben. zonetransfers werden allerdings heutzutage meist auf die IP addressen der secundary server eingeschraenkt. alle anderen duerfen nur einzelne anfragen stellen nicht aber gleich das ganze zonefile auf einmal abholen. wie sehen nun diese zonefiles aus? $TTL 86400 $ORIGIN at. maxmeier IN SOA ns1.maxmeier.at. moriz.maxmeier.at. ( 200203161 28800 7200 604800 86400 ) IN NS ns13.irgendwo.at. IN NS ns1.maxmeier.at. IN MX 10 mail.maxmeier.at. IN MX 100 mail.meierprovider.at. IN A 123.45.56.89 $ORIGIN maxmeier.at. schrottkiste IN A 123.45.56.89 blechkistekiste IN A 88.88.77.66 mail IN A 88.88.77.67 ns1 IN A 99.88.77.66 www IN CNAME schrottkiste.maxmeier.at. hinterhof IN MX 10 mail.maxmeier.at. die wichtigsten eintraege aus diesem zonefile: $TTL gibt die default TTL an. das ist die zeit in sekunden die die clients die namensabfragen zwischenspeichern duerfen bevor sie nachfragen muessen ob sich das ganze nicht unter umstaenden geaendert hat. $ORIGIN gibt eine domain an die hinter alle namen angehaengt wird die NICHT mit einem punkt enden. das maxmeier in der 3ten zeile heisst also in wirklichkeit maxmier.at. es ist ein beliebter fehler punkte am ende zu vergessen wo eigentlich welche seinsollten. SOA bedeutet "start of authority" die angaben dahinter besagen: der hostname auf dem das master file liegt. die email addresse des betreuers der zone. da an dieser stelle kein @ erlaubt ist wird dies durch einen punkt ersetzt. der betreuer waere also moriz@maxmeier.at die nachfolgenden zahlen sind: * seriennummer (die muss immer erhoeht werden wenn man etwas aendert damit die secundary server wissen dass das file neu ist. per konvention schreibt man in dieser 32bit zahl das aktuelle datum) * refresh: nach wievielen sekunden sollen die secundaries fruehestens nachfragen ob das zonefile geaendert wurde? hier: 8 stunden. * retry: nachdem die refresh zeit abgelaufen ist in welchen intervallen soll ein secundary versuchen das zonefile neu zu laden? hier: alle 2h. * expire: wenn obiger retry immer wieder fehlschlaegt ab wann soll der secundary das file als ungueltig erklaeren? hier: 7 tage. die "IN NS" zeilen geben an wer die nameserver fuer die domain sind. (es kann natuerlich noch andere nameserver geben die hier nicht aufgelistet sind. das waeren dann "hidden primary" oder "hidden secundary" server. hier sollten nur die offiziellen nameserver fuer die domain eingetragen werden. die MX records besagen wohin mail fuer die domain gehen soll. wie wir schon wissen: der mit der kleinsten nummer hat die hoechste prioritaet. die A records geben die IP addresse eines namens an. der A record ohne namen steht hier fuer maxmeier.at selbst ohne irgend einen namen davor. der CNAME eintrag ist ein alias namen. hier kann man von einem namen auf einen anderen verweisen. wenn sich die IP addresse von schrottkiste aendert ist damit auch die IP addresse von www.maxmeier.at geaendert. letztendlich legen wir noch fest dass mail die an xxx@hinterhof.maxmeier.at geschickt wird auch auf mail.maxmeier.at landen soll. wir koennten hier auch noch mit NS eintraegen nameserver fuer eine unter domain eintragen. nach einem restart des nameservers und einem blick in das logfile ob dort fehlermeldungen auftauchen ist unser nameserver betriebsbereit. reverse files gehen aehnlich wie normale zonefiles. am besten schaut man sich die beispielfiles fuer die lokale 127.0.0.1 zone an. EXERCISES: * installiere dir einen nameserver. konfiguriere ihn entweder stand-alone oder als forwarder zu deinem provider. teste ihn mit nslookup abfragen und in dem du ihn in dein resolv.conf eintraegst. * richte dir eine eigen domain ein. z.b. als unterdomain einer domain die dir schon gehoert oder die einem bekannten von dir gehoert der dir eine subdomain kostenlos deligieren kann. * versuche einen named-xfer auf verschiedene domains und nameserver. * installiere einen secundary nameserver fuer deine neue domain auf einem anderen rechner oder versuche secundary nameserver fuer eine domain von jemandem anderen zu sein. * teste deine konfiguartion mit nslookup auf verschiedenste server. REFERENCES: man named DNS-HOWTO.txt.gz