DNS laboration report Wilhelm Käll YYYY-MM-DD (the date the report was finished)



Relevanta dokument
DNS. Linuxadministration I 1DV417

Avancerad DNS - Laborationer

Tips: Titta på relevanta genomgångar på webbplatsen

Linuxadministration I 1DV417 - Laboration 5 Brandvägg och DNS. Marcus Wilhelmsson marcus.wilhelmsson@lnu.se 19 februari 2013

DNS-test. Patrik Fältström. Ulf Vedenbrant.

Tilläggs dokumentation 4069 Dns

IP-adresser, DNS och BIND

1. Beskriv hur DNS fungerar. Använd begrepp som root-servrar, topp-domäner mm. Och rita gärna.

Laboration 2 1DV416 Windowsadministraion I

Vad är DNS? DNS. Vad är DNS? (forts.) Vad är DNS utåt? Vad är DNS internt? Vad är DNS internt? (forts.)

Konfiguration av Authoritative-Only DNS-server baserad på BIND

DNS. Måns Nilsson

Föreläsning 9 Transportprotokoll UDP TCP

Grundläggande nätverksteknik. F2: Kapitel 2 och 3

Domain Name System DNS

Windowsadministration I

LABORATION 2 DNS. Laboranter: Operativsystem 1 HT12. Martin Andersson. Utskriftsdatum:

DNS och IPv6 vänner eller fiender?

Linuxadministration 2 1DV421 - Laborationer Webbservern Apache, Mailtjänster, Klustring, Katalogtjänster

Utförande: I exemplet så kommer vi att utgå från att man gör laborationen i en Virtuell miljö (Virtualbox).

Planering och RA/DHCPv6 i detalj

LABORATIONSRAPPORT. Operativsystem 1 LABORATION 2. Oskar Löwendahl, Jimmy Johansson och Jakob Åberg. Utskriftsdatum:

Internets historia i Sverige

Linuxadministration I 1DV417 - Laboration 4 Nätverk, DHCP, säkerhetskopiering, processhantering, Samba och NFS

Win95/98 Nätverks Kompendium. av DRIFTGRUPPEN

NSL Manager. Handbok för nätverksadministratörer

Varför och hur införa IPv6 och DNSSEC?

DNSSec. Garanterar ett säkert internet

Denna genomgång behandlar följande: IP (v4) Nätmasken ARP Adresstilldelning och DHCP

Laboration 4 Rekognosering och nätverksattacker

Föreläsning 6 Mål. Mänskor och IP adresser. Domain Name System (1/3) Numeriska adresser används i Internet

Övning 5 EITF25 & EITF Routing och Networking. October 29, 2016

DIG IN TO Nätverksteknologier

Övningar - Datorkommunikation

Ändringar i samband med aktivering av. Microsoft Windows Vista

ÅTVID.NET Startinstruktioner

IT för personligt arbete F2

Övning 5 ETS052 Datorkommuniktion Routing och Networking

3. Steg för steg. Kör IPv6 på riktigt med FortiGate! Principen är enkel:

Topologi. Utförande: I exemplet så kommer vi att utgå från att man gör laborationen i en Virtuell miljö (Virtualbox).

Unix-miljöer i större sammanhang

Varför ska vi införa IPv6 och hur gjorde PTS?

Small Business Server 2011 SSL certifikat administration

WWW. Exempel på klientsidan. Överföring av en html-fil. Snyggare variant. Verkligt format. Meddelandeformat för begäran HTTP

Förebyggande Råd från Sveriges IT-incidentcentrum

Hur man ändrar från statisk till automatisk tilldelning av IP i routern.

Konfiguration av LUPP synkronisering

Vilka är vi. Magnus Ahltorp KTHLAN Ragnar Sundblad KTHLAN & NADA

Konfiguration av synkronisering fo r MSB RIB Lupp

Olika slags datornätverk. Föreläsning 5 Internet ARPANET, Internet började med ARPANET

DNSSEC implementation & test

LABORATIONSRAPPORT Säkerhet och Sårbarhet Laboration 1 Brandväggar

Datakommunika,on på Internet

Unix-Säkerhet. Övningsprov. Frågorna skall besvaras på ett sådant sätt att en insatt kollega skall känna sig informerad.

IPv6 Jonas Aronsson 3TEa

Linuxadministration 1 1DV417

Installation/uppgradering av Agfa IMPAX program för remittenter

Aktivera och använda EtherTalk för Mac OS 9.x. Om du använder EtherTalk behövs ingen IP-adress för Macintosh-datorer.

Datorhårdvaruteknik 1DV426 - Laboration Migrering av lagring från DAS till SAN

Kom-igång-guide Administratör

Robusthetstester och övervakning av DNS. Internetdagarna Rickard Dahlstrand

