Thuis
Contacten

    Hoofdpagina


Vraag 1: dhcp

Dovnload 74.98 Kb.

Vraag 1: dhcp



Datum26.04.2017
Grootte74.98 Kb.

Dovnload 74.98 Kb.

Reeks B



Vraag 1:  DHCP (§2.1 & §2.1.1)

  1. Geef een overzicht van de belangrijkste DHCP concepten en terminologie.

  2. Waarin verschilt DHCP van BOOTP ? Beschrijf de structuur van DHCP berichten. Je hoeft de verschillende types berichten niet te vermelden.

  3. Waarom voert DHCP opties in ?

  4. Geef een overzicht van de courant gebruikte DHCP opties.

  5. Beschrijf wat er gebeurt op DHCP niveau bij het heropstarten van een Windows Server toestel, nadat men een shutdown heeft uitgevoerd.

  6. Beschrijf wat er gebeurt indien een Windows Server DHCP-cliënt geen DHCP-server kan bereiken.

A)

Concepten:

- Dynamic Host Configuration Protocol: telkens wanneer computer opstart  automatisch TCP/IP configuratiegegevens opvragen via netwerk. Ook Reverse Address Resolution Protocol en Bootstrap Protocol.

- Cliënt stuurt bij opstarten DHCP-aanvraag naar alle computers op lokale netwerk (niet verder want netwerksoftware niet volledig actief) in de hoop antwoord van DHCP-server te krijgen. DHCP-server zendt configuratie informatie.

- DHCP-server bevat lijst van configuratie informatie voor specifieke geregistreerde computers (permanente configuratie, toestellen met nood aan vaste identificatie naar buitenwereld vb. www-servers). Hij kan ook dynamisch adressen uitdelen aan niet-geregistreerde computers (volgende vrije adres uit DHCP-scope wordt toegekend). Deze adressen hebben beperkte lease  onderhandeling cliënt-server voor verlenging.

- DHCP-server kan zichzelf geen ip-adres toewijzen  manueel IP-adres configureren.

- DHCP-server kan ook gebruikt worden op netwerk dat meer pc’s bevat dan maximum toegelaten aantal  niet allemaal tegelijk actief.

- DHCP koppelt IP-adres en MAC-adres  onthouden IP-adres van machine.

- TCP/IP instellingen cliënt automatisch opnieuw geconfigureerd indien opgestart op nieuwe locatie.

- DHCP voordelen: beperking complexiteit, vermijden configuratiefouten en adresconflicten, onafhankelijk van besturingssysteem.


Terminologie:

DHCP-servers: bevatten configuratie informatie voor DHCP-cliënts.

DHCP-cliënts: computers die van de diensten v/ DHCP-servers willen gebruik maken

DHCP-scope: een reservoir van vrije IP-adressen (dynamisch uitdelen adressen)

Lease: de geldigeheidsduur van een IP-adres, dynamisch toegekend.

DHCP-opties: gecodeerde gegevensitems die opgeslagen worden in de protocolberichten, uitgewisseld tussen DHCP-server en zijn cliënt.
B)

Verschil DHCP <> BOOTP:

  • BOOTP: vereist op voorhand een lijst van alle MAC-adressen v/d ethernetkaarten

  • BOOTP: geen mogelijkheid om tijdelijke IP-adressen ter beschikking te stellen

  • DHCP = BOOTP + scopes + opties (in TLV formaat).


Structuur berichten:

1) Header: vaste lengte (282 bytes). DHCP header identiek aan BOOTP header.

  • Transactie ID: cliënt weet dan voor welke vraag het gekregen antwoord is

  • IP (zonder subnetmasker) + MAC-adressen cliënt

  • IP + naam server

