Oplossing: DNS. Domain Name System. Internet Name Space. Naam-adresvertalingen. Ontstaan : midden jaren tachtig Twee belangrijke karakteristieken:

Transcriptie

1 Karakteristieken Werking Domain Name System Configuratie: BIND voor UNIX bekendste implementatie van DNS (zowel resolver als ) Berkeley Internet Name Daemon coördinatie door Internet Software Consortium ( Beheer : nslookup, dig Ontstaan : midden jaren tachtig Twee belangrijke karakteristieken: Oplossing: DNS + hiërarchische naamgeving (ipv. een platte) een domeinnaam bestaat uit meerdere componenten, gescheiden door punten van rechts naar links wordt steeds verder ingezoomd: be staat voor België, wenk voor de hogeschool, denayer voor de campus, en www is de naam van een specifieke computer al deze componenten worden domeinen genoemd: be het Belgische domein, wenk.be het domein van de hogeschool,... het meest rechter domein wordt het top-level domein genoemd + gedistribueerde opslag (ipv. centrale opslag) er bestaan DNS-databases met de namen en de IP-adressen van alle machines in een bepaald domein deze databases zijn verspreid over de verschillende domeinen van het Internet Gevolg: DNS is schaalbaar of tegen groei bestand Elk stukje van de DNS-database wordt beheerd door een Naam-adresvertalingen IP-niveau: er wordt met IP-adressen van computers gewerkt routering van IP-pakketten vindt plaats op basis van het numerieke IP-adres eindgebruikers: verkiezen symbolische namen, bijv. Mechanisme nodig voor de koppeling van namen aan adressen: Tot midden jaren 80: centrale boekhouding met daarin de namen en corresponderende IP-adressen van alle systemen van het Internet bestand: HOSTS.TXT bij het Network Information Center (NIC) bij het Standford Research Institute (SRI) Alle systemen maakten periodiek een kopie van het HOSTS.TXT bestand Door de groei van Internet: toenemende belasting van SRI-NIC steeds groter wordend consistentieprobleem: HOSTS.TXT na een uur al verouderd platte, eendimensionale naamsruimte: steeds moeilijker om nieuwe namen te verzinnen. Internet Name Space de verzameling van alle symbolische namen op het Internet hiërarchisch opgedeeld in domeinen: bovenaan in de hiërachie de root (. ) en daaronder de domeinen van het hoogste niveau Elk van deze domeinen bevat een aantal hiërarchisch geordende subdomeinen. Zo n subdomein kan op zijn beurt weer verder onderverdeeld worden, en zo verder. uk nl ac kuleuven esat. be wenk denayer ekring Fully Qualified Domain Name (FQDN): vrt edu com mtv ekring.denayer.wenk.be. org ieee

2 Top-level domeinen Oorspronkelijk waren de domeinen van het hoogste niveau gekoppeld aan de aard van de instellingen in de USA: com ondernemingen met commerciële doeleinden edu bepaalde educationele instellingen gov gouvernementele organisaties van de USA mil militaire instellingen org non-profit instellingen int internationale organisaties net netwerkorganisaties hp.com standford.edu whitehouse.gov navy.mil greenpeace.org nato.int ripe.net Naarmate Internet meer buiten de USA verspreid geraakte, heeft men hoofddomeinen per land ingevoerd, bijvoorbeeld be voor België. Per land-domein is dan onder andere een subdomein ac voorzien dat de academische instellingen groepeert. Subdomeinen en delegatie Na het verkrijgen van een domeinnaam is de organisatie zelf naming authority geworden over dat domein: + kan zelf subdomeinen maken + en de verantwoordelijkheid voor subdomeinen delegeren door naming authorities voor die subdomeinen toe te wijzen Het domein dat de delegatie uitvoert wordt parent domein of parent genoemd. Een zone is een gedeelte van de naamsboom dat door één instantie beheerd wordt: is dus een domein inclusief alle subdomeinen maar zonder dat wat weggedelegeerd is Voorbeeld : wenk.be met subdomeinen lemmens en denayer Naming authorities Op elk niveau van de boom is er een naming authority die als enige bevoegd is om namen uit te delen op het niveau daaronder. De naming authority op het hoogste niveau (ICANN) als enige bevoegd om nieuwe top-level domeinen uit te delen De naming authority voor het domein.be mag namen uitdelen onder.be. Met elke naming authority correspondeert ook een name server: een database met de door de naming authority uitgedeelde namen. Bij het uitdelen van namen worden politieke regels gevolgd: sommige: erg vrij, alleen wat syntactische voorwaarden andere: strenger, bijv. beoordelen of de gevraagde naam (ook al is deze nog vrij) geen belangen van andere partijen schaadt Reverse DNS Omgekeerde adresvertaling: van een IP-adres naar een bijbehorende symbolische naam Nodig voor: uitvoer van netwerkcommando s (bijv. traceroute, netstat, tcpdump, arp) voor de gebruiker soms duidelijker wanneer een hostnaam gegeven wordt in plaats van een IP-adres logbestanden van web- en andere servers hostnamen van bezoekende systemen zijn meer zeggend dan IP-adressen server die toegang tot bepaalde gegevens afschermt op basis van de domeinnaam van de klant: een webserver die bepaalde gegevens alleen wil tonen aan bezoekers vanuit het domein denayer.wenk.be, heeft reverse DNS nodig om te bepalen wat het domein is van de bezoeker. Probleem: een vraag aan DNS is steeds van de vorm Wat is de waarde die hoort bij de FQDN XYZ? met XYZ een domeinnaam Hoe ziet die vraag eruit bij een achterwaartse vertaling?

3 Onder de root is een speciaal domein in-addr.arpa. gedefinieerd. Onder dit domein zijn er 256 subdomeinen: 0.in-addr.arpa., 1.in-addr.arpa.,..., 255.in-addr.arpa. Onder elk van deze domeinen zijn er opnieuw 256 subdomeinen: 0.0.in-addr.arpa., 1.0.in-addr.arpa.,..., in-addr.arpa. Dit wordt nog tweemaal herhaald zodat er namen ontstaan van de vorm: in-addr.arpa. Speciaal domein nl be wenk denayer lemmens. arpa com in-addr Om nu de symbolische naam te vinden die hoort bij het IP-adres , kan de vraag aan DNS gesteld worden: Wat is de waarde die hoort bij de FQDN in-addr.arpa.? DNS bestaat uit twee componenten: Name-server versus resolver de resolver is een onderdeel van de toepassing die een bepaald naam-adresvertaling wil uitvoeren: het is een bibliotheekroutine (bijv. gethostbyname en gethostbyaddr) die door de toepassing wordt opgeroepen om de vertaling in gang te zetten; deze resolver is normaal niet zichtbaar; het is een onderdeel van ftp, telnet, webbrowser en alle andere toepassingen die een naam-adresvertaling moeten uitvoeren de is een proces dat verantwoordelijk is voor het uitvoeren van naam-adresvertalingen. Voor elk domein is er een die beschikt over de DNS-database van dat domein, waarin onder meer de namen en IP-adressen van alle systemen in dat domein zitten. De is wel zichtbaar: het is een proces dat draait op een bepaald systeem. Takenpakket van DNS vertaling van een symbolische hostnaam naar het corresponderende IP-adres vertaling van een IP-adres naar de corresponderende symbolische hostnaam Een organisatie aangesloten op het internet is dus verantwoordelijk voor twee domeinen: 1. het domein wenk.be. 2. het domein in-addr.arpa. Bijkomende taken: + routering van voor elk domein bepalen wat de mailserver is voor dat domein + recent: mechanisme om te bepalen op welk systeem bepaalde services draaien, bijv. web-server, directory-server,... Werking Een particulier gebruiker in het domein belgacom.be wil de website bezoeken: 1. resolver vraagt aan naburige wat het IP-adres is dat hoort bij 2. de heeft geen idee, omdat het een naam is buiten zijn domein; maar hij doet zijn best door de root te contacteren X 1 8 resolver browser root.be wenk.be 3. de root heeft kennis van de s van alle top-level domeinen: hij kan dus het IP-adres van de van het domein.be geven aan de X.

4 4. de X vraagt nu aan één van de.be s om het IPadres van X 1 8 resolver browser root.be wenk.be 5. de.be weet voor alle subdomeinen onder.be wat de s voor die subdomeinen zijn, maar hij heeft geen informatie over de inhoud van die subdomeinen; de.be kan dus het IP-adres van de wenk.be doorgeven aan de X. 6. Tot slot kan de X het IP-adres van vragen aan de wenk.be. 7. En dit IP-adres wordt aan de resolver doorgegeven. Opgedane kennis wordt door s bewaard en herbruikt. De X heeft geleerd wat de s zijn van.be en van wenk.be en wat het IPadres is van Bij een volgende vraag ivm met kan deze direct beantwoord worden en is het aantal stappen beperkt tot twee. Caching en negative caching X 1 8 resolver browser root.be wenk.be Daarnaast zal bij een vraag naar X beginnen bij stap 4. De gegevens in de cache blijven natuurlijk niet eeuwig geldig. De eigenaar van een domein kan aangeven hoelang anderen DNS-informatie mbt dat domein in hun cache mogen bewaren. In DNS zijn er twee soorten vragen: Recursieve en iteratieve vragen 1. bij een recursieve vraag verwachten we van de andere partij dat deze pas bij ons terugkomt wanneer hij het uiteindelijke antwoord heeft gevonden; een resolver stelt normaal altijd recursieve vragen (stap 1) 2. bij een iteratieve vraag zijn we tevreden wanneer de andere partij ons een stapje dichterbij het antwoord heeft geholpen; s stellen onderling normaal altijd iteratieve vragen (stappen 2, 4, 6). Communicatie tussen resolver en en s onderling verloopt via poortnummer 53; voornamelijk via UDP maar deels ook via TCP (zonetransfers). negative caching: moderne DNS-implementaties onthouden ook negatieve antwoorden. Wanneer het IP-adres gevraagd wordt van bijv. zal de vaststellen dat deze naam niet bestaat. Bij een volgende dezelfde vraag zal de onmiddellijk antwoorden, dat de naam niet bestaat ipv. opnieuw te gaan zoeken. Wanneer een resolver een IP-adres van een FQDN vraagt, kunnen er twee soorten antwoorden komen: authoritative antwoord: het antwoord komt van de die authoritative is voor de zone waar de host met de gegeven FQDN element van is zo n authoritative beschikt in zijn database over alle informatie van alle hosts die in de zone zitten non-authoritative antwoord: het antwoord komt van een die de gevraagde naam-adresvertaling kan doen op basis van de informatie in zijn cache.

5 De lijm tussen s Elke heeft kennis over alle s van de subdomeinen die hij gedelegeerd heeft. De van.be kent de s van alle domeinen onder.be en hij beschikt ook over de IP-adressen van de s van deze subdomeinen. Dit is nodig want in stap 5 geeft de van.be aan X door wat de s van wenk.be zijn. Maar met de symbolische naam van zo n is X niets. Om in stap 6 een vraag te stellen, moet een IP-pakket naar die gestuurd worden en daarvoor is het IP-adres nodig. In stap 5: niet alleen de namen maar ook de IP-adressen van de s doorgeven. Eigenaardig want de van.be heeft geen autoriteit over het domein wenk.be en kan dus eigenlijk geen IP-adres weten van een in dat domein. Dus de van.be heeft een kopie van de naam-adresgegevens van de s van wenk.be. Glue of lijm: de naam-adresinformatie van de van wenk.be zit zowel in het parent-domein (.be) als in het eigen domein wenk.be. Primary en secondary s zijn tegelijk actief: of een bepaalde naam-adresvertaling door de primary of door een secondary uitgevoerd wordt, is in principe niet te voorspellen. In stap 3 worden alle s van.be opgevraagd en in stap 5 alle s van wenk.be. Name server X zal er hiervan één kiezen door proberen vast te stellen welke netwerktopologisch gezien het dichtste is ( kleinste round-trip time). Het is aan te raden om meerdere secondary s te voorzien. Bij voorkeur zou er minstens één secondary buiten de eigen organisatie moeten opgezet worden, zodat de name-service ook bij een uitval (van een deel) van het bedrijfsnetwerk kan blijven werken. In de praktijk wordt dikwijls een secondary opgezet bij de ISP (bijv. Belnet). primary zone-data (gemaakt en aangepast door de beheerder) Primary en secondary update nodig? zone-transfer secondary kopie van zone-data Elk domein moet over precies één primary beschikken: is autoriteit voor dat domein en beschikt over de DNS-database voor dat domein. Alle aanvullingen, veranderingen en andere wijzigingen vinden plaats op de primary nameserver. Omwille van redundantie en spreiding van belasting: minstens één secondary : heeft ook autoriteit over dat domein, maar geen recht om wijzigingen door te voeren. Een secondary beschikt over een kopie van de zone-data. De secondary controleert regelmatig of zijn zonedata nog up-to-date is. Indien dit niet het geval is, wordt een zone-transfer uitgevoerd: het opnieuw overhalen van de zone-informatie vanaf de primary. DNS: nieuwere ontwikkelingen Handmatige tussenkomst nodig bij elke verandering in de zonedata. In veel gevallen ongewenst, bijv. een DHCP-server die IP-adressen uitdeelt aan een PC die een vaste hostnaam moet hebben. DNS dynamic update: DHCP-server stuurt een boodschap naar de primary om de aanpassing in de boekhouding door te geven. Probleem: beveiliging: hoe kan vermeden worden dat een aanvaller valse informatie in de DNS-database gaat stoppen (opl. DNSSEC, secure dns). Secondary moet zelf het initiatief nemen tot een zone-transfer. Na een verandering door de primary in de zonedata, is de secondary een tijdje niet up-to-date. Prompt notification of zone changes: een methode waarbij de primary de secondary s direct op de hoogte brengt van veranderingen. De secondary kan dan direct een zone-transfer doen. Bij een zone-transfer wordt de volledige zonedata doorgestuurd. Incremental zone transfer in DNS: een methode waarbij alleen de veranderingen ten opzichte van de vorige versie gecopieerd worden: is efficiënter.

6 Caching-only-: server die geen autoriteit heeft voor een domein, dient alleen maar als aanspreekpunt voor het uitvoeren van naam-adresvertalingen. Bijvoorbeeld: X wanneer die geen autoriteit heeft voor een domein. Nut: na verloop van tijd heeft zo n server een grote cache met informatie opgebouwd (net zoals elke gewone ). Slave-server: in grote organisaties die het bedrijfsnetwerk via een firewall aan het Internet gekoppeld hebben, met afdelingsnetwerken met eigen s (bijv. A). denayer vlekho 1 6 A B 2 5 N naar root-server 3 firewall 4 Systeem in afdelingsnetwerk denayer wil in het Internet benaderen. Indien niets in cache gevonden wordt, moet de root-server gecontacteerd worden. Omwille van de beveiliging kan er echter geen uitgaand verkeer vertrekken vanuit een intern netwerk. Name-server A wordt als slave-server ingericht en speelt alle verzoeken door aan een forwarding server op de firewall (N). Deze forwarding server kan zijn cache raadplegen en indien nodig, de root-server contacteren. SOA NS A MX SRV CNAME HINFO PTR TXT AAAA Resource records administratieve gegevens met betrekking tot een domein parameters voor communicatie tussen primary en secondary s (Start of Authority ) van het domein IP-adres van het systeem mail-server voor het domein lokatie van een specifieke service bijnaam voor het systeem hostinformatie adres-naamrelatie commentaar IPv6-adres Structuur DNS database: resource records domeinnaam [TTL] klasse type data domeinnaam of hostname in de eerste kolom; time-to-live : hoe lang andere s dit record in hun cache mogen bewaren; optioneel: default waarde is terug te vinden in het SOA record; klasse: bijna steeds IN van internet, tenzij DNS voor andere zaken gebruikt wordt (zeer zeldzaam); type van het resource record: SOA, A, PTR,... data van het resource record: eventueel verschillende parameters. Indien de waarde over meerdere regels wordt geschreven, moeten haakjes gebruikt worden. Commentaar: alles wat op een regel na een ; staat. SOA-record enkele administratieve gegevens met betrekking tot de zone een aantal parameters voor de communicatie tussen de primary en de secondary s denayer.wenk.be. IN SOA hardy.denayer.wenk.be. jo.hardy.denayer.wenk.be. ( 9876 ; Serial ; Refresh every 3 hours 3600 ; Retry every hour ; Expire after a week ) ; Minimum ttl of 1 day de naam van de primary van de zone -adres van degene die verantwoordelijk is voor de zone (in plaats wordt een. geschreven)

7 A-record en PTR-record serienumer: versie van de zonedata (voor communicatie tussen P en S): de secondary klopt van tijd tot tijd bij de primary aan om te vragen of zijn zone-informatie nog up-to-date is; voor deze controle worden de serienummers met elkaar vergeleken; na elke verandering in de zonedata moet dus het serienummer verhoogd worden. refresh: met welke frequentie de secondary de actualiteit van zijn zonedata bij de primary controleert retry: bij een poging tot refresh, maar secondary kan geen contact met primary krijgen; de tijdspanne om een volgende poging te doen om de primary te bereiken expire: na deze tijd mag de secondary zijn zonedata niet langer aanbieden omdat herhaalde pogingen om de primary te bereiken mislukt zijn time-to-live: standaardwaarde (en ook minimumwaarde) voor de TTL in de resource-records van de zone eenvoudig resource record: specificeert de relatie tussen een hostnaam en een IP-adres hardy.denayer.wenk.be. IN A glue-records: de A-records van hardy en zeppo moeten bij de van wenk.be bekend zijn alleen nodig voor s van een domein die in dat domein zelf zitten: het A-record van de derde ns.flippo.be hoeft niet als glue-record opgenomen te worden PTR-record of PoinTeR record definieert de omgekeerde naam-adresvertaling: van IP-adres naar domein in-addr.arpa. IN PTR hardy.denayer.wenk.be. PTR-records en A-records zitten in verschillende zones en dus in verschillende DNS-databases. NS-record aangeven wat de s van een zone zijn elke zone minstens twee: een primary en minstens één secondary NS-records van een zone moeten bekend zijn bij de s van de zone erboven: van daar moet kunnen doorverwezen worden naar deze s De van het Belgische domein.be moet bijvoorbeeld weten wat de NS-records van wenk.be zijn. Belangrijk is de punt achteraan de hostnaam in de resource-record: namen die niet op een punt eindigen: relatief ten opzichte van het huidige domein. denayer.wenk.be. IN NS hardy.denayer.wenk.be. IN NS zeppo.denayer.wenk.be. IN NS ns.flippo.be. Round-robin DNS Om de belasting van drukbezochte (web-)servers terug te dringen Er worden een aantal identieke systemen geconfigureerd die allemaal dezelfde service aanbieden DNS wordt gebruikt om ervoor te zorgen dat de binnenkomende service-verzoeken gelijk verdeeld worden over de diverse servers Hiervoor worden bij een bepaalde naam een hele serie A-records gemaakt: IN A IN A IN A IN A IN A Wanneer om het IP-adres van gevraagd wordt, geeft de alle IP-adressen terug, maar in een roulerende volgorde. Aangezien de resolver het adres vooraan in de lijst neemt, zal elk systeem gemiddeld in één van de vijf gevallen gebruikt worden.

8 CNAME-record specificatie van een bijnaam voor een bepaald systeem: <bijnaam> IN CNAME <echte_naam> het record geeft de canonical name (of echte naam) die hoort bij een bijnaam gebruikt om systemen met een bepaalde specifieke functie (bijv. web-server) van een standaard naam te voorzien, zodat de buitenwereld deze gemakkelijk kan raden dit kan ook door middel van een A-record: IN A Stel dat dit systeem ook mail-server en is met daarbij horend een functie-specifieke hostnaam: mail.denayer.wenk.be. IN A ns.denayer.wenk.be. IN A TXT, HINFO en RP-records niet-verplichte resource-records met algemene informatie over een zone en over systemen binnen de zone HINFO : hostinfo: waarde bestaat uit twee parameters: type hardware en type besturingssysteem TXT : willekeurige tekstuele informatie RP : responsible person : om aan te geven wie verantwoordelijk is voor een bepaald domein, via een adres (met een. in plaats van en bijkomend informatie door middel van een verwijzing naar een TXT-record srva00.labcn.wenk.be. IN HINFO "pentium IV" "Redhat 8.0" info.labcn.wenk.be. IN TXT "student Jos Van Daele" labcn.wenk.be. IN RP VanDaele.labcn.wenk.be info.labcn.wenk.be Meerdere A-records met hetzelfde adres: niet goed voor de onderhoudbaarheid Met behulp van CNAME-records : flexibel en onderhoudbaar srva00.labcn.wenk.be. IN A IN CNAME srva00.labcn.wenk.be. mail.labcn.wenk.be. IN CNAME srva00.labcn.wenk.be. ns.labcn.wenk.be. IN CNAME srva00.labcn.wenk.be. Alternatief om round-robin DNS op te zetten: IN CNAME www1.denayer.wenk.be. ;... IN CNAME www5.denayer.wenk.be. www1.denayer.wenk.be. IN A ;... www5.denayer.wenk.be. IN A MX-record Mail exchange record: naar welk systeem elektronische post voor een bepaald domein moet verstuurd worden denayer.wenk.be. IN MX 10 hardy.denayer.wenk.be. denayer.wenk.be. IN MX 50 buster.denayer.wenk.be. Het eerste argument van de data is een getal dat de prioriteit aangeeft. Hoe lager dit getal, hoe hoger de prioriteit van de bijhorende mail-server Aanbeveling: minstens twee MX-records voorzien: de tweede is een backup-mailserver wanneer de eerste onbereikbaar mocht zijn De mailconfiguratie van deze MX-hosts moet natuurlijk wel zo zijn dat de post voor het domein daar ook daadwerkelijk wordt verwacht en afgehandeld De records zijn van toepassing wanneer iemand stuurt naar joske@denayer.wenk.be maar niet wanneer een gestuurd wordt naar joske@gummo.denayer.wenk.be

9 In dat geval de MX-record van gummo.denayer.wenk.be. wordt gezocht; als deze gevonden wordt, wordt de post afgeleverd op de bijhorende MX-host indien er geen MX-record bestaat, wordt het A-record van deze host opgezocht en wordt geprobeerd om de post rechtstreeks op dat adres af te leveren. Hiervoor is nodig dat er een mailserver op dat systeem actief is en dat het systeem rechtstreeks vanuit de buitenwereld bereikbaar is. Deze bereikbaarheid is meestal omwille van de firewall niet het geval: alle binnenkomende post mag slechts op één centraal mailserver systeem afgeleverd worden: dit komt zowel de veiligheid als de onderhoudbaarheid van de mailconfiguratie ten goede Over het algemeen is het verstandig om voor elk individueel systeem MX-records te maken: zeppo.denayer.wenk.be. IN MX 10 hardy.denayer.wenk.be. gummo.denayer.wenk.be. IN MX 10 hardy.denayer.wenk.be. buster.denayer.wenk.be. IN MX 10 hardy.denayer.wenk.be. Wildcard-record Mogelijkheid om een aantal domeinnamen van een gezamelijke waarde te voorzien. Vooral gebruikt voor MX-toepassingen: *.denayer.wenk.be. IN MX 10 hardy.denayer.wenk.be. Het * staat voor alles en bovenstaande resource-record is een afkorting voor een hele serie resource records. Er is echter een probleem: het wildcard-record is alleen van toepassing voor namen waarvoor geen enkele andere zonedata beschikbaar is. Het is bijvoorbeeld niet geldig voor ns.denayer.wenk.be. omdat er ook een A-record voor die naam bestaat. SRV-record Uitbreiding van het MX-record idee: aangeven waar specifieke services in een bepaald domein zitten bijvoorbeeld de webserver, de LDAP directory server,.. Een mogelijkheid is om met behulp van CNAME-records een bijnaam te geven die de specifieke functie vastlegt. Nadeel : niet erg flexibel; men kan er geen prioriteiten of load sharing mee realiseren. Algemene structuur van SRV-record (nog niet algemeen gebruikt door clients): domein IN SRV <prioriteit> <gewicht> <poort> <host> Voorbeeld: het domein denayer.wenk.be. heeft drie web-servers : http.tcp. IN SRV hardy.denayer.wenk.be. http.tcp. IN SRV zeppo.denayer.wenk.be. http.tcp. IN SRV gummo.denayer.wenk.be. De servers hardy en zeppo hebben de hoogste prioriteit en gummo zal alleen maar gebruikt worden als backup voor de andere twee. De kolom met het gewicht geeft aan dat hardy tweederde van de belasting moet krijgen en zeppo slechts eenderde. groepering van resource-records elke zone heeft zijn eigen zonebestand Zone-bestand verschillend voor de voorwaartse en de reverse zones het formaat is gestandaardiseerd (RFC 1035) en dus voor elke implementatie in de eerste kolom staat voor het huidige domein wat kan worden vastgelegd met de macro $ORIGIN resource-records zonder eerste kolom: er wordt dan hetzelfde domein als de vorige keer (vorige record) gebruikt namen die niet op een punt eindigen: relatief ten opzichte van het huidige domein Bovenaan kunnen macro s gedefinieerd woren: $TTL 5 $ORIGIN denayer.wenk.be

10 Resolver en configuratie bestaat uit een aantal bibliotheekfuncties, o.a. gethostbyname en gethostbyaddr deze routines worden aangeroepen door toepassingen om naam-adresvertalingen of andere DNS-lookups in gang te zetten configuratie: instellen aan welke de vragen gericht moeten worden domain denayer.wenk.be nameserver nameserver In plaats van domain kan ook search met meerdere domeinen gegeven worden (het eerste is dan het default domein). De resolver moet een volledige domeinnaam (FQDN) aan de aanbieden. De door de gebruiker aangeboden naam moet vaak aangevuld worden tot een FQDN: Resolver in unix: /etc/resolv.conf Het domain directief geeft het default domein aan. Wanneer dit ontbreekt, dan zal de resolver het default domein trachten te halen uit de hostname. Wanneer deze bijvoorbeeld gelijk is aan zeppo.denayer.wenk.be, besluit de resolver dat het default domein gelijk is aan denayer.wenk.be. Het is veiliger om meerdere nameservers op te geven, voor een betere bereikbaarheid. Bij één probeert de resolver deze maximaal 4 keer te bereiken, met time-outs van 5, 10, 20 en 40 seconden (totaal 75 seconden). Bij twee s probeert de resolver deze om de beurt elk maximaal 4 keer te bereiken, met time-outs van 5, 5, 10 en 10 seconden (totaal ongeveer 75 seconden). Bij drie s gebeurt iets gelijkaardigs, ook met een totale time-out van rond de 75 seconden. Met het directief search wordt het zoekpad opgegeven. Het eerste domein in dit zoekpad geldt tevens als default domein, zodat het directief domain in dit geval niet moet gebruikt worden. 1. het is de gewoonte om binnen een netwerk het domeingedeelte van hostnamen weg te laten: bijvoorbeeld hardy in plaats van hardy.denayer.wenk.be. De resolver vult de naam aan met het default domein, namelijk de eigen domeinnaam. 2. wanneer de gebruiker ook het domeingedeelte specificeert maar geen afsluitend punt, dan gebruikt de resolver volgende regels: een naam die uit minstens twee componenten bestaat, wordt aangevuld met een punt; als dat geen resultaat oplevert, dan wordt de naam aangevuld met het default domein. Sommige resolvers bieden de mogelijkheid om een zoekpad te definiëren. denayer.wenk.be denayer.be denayer.kuleuven.be Bij de naam hardy worden volgende volledige namen geprobeerd: Versies: Configuratie: BIND voor UNIX bootbestand: taken van de cache-bestand: informatie over de root-servers zone-bestanden met de resource-records van de zones waarvoor de verantwoordelijkheid draagt: minstens één voorwaartse zone (bijvoorbeeld voor denayer.wenk.be.) en één achterwaartse zone (30.10.in-addr.arpa.) BIND 4: niet aanbevolen BIND 8 : nieuwe faciliteiten (dynamic updates en notificatie door de primary van veranderingen in de zone) en security-verbeteringen (DNSSEC) BIND 9 : nieuwe features vanuit security oogpunt (view, rndc). hardy.denayer.wenk.be hardy.denayer.be hardy.denayer.kuleuven.be

11 controls { options { directory "/etc/named.data"; dump-file "named_dump.db"; pid-file "/var/run/named.pid"; statistics-file "named.stats"; //boolean options auth-nxdomain yes; notify yes; recursion yes; //forwarding forward first; forwarders { ; Het bootbestand //access control allow-query { any; //query address query-source address * port *; //zone transfers max-transfer-time-in 120; //transfer-format one-answer; transfer-format many-answers; transfers-in 10; transfers-out 5; //not implemented transfers-per-ns 2; zone "denayer.wenk.be" { type master; file "db.denayer"; allow-update { none; zone "30.10.in-addr.arpa" { type master; file "db.10.30"; allow-update { none; zone " in-addr.arpa" { type master; file "db "; allow-update { none; zone "." { type hint; file "db.cache"; zone "vlekho.wenk.be" { type slave; file "dbak.vlekho"; masters { ; zone "255.in-addr.arpa" { type master; file "db.broadcast"; zone "0.in-addr.arpa" { type master; file "db.self"; in het bootbestand wordt verwezen naar andere bestanden; het directief directory geeft aan in welke directory deze andere bestanden te vinden zijn commentaar: regels beginnend met // of # type master: de is primary voor deze zone. Deze heeft de eindverantwoordelijkheid over een bepaalde zone en beschikt over het origineel van de zonedata. zone in-addr.arpa: om het speciale loopback-adres terug te kunnen vertalen naar een hostnaam de zone met type hint verwijst naar het cache-bestand met daarin gegevens over de root-servers type slave: de is secondary voor deze zone. Hij beschikt dan niet over het origineel van de zonedata. daarvoor moet een zonetransfer vanaf een master-server gedaan worden; het IP-adres is te vinden in het directief masters. Het directief file bevat de naam van een bestand waarin de secondary een backup van de zonedata kan bewaren; is nuttig wanneer bij het opstarten van de secondary de bijhorende primary niet gecontacteerd kan worden. Het cache-bestand een lijst van hints met behulp van welke de meest actuele lijst van root-servers opgevraagd zal worden: BIND vraagt aan één van de in de cache-bestand genoemde hosts om een actuele lijst van root-servers; dit lukt alleen als de betreffende host zelf een root-server is IN NS a.root-servers.net IN NS b.root-servers.net IN NS m.root-servers.net. a.root-servers.net IN A b.root-servers.net IN A m.root-servers.net IN A IN NS NS.NIC.DDN.MIL IN NS KAVA.NISC.SRI.COM. NS.NIC.DDN.MIL IN A KAVA.NISC.SRI.COM IN A

12 Het zone-bestand: voorwaarts denayer.wenk.be. IN SOA hardy.denayer.wenk.be. jo.hardy.denayer.wenk.be. ( 9876 ; Serial ; Refresh every 3 hours 3600 ; Retry every hour ; Expire after a week ) ; Minimum ttl of 1 day ; Name Servers denayer.wenk.be. IN NS hardy.denayer.wenk.be. IN NS zeppo.denayer.wenk.be. ; Addresses for canonical names localhost.denayer.wenk.be. IN A cisco.denayer.wenk.be. IN A hardy.denayer.wenk.be. IN A IN HINFO HP9000/RP HPUX denayer.wenk.be. IN MX 10 hardy.denayer.wenk.be. zeppo IN A IN HINFO HP9000/B180 UNIX Het zone-bestand: IN SOA hardy.denayer.wenk.be. jo.hardy.denayer.wenk.be. ( 9876 ; Serial ; Refresh every 3 hours 3600 ; Retry every hour ; Expire after a week ) ; Minimum ttl of 1 day ; Name Servers in-addr.arpa. IN NS hardy.denayer.wenk.be. ; Addresses to canonical name in-addr.arpa. IN PTR hardy.denayer.wenk.be IN PTR webmail.denayer.wenk.be IN PTR a3a4.denayer.wenk.be IN PTR bak512.denayer.wenk.be IN PTR window.denayer.wenk.be IN PTR schaap.denayer.wenk.be IN PTR polly.denayer.wenk.be. IN A website IN A IN HINFO P4 Linux support IN CNAME website emsys IN CNAME website IN CNAME website webmail IN A IN HINFO P4 Linux webmail IN MX 10 webmail student IN MX 10 webmail telescript IN A IN HINFO PC linux uurrooster IN CNAME telescript a3a4 IN A IN TXT "printer in lokaal A217" labcn IN NS srva00.labcn srva00.labcn IN NS Overige zonebestanden Het zonebestand db dient om het adres te kunnen vertalen naar een IN SOA ns.wenk.be huismeester.wenk.be. ( ) 1 IN PTR localhost.denayer.wenk.be. Zone 0.in-addr.arpa en zone 255.in-addr.arpa: om te voorkomen dat root-servers benaderd worden voor omgekeerde naam-adresvertalingen voor het speciale IP-adres en het broadcast-adres Ze bevatten alleen een SOA-record: omdat er geen namen corresponderen met deze speciale adressen, is er geen data in de zone nodig.

13 Starten en herconfigureren De heet doorgaans named en kan gestart worden: # named -b <naam_van_het_bootbestand> Wanneer de optie niet meegegeven wordt, wordt /etc/named.conf als bootbestand gebruikt. Na veranderingen in het bootbestand of in één van de zonebestanden moet de herstart worden door het sturen van het hangup signaal. Eventuele syntaxfouten worden door de naar de syslogd server doorgegeven die ze dan wegschrijft in een logbestand. Het is belangrijk om deze syntaxfouten op te merken en daarop gepast te reageren; indien niet wordt een deel van de resource-records feitelijk niet aangeboden door de. options { forward first; forwarders { ; } acl beperkt {! ; 10.30/16; localhost; } Bijkomende elementen zone "denayer.wenk.be" { type master; file "db.denayer"; allow-query { beperkt; allow-update { beperkt; allow-transfer { beperkt; Name-servers die niet rechtstreeks met root-servers en andere s op het Internet mogen communiceren, maken gebruik van een extra tussenstap namelijk een forwarding. Het limiteren van gewone lookups, van dynamic updates en van zonetransfers wordt geregeld door directieven die naar een access control list verwijzen. Er is toegang toegestaan aan het lokale systeem en aan alle systemen met een IP-adres dat begint met 10.30, behalve Beheer : nslookup, dnswalk, dig nslookup voor elk domein alle informatie uit DNS opvragen, bijvoorbeeld A-, PTR-, NS- en MX records of zelfs een volledige listing van het domein: Betekenis van verschillende signalen signaal betekenis commando SIGHUP lees bootbestand en zonebestanden opnieuw ndc reload SIGINT dump database en cache (named.dumpdb) ndc dumpdb SIGILL dump statistieken (named.stats) ndc stats SIGUSR1 verhoog debugging level (named.run) ndc trace SIGUSR2 zet debugging uit ndc notrace nslookup buster.denayer.wenk.be nslookup -qtype=ns denayer.wenk.be nslookup -qtype=soa denayer.wenk.be nslookup -qtype=mx denayer.wenk.be nslookup -qtype=ptr in-addr.arpa. nslookup en dan interne commands zoals server of ls -d dnswalk: DNS-debugger om de interne consistentie van een zone te controleren. dnswalk is ook in staat om de corresponderende reverse zone in de controle te betrekken en om recursief in alle subdomeinen af te dalen en deze te controleren. Voorbeeld: dnswalk -r -F -a denayer.wenk.be. Gebruik: als controle voordat de delegatie van een subdomein geactiveerd wordt.

14 Alternatief: dig: command om informatie over DNS op te vragen dig domain [<query-type>] [<query-class>] [+<query-option>] [-<dig-option>] [%comment] domain query-type query-class server: either a domain name or a dot-notation Internet address domain: the domain name for which you are requesting information. (see -x option for convenient way to specify inverse address query) query-type: type of information (DNS query type) that you are requesting a T_A network address (default) any T_ANY all/any information about specified domain mx T_MX mail exchanger for the domain ns T_NS name servers soa T_SOA zone of authority record hinfo T_HINFO host information axfr T_AXFR zone transfer (must ask an authoritative server) txt T_TXT arbitrary number of strings query-class: the network class requested in the query. in C_IN Internet class domain (default) any C_ANY all/any class information -x dot-notation-address: convenient form to specify inverse address mapping (dig -x instead of dig in-addr.arpa ) Voorbeelden: dig wenk.be. ns dig ns.wenk.be. wenk.be. mx dig +norec dig hardy.denayer.wenk.be axfr (niet-recursieve query)