... historia... I begynnelsen var ARPANET:

3) Routern kontrollerar nu om destinationen återfinns i Routingtabellen av för att se om det finns en väg (route) till denna remote ost.

Startanvisning för Bornets Internet

Startguide för Administratör Kom igång med Microsoft Office 365

Jimmy Bergman Ansvarig för utveckling och roliga skämt vid kaffemaskinen

Rotadministration och serverroller

Konfigurering av eduroam

DNSSEC-grunder. Rickard Bellgrim [ ]

Tentamen i datakommunikation EDA343/DIT420 Vt 2011

Design Collaboration Suite

Installation och setup av Net-controller AXCARD DS-202

LEX INSTRUKTION LEX LDAP

DIG IN TO Nätverksteknologier

DNSSEC DET NÄRMAR SIG...

Version 1.0. Benämning OSG Storage Engine. Senaste revidering Användarbeskrivning

DNS Internets vägvisare

Webbteknik II. Föreläsning 4. Watching the river flow. John Häggerud, 2011

Konfigurationer Video- och distansmöte Bilaga till Tekniska anvisningar

RFC 6106-stöd i Router Advertisment-klienten radns. Michael Cardell Widerkrantz mc@hack.org

Internetdagarna NIC-SE Network Information Centre Sweden AB

INNEHÅLL 30 juni 2015

Lastbalansering för webbservrar

GIVETVIS. SKA DU HA INTERNET I DIN LÄGENHET! En guide till hur du installerar internet i ditt nya hem.

Installation xvis besökssystem, Koncern

DIG IN TO. Nätverksadministration

Anslutningar och Internet Protocol (TCP/IP)

! " #$%&' ( #$!

Anvisningar för installation och borttagning av skrivardrivrutinerna Windows PostScript och PCL utgåva 8

Ladda upp filer fra n PLC till PC

Webbservrar, severskript & webbproduktion

DIG IN TO. Nätverksadministration

Wilhelm Käll. Rapport Användarsupport

RUTINBESKRIVNING FÖR INSTALLATION AV KAMERA

Totalt antal poäng på tentamen: 50 För att få respektive betyg krävs: U<20, 3>=20, 4>=30, 5>=40

Innehållsförteckning ADSync Windows Azure Active Directory ADSynC- Installation Konfigurera ADSync... 4

Systemkrav och tekniska förutsättningar

Syfte. Sammanfattning. IT-miljö

Webbtjänster med API er

Manual - Phonera Online Backup

Transkript:

School of humanities and informatics Datakommunikation Introduktion, 7,5 HP DNS laboration report Wilhelm Käll YYYY-MM-DD (the date the report was finished)

1 Introduktion... 1 2 Topologi... 2 3 Del 1 - Namnuppslagning med host-filer... 2 4 Del 2 Namnuppslagning med DNS... 2 4.1 Zone-deklaration... 3 4.2 Zone-definition... 3 5 Del 3 - Zondeligering... 4 6 Del 3 Chachande DNS-server... 5 7 Del 4 Redundanta namnservrar... 5 8 Del 5 Reverse name lookup... 7 8.1 Målsättning... 7 8.2 Reverse lookup zones... 7 8.3 Stub zones... 8 9 Reflektion... 8 10 Disskution... 9 11 Referenser... 9 12 Appendix A... 9 13 Appendix B... 9 14 Appendix C - atlascopco.nsa.his.zone... 9 15 Appendix D - sde.atlascopco.nsa.his.zone... 10 16 Appendix E gbg.atlascopco.nsa.his.se... 11 17 Appendix F Reverse zone IPv4... 11 18 Appendix G Reverse zone IPv6... 12