2) Variabele lengte: bevat opties. Elke optie bevat 3 velden: veld1 (1 byte, identificeert optie), veld2 (1 byte, grootte in bytes van veld 3), veld 3 (waarde v/d optie).

  • magic cookie : veld van 4 vaste bytes (99.130.83.99), gaat opties vooraf  identificeert formaat DHCP-bericht (t.o.v. BOOTP-bericht).

  • Optie 255: niet verplicht, aanduiden einde DHCP-opties, enkel veld1, alles na deze optie wordt genegeerd.

  • Padding veld: niet verplicht, verschillende opties in DHCP-bericht uitlijnen op woordgrenzen, enkel veld 1, zelf als optie 0 geïmplementeerd.

C)

Bij toewijzing van een adres kan meteen ook een heel pakket configuratiewaarden doorgegeven worden. Als DHCP-server optie aanbiedt waarmee cliënt niets kan aanvangen  optie wordt genegeerd.


D)

1

3
6
12

15
19

23

28


31

33
35

69

70


duidt het subnetmasker v/h cliëntsubnet aan

een lijst met IP-adressen van default gateways, die door de cliënt in volgorde gebruikt worden

een lijst met IP-adressen van DNS nameservers, die door de cliënt in volgorde gebruikt worden

een naam voor de cliënt met een maximumlengte van 63 tekens

de DNS suffix, die door de cliënt gebruikt wordt bij het herleiden van niet-gekwalificeerde DNS namen

bepaalt of de cliënt de functie van router vervult

geeft de standaard ttl-waarde aan voor uitgaande datagrammen

doorgaans 255.255.255.255, maar kan gewijzigd worden in andere geldige waarden voor broadcast adressen

geeft aan of de cliënt routers aanvraagt via ICMP router-discovery

lijst met paren IP-adressen, telkens het netwerkadres en het routeradres van een route

geeft een time-out waarde in seconden voor vermeldingen in de ARP cache

een lijst met IP-adressen voor SMTP servers, in volgorde van voorkeur

een lijst met IP-adressen voor POP3 servers, in volgorde van voorkeur



E)

Na opnieuw opstarten wordt geprobeerd oude lease te verlengen (DHCP-Request zenden), als DHCP-server (waarvan ip verkregen) niet beschikbaar is  ping naar default gateway om te zien of ze nog in zelfde netwerk zitten. Indien ja  oude lease stilzwijgend verder gebruiken.


F)

Indien geen DHCP-server kan bereikt worden dan kunnen Linux- en Windows-clients met een tijdelijke IP-configuratie werken (= Automatic Private IP Addressing of automatische IP-configuratie). Zeer nuttig voor cliënts in kleine netwerken.

De adressen worden automatisch toegekend uit klass-B adressen 169.254/16 (niet gebruikt op Internet). Deze toewijzingen zijn transparant voor gebruikers en ze krijgen geen waarschuwing als adreslease bij DHCP-server mislukt is.

DHCP-cliënt zal dan conflictendetectie uitvoeren door met Gratuitous ARP aanvraag te controleren of IP-adres gebruikt is in netwerk. Indien bezet wordt ander random IP-adres gekozen en getest (win: max 10 keer).

DHCP-cliënts blijven in de achtergrond proberen (win: elke 5min) de DHCP-server te bereiken en adreslease te verkrijgen. Indien dit lukt dan vervalt de automatische configuratie en gebruikt DHCP-cliënt configuratie door DHCP-server aangeboden.

Vraag 2:  DHCP leaseprocessen en relay-agents (§2.1.2 & §2.1.3)


  1. Geef een overzicht van de verschillende types DHCP berichten.

  2. Bespreek de opeenvolgende stappen van beide DHCP leaseprocessen.

  3. Bespreek doel en werking van DHCP relay-agents. Welke velden in DHCP berichten helpen deze functie realiseren ?

  4. Indien je over een aantal DHCP servers beschikt, hoe kun je deze best configureren om een internetwerk, bestaand uit een aantal netwerken, te ondersteunen ?

  5. Hoe kunnen Linux en Windows 2000 toestellen als DHCP relay-agent worden geconfi­gureerd ?



A)

Tijdens leaseprocessen tussen DHCP-cliënts en DHCP-servers worden 8 verschillende types berichten gebruikt. Type wordt aangegeven met optie 53. Berichten zijn ingekapseld in UDP (poortnummers 67 & 68).



  • DHCP-Discovery bericht

  • DHCP-Offer bericht

  • DHCP-Request bericht

  • DHCP-Decline bericht

  • Positief DHCP-acknowledgment bericht

  • Negatief DHCP-acknowledgment bericht

  • DHCP-Release bericht

  • DHCP-Inform bericht


B)

Initialisatie voor de eerste keer:

 wanneer computer voor eerst gestart wordt en zich probeert aan te melden bij het netwerk.




  1. DHCP-cliënt verzendt DHCP-discovery broadcast bericht. In het bericht wordt onderhandeld over leasetijden en gewenste gegevens (opties 51: gewenste leasetijd, optie 55: lijst van gewenste opties). IP-adres van DHCP-cliënt in bericht is 0.0.0.0, dat van destination is 255.255.255.255.

  2. Reactie DHCP-servers met DHCP-Offer bericht waarin IP-adreslease wordt aangeboden. DHCP-server zal aangeboden adres voorlopig reserveren voor de cliënt, want DHCP-cliënts krijgen doorgaans zelfde ip na heropstarten. Met optie 54 wordt de serveridentificatie (ip-adres) opgenomen  DHCP-cliënt kan onderscheid maken tussen verschillende leaseaanbiedingen. Als er geen DHCP-Offer bericht wordt ontvangen gaat de DHCP-cliënt periodiek (met wachtperiode) opnieuw DHCP-Discovery berichten zenden tot hij uiteindelijk een DHCP-Offer bericht ontvangt.

  3. DHCP-cliënt kiest één van de DHCP-Offer berichten (meestal de eerste) en zendt een DHCP-Request bericht naar de corresponderende server (met optie 54 wordt serveridentificatie ingevuld). Dit wordt gebroadcast zodat andere DHCP-servers zien dat ze niet gekozen zijn  zullen hun gereserveerde adres weer vrij maken.

  4. DHCP-server zendt meestal Positief DHCP-acknowledgment bericht om de lease te bevestigen, vereiste DHCP-opties worden eveneens meegstuurd. Soms Negatief DHCP-acknowledgment bericht (aanvraag subnet waarvoor geen scope beschikbaar is, aanvraag bezet ip-adres)  initialisatie mislukt  opnieuw vanaf stap 1 beginnen.

  5. Als Positief DHCP-acknowledgment bericht is ontvangen  TCP/IP eigenschappen v/ DHCP-cliënt worden geconfigureerd, aanmelden op netwerk.

Als er één van configuratieparameters foutief is  DHCP-cliënt zendt DHCP-Decline bericht naar DHCP-server  opnieuw naar stap1.

DHCP-cliënt wil aanvullende informatie  hij zendt DHCP-Inform bericht

DHCP-cliënt heeft lease niet meer nodig  hij zendt DHCP-Release bericht