1 Introduktion En notis till läsaren! De zone-definitioner som används i laborationen finns tillgängliga som appendix. Uppgiften bygger på att ett system med DNS servrar byggs upp. Olika maskiner ansvarar för olika zoner(domäner / subdomäner) och tillsammans utgör de en fungerande DNS-lösning som i praktiken skulle kunna implementeras på ett större företag. Dock är det primära målet givetvis att studenten skall få en förståelse för hur DNS-systemet är uppbyggt och fungerar i praktiken samt lära sig att arbeta med den specifika DNS-mjukvaran BIND. Varje student har blivit tilldelad en subdomän som sedan skall administreras med hjälp av studentens egna nätverk av namnservrar. I det här fallet är det subdomänen atlascopco.nsa.his.se som har används för ändamålet. I laborationen presenteras ett antal olika problem som efter att ha lösts kommer att ha gett studenten en inblick i hur det fungerar att arbeta med DNS-system. En kort lista med de olika problemen kommer nu att presenteras för att en bra överblick av laborationen skall kunna ges, det kommer sedan presenteras mer utförligt hur dessa problem de facto löstes. Del 1: Enkel namnuppslagning med hjälp av /etc/hosts. Statiska kopplingar mellan värdnamn och IP-adresser. Del 2: Delmomentet innefattar att BIND skall installeras och konfigureras. En zone för domänen atlascopco.nsa.his.se skall deklareras och definieras på en av de virtuella maskinerna, ns1.atlascopco.nsa.his.se. Del 3: BIND installeras på ns2.atlascopco.nsa.his.se och även på ns3.atlascopco.nsa.his.se. De två namnservrarna som lades till i nätverket skall ansvara för två subdomäner som delegeras till dem. De två subdomänerna heter sde och gbg. De två servrarna skall heller inte svara på förfrågningar för annat än information som de själva ansvarar för. I uppgiften ingår även att ett adress-schema skall implementeras. Med hjälp av ett parametrar genereras en IPv4-adress fram. I detta fallet är adressen: 178.140.0.0. Med hjälp av VLSM utformas ett antal subnät. De olika subnäten som kalkyleras kommer innehålla adresser som sedan någon av de två servrarna, ns2 / ns3, kommer ha information om i sina respektive zondefinitioner. Del 4: BIND installeras på maskinen resolver.atlascopco.nsa.his.se. Målsättningen är att maskinen i fråga skall agera som en cachande namnserver för nätverket. Del 5: ns2.sde.atlascopco.nsa.his.se och ns3.gbg.atlascopco.nsa.his.se skall synca varandras zoner. Detta för att skapa redundans mellan de två olika subdomänerna. Om ns3.gbg.atlascopco.nsa.his.se går ner skall ns2.sde.atlascopco.nsa.his.se ta över för den zonen som ns3 ursprungligen ansvarade för. Del 6: I den här delen skall reverse name lookup implementeras. ns1.atlascopco.nsa.his.se skall ansvara för detta. Två zoner deklareras och definieras, samt två stub-zoner på resolver.atlascopco.nsa.his.se som gör att förfrågningar skickas vidare till ns1.atlascopco.nsa.his.se. 1

2 Topologi Innan konfigureringen av DNS infrastrukturen kan inledas måste server-topologin vara installerad och grundkonfigurationen genomförd. För uppgiften kommer två fysiska maskiner att användas, dock kommer den ena agera värdsystem för ytterligare sex virtuella system. Den första fysiska maskinen kommer att användas som klient för uppgiften. De sex virtuella systemen kommer att användas för att köra DNS-servrar och även en webbserver. Alla maskiner som ingår i topologin måste ha korrekta FQDN konfigurerade. Ett exempel på detta är: ns1.atlascopco.nsa.his.se. Värt att notera är att ns2 / ns3 har sde respektive gbg i sina FQDN då dessa system kommer att hantera de två subdomänerna i del 3. Det kommer att förutsättas att den grundläggande konfigureringen av de olika systemen är korrekta när de olika stegen i laborationen förklaras. Detta innefattar FQDN, IPv4/IPv6- adressering samt OS. Givetvis kommer konfigurationen av systemen att ändras i viss mån. 3 Del 1 - Namnuppslagning med host-filer Som en initial uppgift skall värdnamn mappas upp till IP-adresser med hjälp av filen /etc/hosts för Linux/UNIX, %systemroot%\system32\drivers\etc\ för Windows. Filen hosts används bland annat till att skapa statiska mappningar mellan värdnamn och IP-adresser. Genom att lägga till IP-adresser till de maskiner som skall kunna nås via sitt värdnamn I filen kan ett spartanskt namnsystem byggas upp. Precis som det nämndes tidigare byggs systemet upp genom att skriva in ett namn på ett system(värdnamn) samt vilken IP-adress systemet i fråga har. Det kan se ut som följande: IPv4# 10.207.14.11 ns1.atlascopco.nsa.his.se ns1 IPv6# 2001:0db8::11 ns1.atlascopco.nsa.his.se ns1 För att konfigurationen skall vara syntaxiskt korrekt anges IP-adress först, sedan värdnamnet på maskinen som en mappning skall skapas mellan. Samtliga hosts i labbmiljön skall vara definierade i hosts-filen. Detta för att det skall gå att få kontakt med alla maskiner utan att skriva in en IP-adress till systemet i fråga. Fungerar detta som tänk har ett primitvt namnuppslagningssystem byggts upp. Den fullständiga listan med kopplingar mellan värdnamn och IP-adresser synkroniseras mellan övriga system för att samma typer av kopplingar skall ske över hela labbmiljön. Se appendix B för en fullständig representering av en hosts-fil. 4 Del 2 Namnuppslagning med DNS I delmomentet utförs grundläggande konfiguration av BIND på en av de fyra olika namnservrarna. Servern som används för det här delmomentet är ns1.atlascopco.nsa.his.se. BIND installeras inledningsvis på den aktuella maskinen. Default konfigurationen som följer med Debians paket av BIND fungerar bra för ändamålet. Konfigurationsfiler är sparade i mappen /etc/bind/. Målet med uppgiften är att skapa en zone-deklaration för atlascopco.nsa.his.se för att kunna resolva adresser, detta utförs genom att först modifiera filen named.conf.local. I filen måste zonen som skall defineras deklareras. 2