Vernieuwingsproces:

 Als helft van leasetijd is verlopen (T1), dan gaat DHCP-cliënt vernieuwsproces starten om lease te verlengen. Met optie 58 kan afgeweken worden van (T1).




  1. DHCP-cliënt zendt (rechtstreeks) DHCP-Request bericht naar DHCP-server om adreslease te vernieuwen en te verlengen.

  2. DHCP-server zendt meestal (indien bereikbaar) Positief DHCP-Acknowledgment bericht naar DHCP-cliënt. Ook worden DHCP-opties meegezonden en automatisch geconfigureerd indien nodig  dynamische aanpassing lease instellingen. Indien geen DHCP-Acknowledgment bericht ontvangen  periodiek (met wachtperiode) DHCP-Request bericht opnieuw verzenden.

  3. Indien geen communicatie met DHCP-server mogelijk  DHCP-cliënt wacht tot T2 (7/8 v/d leasetijd, tenzij optie 59 is geconfigureerd), dit is de tijd voor rebinding  indien verstreken: rebinding status geactiveerd  DHCP-cliënt zal bij willekeurige DHCP-server lease proberen te verlengen.

  4. Als er DHCP-server reageert met DHCP-Acknowledgment om cliëntlease bij te werken  DHCP-cliënt zal lease bij deze DHCP-server verlengen. Indien dit bericht niet wordt ontvangen  DHCP-Request bericht wordt 3 maal herhaald (4+,8+ en 16+ seconden).

  5. Als lease verloopt en DHCP-cliënt heeft geen verlenging kunnen bekomen  adreslease onmiddellijk beëindigen = TCP/IP op DHCP-cliënt deactiveren. DHCP-cliënt moet van voorafaan herbeginnen (initialisatieproces).


C)

Doel: Dit is een klein programmatje dat DHCP-berichten doorgeeft tussen cliënts en servers in verschillende subnetten. Dit is nodig omdat routers geen broadcastberichten (vb. DHCP-Discovery) doorzenden.

Opm: Meeste routers ondersteunen functionaliteit van BOOTP-relay agent en omdat BOOTP-berichten zelfde UDP-poorten gebruiken en zelfde structuur hebben als DHCP-berichten zullen deze ook doorgezonden worden door deze routers.

Als router deze functionaliteit niet aankan dan moet elk subnet een DHCP-server hebben of op elk subnet moet een computer functioneren als relay-agent.



Werking: relay-agent ontvangt DHCP-berichten die als broadcast berichten binnenkomen op één van zijn interfaces, hij geeft deze berichten rechtstreeks, point-to-point door aan gekende DHCP-servers of hij broadcast ze opnieuw naar alle externe subnetten via zijn interfaces bereikbaar. Aantal opeenvolgende broadcasts is beperkt: win max 4. BOOTP-header van DHCP-bericht bevat hop-veld dat telkens verhoogd wordt.

Velden: Gateway ip-adres in de header v/h DHCP-bericht  als de relay agent een DHCP-bericht ontvangt en dit veld staat op 0.0.0.0 dan vult hij hierin zijn eigen ip-adres. A.d.h.v dit ip-adres kan de DHCP-server beslissen als hij beschikt over een scope voor het subnet waarop de DHCP-cliënt zich bevindt. Hop-veld  max aantal broadcasts.
D)

Best DHCP-servers in verschillende subnetten plaatsen. Er is echter geen enkel mechanisme voor communicatie tussen DHCP-servers  geen gemeenchappelijke ip-adressen in hun scopes. Dikwijls wordt volgende vuistregel gehanteerd:

80% van het adresbereik van een subnet laten beheren door een DHCP-server van dat subnet en 20% laten beheren door DHCP-servers op externe subnetten.
E)

Linux: commando dhcrelay met als argumenten ip-adressen van één of meerdere DHCP-servers aan dewelke DHCP-berichten moeten doorgestuurd worden.

Windows:Analoog als RIP en OSPF wordt DHCP Relay Agent als nieuw routingprotocol toegevoegd m.b.v. rrasmgmt.msc MMC Console. Minstens één interface toevoegen via de controlestructuur en General tabpagina invullen (max waarde hop-veld, vertragingsinterval). Locatie van DHCP-servers inbrengen door rechtermuisknop op DHCP Relay Agent controlestructuur > properties > General tabpagina invullen.

Vraag 3: Configuratie van DNS servers onder Linux (§3.3.2)
De figuur in bijlage stelt een intranet bestaand uit een aantal Linux ...(cfr.vraag B5)... achterhalen. Je hoeft geen reverse DNS te configureren.


  1. Stel het configuratiebestand en alle zonebestanden op van volgende DNS servers, waarbij je er rekening moet mee houden dat elk van deze servers ook secundaire nameserver is voor alle zones van de andere server: ... . Gebruik relatieve DNS namen waar mogelijk. Gebruik noch forwarders, noch de $ORIGIN opdracht !

  2. Bespreek in detail het begrip secundaire nameserver, inclusief voordelen, beperkingen en problemen. (§3.1 & §3.3.3) 