4.1 Zone-deklaration Det första som måste utföras är att skapa en deklaration av zonen atlascopco.nsa.his.se. Zonen namnges efter den domänen som skall administreras. Detta sker med hjälp av följande rader kod: zone "atlascopco.nsa.his.se" IN { type master; file "/zones/atlascopco.nsa.his.zone"; allow-update { none; Raderna ovanför deklarerar zonen atlascopco.nsa.his.se. Koden informerar BIND att använda sig av filen atlascopco.nsa.his.zone som ligger i mappen /zones/ för definitionen av zonen, det vill säga där själva konfigurationen finns. I deklarationen fastställs det även att zonen är av typen master vilket i kort innebär att zone-definitionen är lokal och att zonen är auktoritär. A zone master obtains the zone data from a local zone file as opposed to a zone slave, which obtains its zone data via a zone transfer operation from the zone master. (Aitchison, 2011, s.65) 4.2 Zone-definition I nästa skede skall definitionen av zonen skapas. Detta innebär att zone-filen skapas på filsystemet. Enligt konfigurationen i punkt 4.1 skall zone-filen ligga i mappen /zones/. Det viktigaste i zone-filen är Start Of Authority(SOA) som beskriver zonens egenskaper. Utan SOA kommer inte zonen att fungera, det är med andra ord av yttersta vikt att detta konfigureras korrekt. SOA definieras med följande rader kod atlascopco.nsa.his.se. IN SOA ns1.atlascopco.nsa.his.se. admin.atlascopco.nsa.his.se. ( 2012103102 ; 21600 ; 3600 ; 604800 ; 86400 ) ; atlascopco.nsa.his.se. IN NS ns1.atlascopco.nsa.his.se. De parametrar som är viktiga i SOA är de som hanterar vilken domän det är som används, vilken server det är som ansvarar för domänen och mailadress till administratören eller annan ansvarig för domänen. I koden ovanför specificeras det att atlascopco.nsa.his.se är den aktuella domänen samt att ns1.atlascopco.nsa.his.se är servern som ansvarar för domänen. Efter ett korrekt angett SOA kan adresser till de olika systemen matas in. De adresser som finns i listan är de adresser som BIND slutligen kan slå upp inom domänen atlascopco.nsa.his.se. De typer av resource records som används för de olika adresserna är i det här fallet A, AAAA och CNAME. A är ett så kallat address record som används för att mappa upp värdnamn till IP-adresser, AAAA är samma som föregående fast för IPv6-adresser. CNAME används för att skapa alias till andra mappningar, man skulle kunna jämföra det med ett smeknamn, ett annat namn men refererar ändå till samma individ(i det här fallet en dator). 3

Raderna kod nedanför är ett utdrag från ns1.atlascopco.nsa.his.se zone-definition. www IN A 10.207.14.15 www IN AAAA 2001:0db8::15 webmail IN CNAME www För att kunna testa servern ändras filen /etc/resolv.conf. I filen kan konfiguration utföras för att ändra vilken DNS-server maskinen i fråga skall använda samt vilken search domain som används. För att kunna testa ns1 måste den användas I resolv.conf. Nameserver ställs in till IPv4-adressen som ns1 är inställd på, detta för att maskinen skall använda sin egna DNS-server: nameserver=10.207.14.11 search=atlascopco.nsa.his.se Även search ställs in till atlascopco.nsa.his.se, detta för att slippa lägga till domännamnet på värdnamn när adresser till exempel skall pingas: ping www Istället för: ping www.atlascopco.nsa.his.se 5 Del 3 - Zondeligering Målsättningen är att namnservrarna ns2 och ns3 skall ansvara för två subdomäner, sde.atlascopco.nsa.his.se respektive gbg.atlascopco.nsa.his.se. Detta utförs genom att delegera auktoritet för de olika zonerna till de två servrarna ns2 och ns3. ns2 skall ansvara för zonen sde.atlascopco.nsa.his.se ns3 skall ansvara för zonen gbg.atlascopco.nsa.his.se Precis som tidigare deklareras och definieras de två nya zonerna på respektive maskin. Detta innebär att zonernas konfiguration i stort sätt är den samma som i del 1 när det kommer till zone-definitionen. För demonstrationssyfte kommer ett utdrag från ns2 som ansvarar för sdesubdomänen: sde.atlascopco.nsa.his.se. IN SOA ns2.sde.atlascopco.nsa.his.se. admin.atlascopco.nsa.his.se. ( 2012112008; 604800; 86400; 2419200; 604800); sde.atlascopco.nsa.his.se. IN NS ns2.sde.atlascopco.nsa.his.se. I koden ovanför syns det att istället för atlascopco.nsa.his.se står det sde i början av domännamnet. Detta är för att det är den subdomänen / zonen servern skall ansvara för. I kort talar raderna kod ovanför om att ns2.sde.atlascopco.nsa.his.se ansvarar för subdomänen sde.atlascopco.nsa.his.se. Samma procedur sker på ns3, dock ansvarar den maskinen för subdomänen gbg.atlascopco.nsa.his.se. För själva delegeringen av subdomänerna måste ns1 vara varse om vilken maskin det är som hanterar respektive subdomän. Detta sker genom att deklarera aktuell subdomän med ett NS record och ett A record. Följande rader talar om för ns1 att ns3 kommer att hantera gbg.atlascopco.nsa.his.se. gbg.atlascopco.nsa.his.se. IN NS ns3.gbg.atlascopco.nsa.his.se. ns3.gbg IN A 10.207.14.13 4

Följande rader talar om för ns1 att ns2 kommer att hantera sde.atlascopco.nsa.his.se. sde.atlascopco.nsa.his.se. IN NS ns2.sde.atlascopco.nsa.his.se. ns2.sde IN A 10.207.14.12 Förfrågningar som är avsedda för sde eller gbg kommer således att hanteras av ns2 respektive ns3. För att detta skall fungera korrekt förutsätter det att zone-konfigurationen är korrekt och att de två nya maskinerna är på. Dessa finns tillgängliga som appendix. ns2 och ns3 skall inte heller svara på förfrågningar som inte faller inom deras egna zoner. Det vill säga, en lookup på www.google.se skall inte kunna besvaras av varken ns2 eller ns3. Detta kan utföras genom att lägga till kodsnutten i named.conf.options: recursion no; Dock är det värt att tillägga att ns1 fortfarande kan svara på den typen av förfrågningar. (Zytrax, 2011) I uppgiften ingår även att ett adress-schema skall tas fram. De olika subnäten och dess egenskaper finns tillgängliga i Appendix B. 6 Del 3 Chachande DNS-server BIND installeras på resolver, resolver.atlascopco.nsa.his.se. BIND skall cacha information från tidigare lookups. BIND kommer att cacha DNS-information automatiskt, därför krävs ingen speciell konfiguration för att det skall utföras. Det krävs inte heller någon annan direkt konfiguration för att resolver skall skicka vidare förfrågningar som sedan ns1 tar hand om. Eftersom ns1 är auktoritativ för atlascopco.nsa.his.se kommer förfrågningar skickas vidare dit per automatik enligt DNS hierarkiska system. Med tanke på att resolver.atlascopco.nsa.his.se nu mera skall användas för att göra namnuppslagningar behöver alla maskiner använda den maskinen som sin primära namnserver. I Linux utförs detta genom att ändra filen /etc/resolv.conf och lägga till följande rader kod: nameserver=10.207.14.20 search=atlascopco.nsa.his.se Detta för att använda resolver som primär namnserver och atlascopco.nsa.his.se som sökdomän. Precis som i föregående del måste recursion no; läggas till i named.conf.options på ns1 för att inte heller den skall svara på recursive requests. Efter att det är gjort kommer resolver.atlascopco.nsa.his.se sköta uppslagningar som inte faller inom atlascopco.nsa.his.se domänen. 7 Del 4 Redundanta namnservrar Målsättningen är att redundans skall skapas mellan sde och gbg zonerna. Det har sedan tidigare deklarerats zoner för gbg.atlascopco.nsa.his.se och sde.atlascopco.nsa.his.se på ns2 och ns3. Dessa zoner är satta till type master; vilket innebär att deras definitioner ligger på respektive system och att de är auktoritära för de zonerna. För att åstadkomma redundansen behöver ns2 som normalt sätt auktoritär för sde.atlascopco.nsa.his.se även hantera gbg.atlascopco.nsa.his.se som normalt sätt hanteras av ns3 och vise versa. För att säga till de två olika systemen att de även skall hantera gbg.atlascopco.nsa.his.se och sde.atlascopco.nsa.his.se behövs zone-deklarationer med typen slave på både ns2 och ns3. Att använda typen slave innebär att zone-filen måste synkroniseras från master zonen. Överföringar mellan de olika maskinerna behöver även tillåtas för att data skall kunna 5

skickas mellan de två olika namnservrarna, det behöver även indikeras vilken server som har zone-definitionen tillgänglig. ns2.sde.atlascopco.nsa.his.se zone "sde.atlascopco.nsa.his.se" IN { type master; file "/zones/sde.atlascopco.nsa.his.zone"; allow-update { none; allow-transfer { 10.207.14.13; zone "gbg.atlascopco.nsa.his.se" IN { type slave; file "/zones/gbg.atlascopco.nsa.his.zone"; allow-transfer { none; masters { 10.207.14.13; ns3.sde.atlascopco.nsa.his.se zone "gbg.atlascopco.nsa.his.se" IN { type master; file "/zones/gbg.atlascopco.nsa.his.zone ; allow-update { none; allow-transfer { 10.207.14.12; zone "sde.atlascopco.nsa.his.se" IN { type slave; file "/zones/sde.atlascopco.nsa.his.se"; masters { 10.207.14.12; Dessa rader kod talar om att ns2 ansvarar zonen sde.atlascopco.nsa.his.se samt att zonedatan kan överföras till klienten med adressen IP-adressen 10.207.14.14, det vill säga, ns3.gbg.atlascopco.nsa.his.se. De säger även att zonen gbg.atlascopco.nsa.his.se är av typen slave, det innebär att zonen kommer att synkroniseras från server som är satt till master, i detta fallet är det 10.207.14.13 vilket representerar ns3.gbg.atlascopco.nsa.his.se. Samma typ av konfiguration sker även på ns3 fast i omvänd ordning. Poängen med detta är i varje fall att de två servrarna kommer att synkronisera zone-data mellan varandra. Detta kommer slutligen innebära att redundans möjliggörs. Kod för att tala om att ns2 även hanterar zoner för ns3 och att ns3 även hanterar zoner för ns2 behöver läggas till så den faktiska hanteringen av redundans kan ske. Denna identifikation sker dels i zone-filerna hos respektive maskin(ns2/ns3) men även hos ns1. gbg.atlascopco.nsa.his.se. IN NS gbg.atlascopco.nsa.his.se. IN NS ns3.gbg.atlascopco.nsa.his.se. ns2.sde.atlascopco.nsa.his.se. sde.atlascopco.nsa.his.se. IN NS ns2.sde.atlascopco.nsa.his.se. sde.atlascopco.nsa.his.se. IN NS ns3.gbg.atlascopco.nsa.his.se. Koden ovan anger att subdomänen sde.atlascopco.nsa.his.se hanteras både av ns2 samt ns3 och att gbg.atlascopco.nsa.his.se hanteras av ns3 samt ns2. Detta kommer tala om 6

vilka namnservrar som ansvarar för de två subdomänerna. Samma sak behöver även deklareras hos de individuella zonerna för att tala om att de olika namnservrarna även har hand om andra zoner. @ IN NS ns2.sde.atlascopco.nsa.his.se. IN NS ns3.gbg.atlascopco.nsa.his.se. Texten ovan är hämtad från ns2, mer specifikt zone filen sde.atlascopco.nsa.his.zone. Samma typ av konfiguration sker på ns3: @ IN NS ns3.gbg.atlascopco.nsa.his.se. IN NS ns2.sde.atlascopco.nsa.his.se. Dessa rader kod talar om att även ns2 hanterar zonen gbg.atlascopco.nsa.his.se. Hela konfigurationen för sde / gbg finns tillgänligt som appendix. När konfigurationen är färdig kommer zonerna skickas mellan de två namnservrarna så de I sin tur kan ta över för namnservrar som går ner. Detta momentet kalls för zone-transfers. Verifiering av redundansen sker genom att stoppa BIND på antingen ns2 eller ns3, rensa cachen på både ns1 samt resolver. Sedan köra en lookup på hosts som finns under servern vars BIND-daemon stängdes ner. 8 Del 5 Reverse name lookup 8.1 Målsättning Momentet innefattar att reverse name lookup skall fungera. Det innebär att lookups kan göras på en IP-adress och värdnamnet för adressen visas. Ett exempel på detta skulle kunna vara: $ nslookup 10.207.14.11 Resultatet skulle i detta fallet vara att svaret blir: ns1.atlascopco.nsa.his.se. Det skall även fungera att använda sig av lookups med IPv6 protokollet. För att möjliggöra önskad funktionalitet behöver två reverse lookup zones finnas, en zone för IPv4 och IPv6. Detta på grund av att adresseringen ser annorlunda ut för de två olika protokollen. 8.2 Reverse lookup zones De två zonerna som beskrevs tidigare I texten skall hanteras av ns1. De två zonerna deklareras i named.conf.local med följande stycke kod: zone "14.207.10.in-addr.arpa" IN { type master; file "/zones/0.14.207.10.in-addr.arpa"; allow-update { none; zone "0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa" { type master; file "/zones/reverse-2001-db8_64.ip6.arpa"; allow-update { none; Den första zonen hanterar IPv4 och den andra zonen hanterar IPv6. Det går att utläsa vilken nätverksadress zonen hanterar I namnet på zonen. Som ett exempel är IPv4-zonen 10.207.14. Samma sak gäller för IPv6-zonen. Namnet på zonerna är med andra ord nätverksadresserna på de nätverk som reverse lookups skall kunna utföras på. Definitionen av zonerna sker enligt följande: 7

$ORIGIN 14.207.10.in-addr.arpa. $TTL 86400 @ IN SOA ns1.atlascopco.nsa.his.se. admin.atlascopco.nsa.his.se. ( 2012103102 ; serial 21600 ; refresh 3600 ; 604800 ; 86400 ) ; @ IN NS ns1.atlascopco.nsa.his.se. Precis som vid skapande av en vanlig zone sätts $ORIGIN till den domänen som omfattas. I det här fallet är det 10.207.14.in-addr.arpa. som används. För att lookups skall funka enligt uppgiftens mål behöver BIND veta om vilka hosts som har ett visst host-nummer, d.v.s, hostdelen i IP-adressen. En sådan typ av konfigurering ser ut som följande: 15 IN PTR www.atlascopco.nsa.his.se. Den fullständiga adressen skulle således vara 10.207.14.15. I det här fallet används även ett PTR record vilket är den typen av resource record som används vid den här typen av operationer, reverse DNS record. Alla de adresser som det skall gå att utföra lookups på måste vara närvarande i den här zonen. Se appendix för de två reverse lookup zonerna. 8.3 Stub zones I nuläget kan dock bara ns1 utföra reverse name lookups. Målsättningen är att klienter skall kunna utföra lookups även fast det är resolver.atlascopco.nsa.his.se som används som primär namnserver. Resolver behöver med andra ord bli varse om att ns1 är auktoritär för de två reverse lookup zonerna som definerades tidigare. För att möjliggöra önskad funktionalitet deklareras två zoner med typen stub. De två zonerna kommer göra det möjligt för resolver att identifiera vilken namnserver det är som är auktoritär för de två zonerna, nämligen ns1. En deklaration av en sådan stub-zone ser ut som följande: zone "14.207.10.in-addr.arpa" IN { type stub; masters { 10.207.14.11; Typen som används är stub samt att mastern, servern som hanterar zonen, är 10.207.14.11 med andra ord ns1. En stub-zone för IPv6 måste finnas för att reverse lookups på den typen av adresser skall fungera. Detta sker på samma sätt som med IPv4-zonen: zone "0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa" IN { type stub; masters { 10.207.14.11; 9 Reflektion Det har varit en väldigt besvärlig rapport att skriva. Jag har valt att lägga fokus på de moment i laborationen som har varit vitala för systemets funktionalitet. Jag har även haft problem med att veta hur ingående jag bör vara när rapporten skrevs, ingen tydlig information har delats ut angående detta. Sammanfattningsvis bör jag konstatera att det var jobbigare att skriva rapporten än att faktiskt lära sig BIND och implementera det i servermiljön. 8

10 Disskution Systemet jag byggde upp fungerar precis som det är tänkt att det skall göra. Alla målsättningar som målades upp i labben är avklarade. Sammanfattningsvis kan jag konstatera att jag har lärt mig väldigt mycket om DNS som system och BIND som mjukvara. 11 Referenser Ron Aitchison(2011). Pro DNS and BIND10. (ISBN: 1430230487) Zytrax(211). HOWTO - Delegate a Sub-domain. Tillgänlig på Internet: http://www.zytrax.com/books/dns/ [Hämtad 12.11.10] 12 Appendix A 13 Appendix B 10.207.14.11 ns1.atlascopco.nsa.his.se ns1 10.207.14.12 ns2.sde.atlascopco.nsa.his.se ns2 10.207.14.13 ns3.gbg.atlascopco.nsa.his.se ns3 10.207.14.15 www.atlascopco.nsa.his.se webmail.atlascopco.nsa.his.se www webmail 10.207.14.20 resolver.atlascopco.nsa.his.se resolver 2001:0db8::11 ns1.atlascopco.nsa.his.se ns1 2001:0db8::12 ns2.sde.atlascopco.nsa.his.se ns2 2001:0db8::13 ns3.gbg.atlascopco.nsa.his.se ns3 2001:0db8::15 www.atlascopco.nsa.his.se webmail.atlascopco.nsa.his.se www webmail 2001:0db8::20 resolver.atlascopco.nsa.his.se resolver 14 Appendix C - atlascopco.nsa.his.zone $ORIGIN atlascopco.nsa.his.se. $TTL 86400 atlascopco.nsa.his.se. IN SOA ns1.atlascopco.nsa.his.se. admin.atlascopco.nsa.his.se. ( 2012103102 ; 21600 ; 3600 ; 604800 ; 86400 ) ; atlascopco.nsa.his.se. IN NS ns1.atlascopco.nsa.his.se. 9

ns1 IN A 10.207.14.11 ns1 IN AAAA 2001:0db8:0000:0000:0000:0000:0000:11 www IN A 10.207.14.15 www IN AAAA 2001:0db8::15 resolver IN A 10.207.14.20 resolver IN AAAA 2001:0db8:0000:0000:0000:0000:0000:20 webmail IN CNAME www gbg.atlascopco.nsa.his.se. IN NS gbg.atlascopco.nsa.his.se. IN NS ns3.gbg IN A 10.207.14.13 ns3.gbg IN AAAA 2001:0db8:0000:0000:0000:0000:0000:13 sde.atlascopco.nsa.his.se. ns2.sde.atlascopco.nsa.his.se. sde.atlascopco.nsa.his.se. ns3.gbg.atlascopco.nsa.his.se. ns2.sde IN A 10.207.14.12 ns3.gbg.atlascopco.nsa.his.se. ns2.sde.atlascopco.nsa.his.se. IN NS IN NS ns2.sde IN AAAA 2001:0db8:0000:0000:0000:0000:0000:12 15 Appendix D - sde.atlascopco.nsa.his.zone $TTL 604800 $ORIGIN sde.atlascopco.nsa.his.se. sde.atlascopco.nsa.his.se. IN SOA ns2.sde.atlascopco.nsa.his.se. admin.atlascopco.nsa.his.se. ( ; 2012112008 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL @ IN NS ns2.sde.atlascopco.nsa.his.se. @ IN NS ns2.sde.atlascopco.nsa.his.se. IN NS ns3.gbg.atlascopco.nsa.his.se. ns2 IN A 10.207.14.12 blueprintdb IN A 178.140.9.30 blueprintdb IN AAAA fd00::30 vpngw IN A 178.140.7.254 vpngw IN AAAA fd00::254 10

16 Appendix E gbg.atlascopco.nsa.his.se $ORIGIN gbg.atlascopco.nsa.his.se. $TTL 86400 gbg.atlascopco.nsa.his.se. IN SOA ns3.gbg.atlascopco.nsa.his.se. admin.gbg.atlascopco.nsa.his.se. ( 2012111106 ; serial 2m ; refresh 3600 ; 604800 ; 86400 ) ; gbg.atlascopco.nsa.his.se. IN NS ns3.gbg.atlascopco.nsa.his.se. @ IN NS ns3.gbg.atlascopco.nsa.his.se. IN NS ns2.sde.atlascopco.nsa.his.se. ns3 IN A 10.207.14.13 ns3 IN AAAA 2001:db8::13 fileserver IN A 178.140.9.62 fileserver IN AAAA fc00::62 backup IN A 178.140.8.190 backup IN AAAA fc00::190 secretstash IN A 178.140.6.126 secretstash IN AAAA fc00::126 announcementsdb IN A 178.140.10.22 announcementsdb IN AAAA fc00::22 testserver IN A 178.140.10.21 testserver IN AAAA fc00::21 17 Appendix F Reverse zone IPv4 $ORIGIN 14.207.10.in-addr.arpa. $TTL 86400 @ IN SOA ns1.atlascopco.nsa.his.se. admin.atlascopco.nsa.his.se. ( 2012103102 ; serial 21600 ; refresh 3600 ; 604800 ; 86400 ) ; @ IN NS ns1.atlascopco.nsa.his.se. 11 IN PTR ns1.atlascopco.nsa.his.se. 12 IN PTR ns2.sde.atlascopco.nsa.his.se. 13 IN PTR ns3.gbg.atlascopco.nsa.his.se.

15 IN PTR www.atlascopco.nsa.his.se. 20 IN PTR resolver.atlascopco.nsa.his.se. 18 Appendix G Reverse zone IPv6 $TTL 3d @ IN SOA 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. mail.atlascopco.nsa.his.se. ( ) 201211280 ; 24h ; 30m ; 2d ; 3d ; ns1.atlascopco.nsa.his.se. ns2.sde.atlascopco.nsa.his.se. ns3.gbg.atlascopco.nsa.his.se. $ORIGIN 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. 5.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR www.atlascopco.nsa.his.se. 2.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR ns2.sde.atlascopco.nsa.his.se. 3.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR ns3.gbg.atlascopco.nsa.his.se. 0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR resolver.atlascopco.nsa.his.se. IN IN IN NS NS NS