A) niet gevonden... is blijkbaar niet opgelost in de originele versies ?Die komt nog 2 keer terug in de volgende vragen dus is vrij belangrijk

B)

Naast primaire bestaan er ook secundaire nameservers, deze houden zelfde info bij als de primaire nameservers.



Voordelen: Verlichten taak primaire nameservers, zorgen voor verhoogde fouttolerantie. Als primaire uitvalt kan secundaire gepromoveerd worden (door netwerkbeheerder). Beperkingen:

wijzigingen van gegevens v/d zone worden enkel doorgevoerd bij de primaire nameserver  secundaire nameserver moet dus regelmatig contact opnemen met de primaire om een kopie van de nieuwe zone-informatie te verkrijgen.



Opm:

  • In het configuratiebestand van named is voor een secundaire nameserver de lijn allow-transfer { ip-adressen; }; verplicht bij options sleutelwoord.

  • Als men bij zone sleutelwoord als type slave gebruikt: named is secundaire nameserver voor opgegeven zone. masters lijn bevat één of meerdere ip-adressen van nameservers voor dit domein. file lijn bevat naam zonebestand, relatieve padnaam altijd t.o.v. dir opgegeven in options. Dit bestand wordt door server automatisch aangemaakt en bevat kopie van de zone-informatie v/h opgegeven domein  sec nameserv kan dus blijven werken als prim nameserv uitvalt. Daarom aanbevolen minimaal 2 nameservers te gebruiken voor elke zone.



Vraag 4: Configuratie van reverse DNS onder Linux

  1. Wat wordt beoogd met reverse DNS ? Hoe wordt dit gerealiseerd ? (§3.3.2)

  2. De figuur in bijlage stelt een intranet voor bestaand uit een aantal Linux computers. Alle computers hebben een interface op het gemeen­schappelijke 192.168.16/24 netwerk, met corres­ponderend IP-adres, van de vorm 192.168.16.z . Het getal z lees je af links van de naam van de computer. Alle computers hebben eveneens een interface op een 10.x.y/24 netwerk, met corres­ponderend IP-adres van de vorm 10.x.y.z . De getallen x en y lees je af rechts van de naam van de computer. De computers staan gegroepeerd in een tabel met als header de naam van het domein waarin ze zich bevinden. De recht­hoeken die domeinen groeperen stellen dan weer een zone voor. Stippel­lijnen duiden op een domein/sub­domein relatie. De pijlen laten toe om de primaire name­server van elke forward DNS zone te achter­halen. De reverse DNS van het 10/8 inter­netwerk wordt gedelegeerd aan ... . De reverse DNS van de 10.x/16 internetwerken (x≠0) wordt gedelegeerd aan: ... . De reverse DNS van de 10.x.y/24 netwerken (x≠0,y≠0) tenslotte wordt gedelegeerd aan de computers met IP-adres van de vorm 10.x.y.z, die reeds name­server van meerdere forward DNS zones zijn: ... . Geen enkele zone heeft een secundaire nameserver. Stel het configuratiebestand en de zonebestanden op van alle servers die een rol spelen bij de reverse DNS resolving van IP-adressen behorend tot netwerken ... en ... . Je hoeft hierbij enkel de configuratie informatie te vermelden die noodzakelijk is voor reverse DNS. Gebruik relatieve DNS namen waar mogelijk. Het gebruik van forwarders is hier niet toegelaten !

A)Reverse DNS = domeinnaam opzoeken voor een gegeven IP-adres. Meestal om beviligingscontrole uit te voeren. De DNS-records zijn van het type PTR.

Naam w.x.y.z? PTR-record opvragen van autoritaire server die deze informatie bevat, kennen domeinnaam machine niet  weten niet waar deze server te zoeken. Invoeren pseudo-domein: in-addr.arpa. Elk netwerkadres heeft een geassocieerde naam in dit speciale domein, naam = z.y.x.w.in-addr.arpa. We zoeken nu dus PTR record van deze naam. Hiërachische structuur van domein in-addr.arpa komt ongeveer overeen met die v/h netwerk.

Reverse DNS toelaten op machines eigen netwerk  primaire nameserver configureren voor overeenkomstige subdomein in-addr.arpa domein.

 Vb in cursus: toestellen iii.hogent.be allemaal in 192.168.16/24

#cat /var/named/192.168.16

SOA-record hetzelfde (behalve serienummer), PTR records. Alle namen in bestadn relatief t.o.v. 16.168.192.in-addr.arpa .Getallen in linkerkolom PTR records duiden op ip-adressen (relatief), namen rechterkant zijn absoluut.

 reverse DNS voor deel v/h loopbacknetwerk 127/8

#cat /var/named/named.local

kunnen ongewijzigd zonebestand gebruiken dat standaard tijdens de installatie van BIND software geconfigureerd wordt.

@ IN SOA localhost. Root.localhost. (

)

IN NS localhost.



1 IN PTR localhost.

B) niet gevonden

Vraag 5: Configuratie van DNS servers onder Linux

De figuur in bijlage stelt een intranet bestaand uit een aantal Linux computers voor, met corresponderend IP-adres, van de vorm 192.168.16.z . Het getal z lees je af links van de naam van de computer. De getallen rechts van de naam van de computer moet je negeren. De computers staan gegroepeerd in een tabel met als header de naam van het domein waarin ze zich bevinden. De rechthoeken die domeinen groeperen stellen dan weer een zone voor. Stippellijnen duiden op een domein/sub­domein relatie. De pijlen laten toe om de primaire name­server van elke zone te achterhalen. Geen enkele zone heeft een secundaire nameserver. Je hoeft geen reverse DNS te configureren.



  1. Stel het configuratiebestand en alle zonebestanden op van volgende DNS servers: ... . Gebruik relatieve DNS namen waar mogelijk. Gebruik noch forwarders, noch de $ORIGIN opdracht !

  2. Bespreek in detail het formaat van een zonebestand en zijn records. Je mag dit doen op basis van één van de oplossingen in a), doch je moet ook alternatieve records en formaten beschrijven, die je niet noodzakelijk hebt gebruikt. (§3.3.1 & §3.3.4)

B)

Named kan dienen als primaire server  autoriteit één of meerdere DNS-zones. Per zone een zonebestand (willekeurige naam, namen staan in configuratiebestand).

Elke lijn = afzonderlijk DNS-record (tenzij groeperen met haakjes).
Formaat: naam ttl IN recordtype waarde

Veld1:


  • naam machine of domein (mag ook spatie of tab zijn  naam vorige record).

  • Op verschillende manieren genoteerd:

    • Niet gekwalificeerde alfanumerieke naam: relatief t.o.v. domein

    • Naam eindigt op punt: absolute domeinnaam

    • Speciale naam @: verwijst naar huidige oorsprong, doorgaans enkel bij SOA record  oorsprong = huidige domein, $ORIGIN: oorsprong wijzigen

Veld2:

  • Time-to-Live (ttl): mag weggelaten worden, geeft aan hoelang DNS-record geldig is ( caching), weinig gebruikt want in SOA record default ttl-waarde.

Veld3:

  • IN (afkorting voor Internet): ook nog andere maar niet veel gebruikt

Veld4:

  • Type DNS-record: A, PTR, MX, SOA, NS, CNAME

Veld5:

  • Waarde DNS-record: ip-adres opgegeven naam(A), ip-adres mailserver (MX)

Commentaarlijnen worden voorafgegaan door ‘;’.

Het eerste record is een SOA-record (Start of Authority)  geeft begin records van bepaalde zone aan, in elk bestand maar één SOA-record als we per zone één zonebestand gebruiken. Formaat:


  • DNS-naam primaire nameserver (absoluut) gevolgd door e-mailadres v/ persoon verantwoordelijk voor server (‘@’ vervangen door ‘.’).

  • Volgnummer: gebruikt door secundaire nameserver  kijken als info nog synchroon is. Nummer telekns verhogen bij wijziging configuratiebestand. Conventie: 8 eerste cijfers = jaartal,maand,dag; laatste 2 = hoeveelste wijziging.

  • 4 tijdsduren: in seconden

    • refresh interval: #keer dat secundaire nameserver voor deze zone zijn database moet veranderen (1 à 2 keer per dag = voldoende).

    • Retry interval: hoelang sec. nameserv moet wachten om prim. nameserv opnieuw te contacteren na mislukte refresh

    • Expire interval: hoelang gegevens bewaren als refresh mislukt

    • Default ttl: mag grote waarde hebben (week of maand)

Na SOA-record meestal aantal NS-records. Deze sommen de namen op van alle primaire en secundaire nameservers van dit domein en al zijn gedelegeerde domeinen. Ook nameservers vermelden die zich buiten het domein bevinden!

Bij MX-record wordt voor de naam een prioriteit opgegeven  indien meerdere MX-records voor zelfde naam wordt laagste prioriteit gekozen.

CNAME-record om alias op te geven voor bepaalde DNS-naam. Alias mag enkel aan linkerkant van CNAME-definitie staan en niet aan linkerkant van andere definitie!  CNAME-records zoveel mogelijk vermijden en door A-records vervangen.

Het is mogelijk ip-adres aan meerdere namen te koppelen of meerdere ip-adressen aan zelfde naam te koppelen  cyclisch volgorde gebruikt  belastingdaling.


Subdomeinen:

  1. Subdomein hoeft geen eigen DNS-server te hebben  kan door DNS-server bovenliggend domein beheerd worden  domein en subdomein behoren dan tot zelfde zone. Men kan ip-adressen sub-domein dan gewoon toevoegen aan zonebestand hoger gelegen domein. Als ze alle behoren tot zelfde klasse-C netwerk  aangewezen ook reverse DNS door zelfde nameserver te beheren.

  2. Alternatief: subdomein delegeren door eigen zone met eigen nameserver. Hiervoor moet DNS-informatie bovenliggende domein aangepast worden  kan enkel door beheerder van dat domein! Vb.: lokaal 225 subdomein 225.iii.hogent.be met mozart nameserver van subdomein.

#cat >> /var/named/iii.hogent.be

225 IN NS mozart.225

mozart.225 IN A 192.168.16.142

Lijn1: vertelt iii.hogent.be dat mozart.225.iii.hogent.be nameserver is van subdomein 225.iii.hogent.be

Lijn2: geeft adres van deze nameserver, normaal vraagt de nameserver van iii.hogent.be alle adressen uit het gedelegeerd subdomein aan de nameserver van dit subdomein, maar voor de nameserver zelf (die ook deel uitmaakt van subdomein) kan dat uiteraard nog niet  A-record is een glue-record.

Opm:


  • DNS-aanvragen steeds vanaf root-servers naar beneden toe doorgegeven  enkel referenties naar subdomeinen in hoger liggende domeinen, niet omgekeerd! Vb.: in zonebestand 225.iii.hogent.be geen enkele referentie naar nameserver iii.hogent.be

  • Al dan niet delegeren reverse-DNS voor een subdomein is volledig onafhankelijk van forward-DNS.



Vraag 6: Configuratie van DNS servers onder Linux

De figuur in bijlage stelt een intranet bestaand uit een aantal Linux ...(cfr.vraag B5)... achterhalen. Geen enkele zone heeft een secundaire nameserver. Je hoeft geen reverse DNS te configureren.



  1. Stel het configuratiebestand en alle zonebestanden op van volgende DNS servers: ... . Gebruik relatieve DNS namen waar mogelijk. Gebruik noch forwarders, noch de $ORIGIN opdracht !

  2. Bespreek in detail het formaat van een configuratiebestand. Je mag dit doen op basis van één van de oplossingen in a), doch je moet ook alternatieve opdrachten en sleutelwoorden beschrijven, die je niet noodzakelijk hebt gebruikt. (§3.3.3)



B) Het configuratiebestand bevat basisinstellingen voor de serverdaemon en vermeldt ook de namen v/d zonebestanden: /etc/named.conf of /etc/named.boot (oudere toestellen).

Opdrachten bepaald door sleutelwoorden (zone en options zijn belangrijkste).


Options groepeert een aantal opties; elke optie bestaat uit sleutelwoord, parameters, afsluitende kommapunt.

  • directory padnaam; : dir waar zonebestanden zich bevinden

  • forwarders { ip-adressen; }; : lijst van ip-adressen waarnaar named zijn vraag zal richten als hij DNS-informatie niet in eigen cache vindt, als servers ook geen antwoord hebben  aanvraag aan root-servers. Is belastingverlagend voor root-servers.

  • allow-transfer { ip-adressen; }; : lijst van ip-adressen van computers die zone-transfer kunnen uitvoeren, bij ontbreken kunnen alle computers dit. Noodzakelijk voor secundaire nameservers en ls commando van nslookup. Ook netwarkadressen met prefixlengtesyntax.

Zone geeft informatie over verschillende zones waarvoor de geconfigureerde DNS-server moet instaan (primair of secundair). Na zone volgt naam zone tussen “” en eventueel gevolgd door in, tussen accolades bevindt zich de zone-specifieke configuratie-informatie.

  • type: geeft functie van de nameserver aan

    • master: named is primaire nameserver voor opgegeven zone. file lijn bevat naam zonebestand, relatieve padnaam altijd t.o.v. dir opgegeven in options. allow-update lijn (optioneel, ip-adres of netwerkadres/prefix) vermeldt computers die dynamische updates mogen uitvoeren. allow-transfer lijn hier heeft voorrang op deze bij options.

    • slave: named is secundaire nameserver voor opgegeven zone. masters lijn bevat één of meerdere ip-adressen van nameservers voor dit domein. file lijn is analoog. Dit bestand wordt door server automatisch aangemaakt en bevat kopie van de zone-informatie v/h opgegeven domein  sec nameserv kan dus blijven werken als prim nameserv uitvalt. Daarom aanbevolen minimaal 2 nameservers te gebruiken voor elke zone. Meerdere prim nameservs per zone kan maar afgeraden  inconsistentie.

    • stub: stub nameserver gedraagt zich zoals sec. nameserv maar dupliceert enkel NS records v/d opgegeven master servers.

    • forward: stuurt alle aanvragen door naar andere nameservers, ip-adressen vermeld in forwarders-lijn  in options (globaal voor server) of in zone (specifiek voor zone).

    • hint: altijd met zonenaam “.”, opgegeven bestand bevat lijst van root-servers die gebruikt worden door nameserver bij opstarten en slechts geraadpleegd wordt om namen van echte root-servers te vinden.

. 3600000 IN NS A.ROOT-SERVERS.NET.

A.ROOT-SERVERS.NET. 3600000 A 192.41.0.4



Als network niet is verbonden met Internet  configureer private root: zone en nameserver aanmaken voor “.” (met juiste subdomein info). Laat alle andere nameservers via /var/named/named.ca wijzen naar deze root.

  • Vraag 2
  • Vraag 3: Configuratie van DNS servers onder Linux
  • Vraag 4
  • Vraag 6: Configuratie van DNS servers onder Linux

  • Dovnload 74.98 Kb.