Jason: In deze les gaan we het
hebben over het domeinnaamsysteem, of DNS.
Het DNS-protocol wordt gebruikt om uw netwerkclients te helpen een website
te vinden met behulp van menselijk leesbare hostnamen
in plaats van numerieke IP-adressen.
Als ik je bijvoorbeeld zeg dat je mijn website moet bezoeken, kan ik gewoon
zeggen: "Hé, ga naar diontraining. com," en dat is veel gemakkelijker
te onthouden dan te moeten onthouden dat het
66 is. 123. 45. 237, of wat
het IP-adres van mijn webserver ook mag zijn.
Het zeggen van al die nummers als onderdeel van een tv-commercial
is immers niet zo pakkend of memorabel als vertellen dat je consument
diontraining moet bezoeken.
com, of coca-cola. com
of microsoft. com, toch?
Dus hoe weet de computer hoe hij het IP-adres
van de webserver moet vinden aan de hand
van deze verschillende domeinnamen?
Dat is het doel van DNS, het domeinnaamsysteem.
De manier waarop DNS werkt is dat de computer van de gebruiker de opdracht krijgt om naar
een plek als diontraining te gaan. com, dus het bereikt
een DNS-server en zegt, "Hé, wie is
diontraining. com? En de DNS-server antwoordt
dan terug en zegt: "Oh, ik ken diontraining.
com.
Het IP-adres is 66 punt iets, punt
iets, punt iets. Vervolgens wordt de client omgeleid
naar een webserver met behulp van hun router en hun weg
naar de verbinding, omdat ze nu het juiste IP-adres weten
om te gebruiken als hun bestemming,
en dit gebeurt allemaal op de achtergrond voor jouw
gebruikers en jouw computer zonder dat iemand
er echt om hoeft te vragen, omdat DNS zo'n ingebed
onderdeel is van onze netwerken en systemen.
Nu zullen de meesten van ons als thuisgebruikers geen
eigen DNS-servers draaien, maar vertrouwen
we op onze internetproviders om dit voor ons te doen.
Maar als je je eigen websites of ons grote
bedrijfsnetwerk beheert, heb je misschien ook
je eigen DNS-server in je netwerk en ben je verantwoordelijk
voor het instellen van je eigen
DNS-records die bepalen welke servers
zich op welke IP-adressen bevinden en voor welke doeleinden.
Hiermee kun je je eigen domeinnaam- en
hostresolutie uitvoeren, die deze domeinnamen omzet
naar IP-adressen.
Als je het zo wilt zien, is het
vergelijkbaar met een lijst met contactpersonen op je telefoon.
Hoeveel telefoonnummers ken jij tegenwoordig uit je hoofd?
Waarschijnlijk niet veel, toch?
Want normaal gesproken haal je je smartphone tevoorschijn,
scrol je naar de naam van de persoon en druk je met je vinger
op zijn naam, waarna de telefoon hem belt.
Als ik bijvoorbeeld mijn vrouw wil bellen, scroll ik naar haar naam,
druk ik een foto van haar gezicht op mijn telefoon
en belt mijn telefoon onmiddellijk haar nummer.
Ik hoef niet alle 10 cijfers van haar telefoonnummer te onthouden,
want dat doet mijn telefoon voor me.
Dat komt omdat we het als mensen moeilijker
hebben om nummers te onthouden dan namen, en dus doen we deze gezichts-
of naam-naar-nummer conversie met behulp van onze contactpersonenlijst.
Het is hetzelfde voor computers, behalve
dat computers eigenlijk veel meer van getallen
houden dan van namen, dus we willen de domeinnamen die makkelijker
voor ons zijn omzetten in IP-adressen die makkelijker zijn voor computers
om hun routering mee te doen, en dat is eigenlijk alles wat
DNS voor ons doet.
Het converteert namen naar nummers en nummers naar namen.
Een van de concepten van DNS waar
we het over moeten hebben is
de zogenaamde volledig gekwalificeerde domeinnaam, of FQDN.
Dit is wanneer een domeinnaam onder een toplevelprovider valt.
De meest voorkomende top level provider is bijvoorbeeld . com, maar we hebben ook dingen
zoals . molen, . edu, . org, . net.
Laten we het voorbeeld van Dion Training gebruiken.
Bij Dion Training hebben we veel verschillende servers.
Een van onze servers is onze webserver
en deze bevindt zich op www. diontraining. com.
Het topleveldomein is hier . com.
De domeinnaam die ik gebruik is Dion Training.
Om volledig gekwalificeerd te zijn, moet ik er WWW voor zetten.
Dit maakt het www. diontraining. com.
Als je naar mijn webserver
wilt gaan, typ je www. in je
browser. diontraining. com, en nu word je doorgestuurd
naar mijn webserver, omdat DNS weet hoe het IP-adres van mijn
webserver moet draaien met die volledig
gekwalificeerde domeinnaam.
Als je in plaats daarvan naar mijn bestandsserver wilt gaan,
moet je ftp intypen. diontraining. com, omdat dat de
server is die ik daar draai.
Als je naar mijn mailserver wilt
gaan, typ je mail. diontraining. com.
Dit zijn alle drie voorbeelden
van volledig gekwalificeerde domeinnamen of FQDN's.
In wezen is er een service, een punt, een domeinnaam,
een punt en een topleveldomein en dit werkt op dezelfde
manier, ongeacht naar welk
domein je op internet kijkt.
DNS wordt nu ingesteld als een hiërarchie.
Dit gebeurt op vijf verschillende niveaus.
We hebben het routeniveau, het topleveldomein,
de domeinen op het tweede niveau, subdomeinen en de host.
Het routeniveau is het hoogste niveau
in de DNS-hiërarchieboom en de routenameserver
gaat verzoeken in de routezone beantwoorden.
Deze servers bevatten de globale lijst
van alle topleveldomeinen, zoals. com,. net, . org, . molen en anderen.
Het tweede niveau naar beneden zijn de topleveldomeinen.
Deze zijn onderverdeeld in twee categorieën, organisatorische
hiërarchieën zoals . com, . net, . org, en anderen, en dan de
geografische
hiërarchie zoals . uk voor het Verenigd Koninkrijk, . fr voor Frankrijk,. voor Italië en andere landen.
Het derde niveau lager staat bekend als second level domains.
Deze domeinen staan direct onder het topleveldomein.
Mijn domein Dion Training is bijvoorbeeld
een domein op het tweede niveau onder de . com topleveldomein.
De . com zit onder het routedomein.
Dit is de manier waarop deze dingen samen opklimmen
als onderdeel van de hiërarchie.
Het vierde niveau naar beneden staat bekend als het subdomein,
dus als ik een nieuwe server zou willen maken
onder mijn domein van het tweede niveau, diontraining. com, kan ik dat doen met een
subdomein.
In mijn geval heb ik veel verschillende
subdomeinen voor verschillende doeleinden.
Ik heb mijn hoofdwebsite gehost op het www-subdomein,
dus je typt www in. diontraining. com, en dat brengt
je naar mijn webserver, maar ik heb er ook een die support
heet.
Nu bevindt het support-subdomein
zich op support. diontraining. com.
Ik heb er nog een voor mail, mail. diontraining. com.
Dit zijn allemaal verschillende subdomeinen.
Het vijfde en laatste niveau naar beneden is het hostniveau.
Dit is het laagste en meest gedetailleerde
niveau binnen de DNS-hiërarchie en verwijst naar een specifieke
machine of server op het netwerk.
Als we echter aan DNS denken, denken
de meesten van ons aan zoiets als een volledig
gekwalificeerde domeinnaam,
iets als www. diontraining. com, dat een subdomein, een domein op
het tweede niveau en een domein op het hoogste
niveau bevat.
Als ik nog een stapje verder wil gaan, kan ik het bekijken vanuit
het perspectief van een URL, die bekend staat
als een uniform resource locator.
Nogmaals, laten we mijn webserver
als voorbeeld nemen, www. diontraining. com.
Dat is mijn volledig gekwalificeerde domeinnaam, maar het
vertelt je niet hoe je er toegang toe krijgt.
Wil je dit veilig of onveilig doen?
Nou, dat zul je moeten zien door de URL te doen.
Als je me je gebruikersnaam en wachtwoord
wilt geven, moet je dit veilig doen.
Dus je voegt HTTPS://
toe voor www. diontraining. com, en dat wordt een URL, een
uniform resource locator, omdat het je vertelt hoe je toegang krijgt
tot diontraining. com's webserver.
Daarom hebben we die HTTPS aan het begin.
Het is het hyper text transfer protocol
secure, en dat is de methode om er toegang toe te krijgen.
Als je nu mijn website wilt bezoeken en dat op een onveilige manier
wilt doen, kun je dat doen door HTTP:// toe te voegen
aan het begin van het webadres.
Als je nu verbinding wilt
maken via FTP, gebruik je FTP://FTP. diontraining. com als je URL, en zo zijn er veel verschillende manieren om dit te doen als
je het systeem vertelt wat het moet
doen, en dat zal een URL en een
volledig gekwalificeerde domeinnaam
creëren.
Vervolgens moeten we het hebben over de verschillende
soorten DNS-records die bestaan binnen een DNS-server.
Binnen je DNS-server ga je verschillende
records aanmaken die verschillende soorten informatie bevatten op
basis van je gebruikssituatie.
Deze staan bekend als A-records, AAAA-records, CNAME-records, MX-records,
TXT-records en NS-records.
Laten we eens kort kijken naar elk van deze
verschillende recordtypes.
Ten eerste hebben we een
A-record, wat staat voor een adresrecord.
Een A-record wordt gebruikt om een
hostnaam aan een IPv4-adres te koppelen.
Er is bijvoorbeeld een A-record voor www. diontraining. com en koppelt dit aan het
IP-adres van 45. 79. 184. 180.
Daarnaast kun je ook een A-record instellen voor de
@ host, en dit geeft een record
voor het routedomein aan.
In het voorbeeld van Dion Training betekent
ons @ record dat diontraining. com, de route van ons domein, wordt
weergegeven op een bepaald
IP-adres.
Op deze manier kunnen onze gebruikers onze website vinden
door naar het subdomein www. diontraining. com, of gewoon door
naar diontraining te gaan. com door dat A @ record te gebruiken.
Nu werken A-records alleen voor IPv4-adressen,
maar veel moderne websites ondersteunen ook IPv6.
Om een domeinnaam aan een IPv6-adres
te koppelen, gebruik je een AAAA-record.
Dus met de site van Dion Training als voorbeeld,
zou ik het AAAA record kunnen instellen op 2400:cb00:2049:1::a29f:1804
als dat het IPv6 adres voor mijn webserver was.
Zoals je kunt zien, zijn IPv6-adressen veel ingewikkelder
dan IPv4 en heel moeilijk te onthouden voor
ons mensen.
Daarom gebruiken we graag deze AAAA-records
of 4A-records.
Het volgende type record dat we kunnen gebruiken staat bekend als een CNAME-record,
oftewel een canoniek naamrecord.
Nu wordt een CNAME-record gebruikt in plaats
van een A-record voor een AAAA-record als je een domein naar een andere
domeinnaam of een subdomeinnaam wilt verwijzen.
Ik bezit bijvoorbeeld veel verschillende
domeinnamen naast diontraining. com.
Sommige hiervan zijn voor voormalige bedrijven die ik had of projecten
die ik runde, en andere
ben ik van plan ooit in de toekomst te gebruiken,
maar in de tussentijd heb ik ze ingesteld met een CNAME-record
dat terugverwijst naar diontraining. com.
Ik had bijvoorbeeld een website genaamd itil4exam. com, maar sindsdien gebruik ik
die domeinnaam niet meer
en heb ik al die cursussen samengevoegd
in mijn eigen diontraining. com website.
Dus toen ik die oude webserver uitschakelde, wilde ik mensen nog
steeds toestaan om itil4exam in te typen. com en iets bereiken in
plaats van alleen een foutpagina.
Dus heb ik een CNAME record gebruikt
om het direct naar diontraining te laten verwijzen. com.
Waarom zou ik dat willen doen?
Nou, we waren een paar jaar op de andere
site, parallel aan diontraining. com, en veel van de links die
daar staan, staan overal op het internet met aanbevelingen
voor onze cursussen die
op dat itil4examen werden gehost. com website.
Een van onze populairste cursussen van die site
was onze ITIL 4 Foundation-cursus,
die te vinden was op itil4exam. com/itil-4-stichting.
Als je dat in je webbrowser typt,
wordt het itil4examen opgelost. com naar diontraining. com en brengt je rechtstreeks
naar diontraining. com/itil-4-stichting.
Dit betekent dat zelfs als je een
link gebruikt die je hebt gevonden op Reddit en die onze cursus
van een paar jaar geleden aanbeveelt, deze nog
steeds werkt en je naar onze verkooppagina brengt,
ook al is het originele itil4exam. com server is zelfs niet meer in
gebruik en is offline gehaald.
Een andere toepassing voor het gebruik
van een CNAME-record is wanneer je een software-as-a-service
gebruikt die je een subdomein op hun server geeft.
Ik gebruik bijvoorbeeld een service desk
ticket tracking software die Freshdesk heet. com, en ze gaven ons een nogal
moeilijk te onthouden subdomein voor
hun service, zoiets
als FDUS-143-D15. freshdesk. com.
Dus om het voor mijn medewerkers
makkelijker te maken om onze supportdesk te vinden,
maken we een CNAME-record aan met de naam Support en verwijzen dat naar dit moeilijk te onthouden subdomein.
Dus als mijn personeel ondersteuning invoert. diontraining. com, brengt ze rechtstreeks naar ons ondersteuningssysteem,
dat ons eigenlijk doorverwijst naar deze cloud-instantie die wordt
geleverd door het subdomein
dat door Freshdesk is uitgegeven.
Onthoud dat CNAME-records niet kunnen worden
gebruikt om naar een IP-adres te verwijzen.
Het kan alleen worden gebruikt om naar een andere domeinnaam
of subdomeinnaam te verwijzen.
Vervolgens hebben we een
MX-record, wat staat voor mail exchange record, en het
doet wat je denkt dat het zou doen.
Het helpt je uit te zoeken waar een e-mailserver zich bevindt.
Een MX-record wordt gebruikt om e-mails naar uw mailserver te leiden.
MX-records kunnen net als CNAME-records alleen worden
gebruikt om naar een ander domein te verwijzen en niet naar een IP-adres.
Wanneer je je MX-records aanmaakt, kun je
ook de prioriteit voor elk van deze records
opgeven.
Hiermee kun je je voorkeur aangeven voor
welke server de e-mail eerst moet proberen te gebruiken.
Bij het instellen van de prioriteit
geldt: hoe lager het getal dat je invoert, hoe hoger de
prioriteit.
Het zijn in wezen golfregels.
Dus als we mail1. diontraininf. com ingesteld
op 10 en mail2. diontraining. com ingesteld op 20 voor hun prioriteiten, proberen de e-mails
eerst mail één te gebruiken.
Als het niet lukt om mail
één te bereiken, dan zal het proberen mail twee te bereiken.
Als je nu je e-mail wilt verdelen over
meerdere servers, hoef je alleen maar hun prioriteiten
op dezelfde waarde in te stellen.
Dus als ik records heb aangemaakt voor
mail één en mail twee, en ze hebben allebei prioriteit 10, dan zullen
alle inkomende e-mails elkaar afwisselen en gelijkmatig worden
verdeeld over deze servers.
De eerste gaat naar één, de tweede gaat
naar twee, de derde gaat naar één, de
vierde gaat naar twee, enzovoort.
Vervolgens hebben we TXT-records, of tekstrecords.
Nu wordt een tekstrecord gebruikt door domeinbeheerders
om tekst toe te voegen aan het domeinnaamsysteem, of DNS.
Oorspronkelijk werden tekstrecords ontworpen
als een manier voor ons om menselijk leesbare notities toe te voegen
aan onze DNS-records, en na verloop van tijd werden
er steeds meer dingen toegevoegd aan deze tekstrecords,
en uiteindelijk begonnen we ook machineleesbare
gegevens toe te voegen aan deze tekstrecords, en dat
is wat je tegenwoordig meestal zult zien.
Je domein kan ook veel verschillende
tekstrecords hebben.
Je bent niet beperkt tot slechts één van hen.
Meestal worden tekstrecords gebruikt
om domeineigendom aan te tonen door machine-leesbare
code toe te voegen ter verificatie en om e-mailspam te voorkomen,
ook weer door specifieke machine-leesbare code
toe te voegen aan een TXT-record.
Bijvoorbeeld bij diontraining. com hebben we een tekstrecord
met de naam fdkey. ondersteuning en een structuur van 32 hexadecimale
cijfers in onze
DNS-records.
Hierdoor kan ons supportsysteem Freshdesk verifiëren dat wij de eigenaar
zijn van de domeinnaam diontraining. com, dus zij zijn gemachtigd om namens
ons e-mails te versturen naar onze studenten wanneer
ons team in hun systeem antwoordt
op een supportticket.
Dit is een vorm van verificatie van domeineigendom,
omdat hun systeem onze DNS-records kan opvragen en kan
zien dat we deze unieke reeks van 32 hexadecimale cijfers
hebben ingevoerd in ons DNS TXT-record.
In wezen werkt het als een wachtwoord
om te zeggen: "Hé, ik ben de eigenaar van dit domein. In je TXT-records kun je ook informatie opnemen zoals SPF-, DKIM- of
DMARC-berichten om je e-mailservices
te helpen verifiëren en de verzending
van gespoofde of ongewenste berichten, bekend
als spam, naar andere mensen die je domein en e-mailadressen gebruiken, te blokkeren.
SPF, of het sender policy
framework, is een DNS record dat de host identificeert
die geautoriseerd is om mail te versturen voor
het domein, en er is er maar één
toegestaan voor elk domein.
Als je ze bekijkt, zul je iets hebben dat er
zo uitziet, en dit is een DNS-record dat een tekstrecord
wordt genoemd.
Je zult zien dat het het @ teken heeft
en dan V=SPF1, wat sender policy framework one is.
Het is de eerste.
Dan staat er MX, wat het mailserverrecord is, en
dan staat er include:_SPF. google. com, en vermeld:e-mail.
freshdesk. com-all.
Wat vertelt dit jou?
Nou, dit is eigenlijk het SPF-record voor mijn e-mailserver.
Waarom hebben we google? com daar?
Nou, dat komt omdat we G Suite van Google gebruiken en Google dus onze
e-mailprovider is.
We hebben geen eigen e-mailserver.
In plaats daarvan laten we ze dat doen en hebben we ze toestemming
gegeven om dat te doen, dat ze gemachtigd
zijn om namens ons e-mail te versturen door
die SPF-verklaring op te nemen.
De tweede daar vraag je je misschien
af: "Waar is dat voor?
Ik dacht dat je er maar één kon hebben. Nou, je kunt maar één
SPF-verklaring hebben, maar dit hele
ding is één regel als het in DNS wordt
geschreven, en dit hele ding van tekst helemaal naar alles
is één enkele regel, en dat is één enkele SPF-verklaring.
Ik kan meerdere servers machtigen om namens mij te verzenden,
maar ik kan het alleen doen in één DNS-regel zoals je hier ziet,
en wat Freshdesk is, is ons trouble ticket-systeem.
Als u een e-mail stuurt naar de supportafdeling van Dion Training,
gaat deze naar Freshdesk, maar als u een e-mail
stuurt naar mijn persoonlijke e-mail
bij Dion Training, gaat deze naar
Google, omdat dat onze persoonlijke e-mails voor ons bedrijf
zijn, en dus moet u beide
e-mailadressen opnemen in alles wat namens u wordt verzonden
in deze verklaring.
Het volgende waar we het over moeten hebben is DKIM, of dkim.
Dit is domein sleutels geïdentificeerde mail.
Dit biedt een cryptografisch authenticatiemechanisme voor mail met behulp van een openbare
sleutel die wordt gepubliceerd als een DNS-record.
Als je nu een SPF of DKIM opzoekt,
zie je zoiets als dit.
Hier is een voorbeeld van de mail voor adobe. com.
Je ziet DMARC bovenaan, waar
we het zo over zullen hebben, je ziet
SPF, waar we het net over hebben
gehad, en dan zie je DKIM,
waar we het nu over hebben.
Het is eigenlijk een hele lange cryptografische
authenticatiesleutel, die je op het scherm kunt zien.
DKIM kan nu SPF vervangen of samen met SPF worden gebruikt.
De volgende waar we het over gaan
hebben is DMARC, en DMARC is de domain-based message authentication
reporting and conformance.
Dit is in feite een raamwerk, en dit raamwerk wordt gebruikt
om de juiste toepassing van
SPF en DKIM te garanderen met behulp
van een beleid dat wordt gepubliceerd als een DNS-record,
en ik heb je dat heel kort laten zien in de laatste afbeelding
op je scherm toen ik je de DMARC liet zien op de bovenste
regel van die afbeelding.
Als je terug wilt gaan en daarnaar wilt
kijken, dan kan dat op dit moment.
Als je te maken hebt met DMARC,
kun je dit gebruiken met SPF,
met DKIM of met beide, want
vergeet niet dat SPF en DKIM niet samen hoeven te worden gebruikt.
Je kunt het een of het ander gebruiken,
of je kunt beide gebruiken en DMARC wordt gebruikt met een van de twee of met beide.
Als je nu met MARC werkt,
ziet het er zo uit.
Hoe werkt dit allemaal samen?
Eerst moet je ervoor zorgen dat SPF, DKIM
en DMARC allemaal op de DNS-server staan.
Zodra je al die gegevens hebt,
begint het hele proces.
Als je dat eenmaal hebt gedaan,
volgt al het andere elke keer dat je een bericht
wilt sturen.
In dit voorbeeld worden er twee berichten
verzonden, één van de SMTP server, die geautoriseerd
is en groen wordt weergegeven, en één van een tegenstander
die je domein probeert te spoofen,
die rood wordt weergegeven.
Laten we beginnen met degene die geautoriseerd is.
Hier staat het vermeld als 2A.
Je verzender stuurt dat bericht naar de MTA.
Het gaat naar de MTA, wat je
message transfer agent is, en die neemt uiteindelijk
dat bericht aan met de SPF of DKIM header erin.
Laten we even bij deze boodschap blijven
en dan terugkomen op de tegenstander.
Zodra de MTA dat bericht heeft, gaat
het verder en bekijkt het dat
bericht en verwerkt het.
Wanneer het dat doet, zal een deel daarvan het
DMARC-beleid van de afzender
en de SPF- en DKIM-records opzoeken via DNS, net zoals
we in de laatste drie of vier minuten hebben besproken.
Als de MTA dat eenmaal heeft gedaan en het is legitiem,
dan kan dat bericht in de mailbox van de ontvanger
op de IMAP server worden geplaatst en wachten tot de persoon het bericht kan
lezen met behulp van zijn mail user agent.
Dat is allemaal goed, want ze weten dat dit bericht authentiek
was, omdat het die waarden vergeleek met SPF, DKIM of DMARC,
gebaseerd op het beleid
dat was ingesteld.
Als we nu kijken naar de tegenstander aan de andere kant, dan gaat
het bericht nog steeds naar de MTA, omdat het naar de MTA moet om bij de
eindgebruiker te komen.
Maar zodra het daar aankomt, controleert de MTA
het aan de hand van het DMARC-beleid en kijkt daarbij naar de SPF- of
DKIM-records.
Als dat gebeurt en ze komen niet overeen, dan wordt
het bericht geweigerd, verwijderd of in quarantaine
geplaatst en weggegooid, zoals
je kunt zien in 5B.
Nogmaals, dit is de manier waarop deze dingen werken en door
DKIM, DMARC en SPF samen te gebruiken, kunnen we
wat beveiliging toevoegen aan onze organisaties.
Tot slot hebben we een NS-record, wat
staat voor nameserverrecord.
Nu wordt een nameserverrecord gebruikt om aan
te geven welke DNS-naamserver in de wereld de
gezaghebbende wordt voor dat domein.
Dit is belangrijk omdat DNS dat hiërarchische model
gebruikt waar we het over hadden, en alle servers
moeten weten wie de eigenaar van dat record is en gemachtigd
is om wijzigingen aan te brengen.
Een nameserver is een type DNS-server die alle DNS-records
voor een bepaald domein opslaat, inclusief
alle types die we al hebben besproken, zoals A-records,
AAAA-records, canonieke naamrecords, MX-records voor mailuitwisseling en
TXT-tekstrecords.
Er zijn vaak ook meer dan één nameserver voor een domein, dus
je kunt een primaire en een back-up nameserver hebben.
Bovendien hoeft u niet altijd
uw eigen nameservers te hosten.
In het geval van diontraintraining. com, we hosten onze eigen
nameservers niet.
In plaats daarvan vertrouwen we
op Cloudflare, een cloudserviceprovider die dit voor ons doet.
Dus als je de DNS-records voor diontraining. com, de gezaghebbende bron
daarvoor zijn twee van Cloudflare's
nameservers.
Tot nu toe heb ik het gehad over DNS vanuit het perspectief
van het hosten van een publiek beschikbare
DNS server waar iedereen ter wereld toegang toe heeft, maar
DNS kan eigenlijk intern of extern
gebruikt worden.
Alles waar ik het tot nu toe
over heb gehad, gaat over extern, maar laten we het
eens over intern hebben.
Tegenwoordig is het bij cloud computing heel gebruikelijk
om ook een interne DNS-service op
te zetten waarmee je cloudinstanties
binnen hetzelfde netwerk of private cloud elkaar kunnen bereiken via interne
DNS-namen in plaats van via hun IP-adressen.
Om dit te doen, worden interne A-records aangemaakt en worden
er ook interne pointerrecords aangemaakt
in de omgekeerde zone.
Gelukkig zullen de meeste cloudaanbieders deze interne
DNS-records automatisch voor je aanmaken,
bijwerken en verwijderen wanneer je verschillende virtuele machines en andere
instanties in je private cloud aanmaakt en verwijdert.
De meesten van ons zullen echter
meer bekend zijn met extern DNS.
Dit zijn de records die worden aangemaakt rond de domeinnamen
die we kopen van een centrale autoriteit
en die we gebruiken op het openbare
internet.
Voor elk DNS-record hebben we ook
een zogenaamde TTL, of time to live, die eraan gekoppeld is.
De time to live is een instelling die de DNS-oplosser vertelt
hoe lang hij een query kan cachen voordat hij een nieuwe query aanvraagt.
Dus als mijn DNS-records zijn ingesteld met
een time to live van 86.400 seconden, wat meestal de
standaard is, betekent dit dat mijn computer
dat DNS-record omzet en het 24 uur lang onthoudt voordat het
opnieuw naar de DNS-server moet gaan om die informatie
op te vragen.
Deze DNS-resolver, ook wel DNS-cache genoemd,
bevindt zich op je eigen host.
Dus als je bijvoorbeeld Windows 10 gebruikt, maakt je computer een lokale
kopie van elke DNS-vermelding die
wordt omgezet wanneer je verbinding maakt met websites
over het hele internet.
Deze tijdelijke database onthoudt
de antwoorden die het van de DNS-server heeft ontvangen.
Dus als je naar diontraining gaat. com, de eerste keer dat je dat vandaag doet, moet je
computer de DNS-server om dat
IP-adres vragen,
maar nu weet hij waar het is en onthoudt
hij dat IP-adres voor de komende 24 uur.
Als je mijn website vandaag vijf keer bezoekt,
hoefde je dat IP-adres maar één keer op te zoeken.
Dit helpt het hele proces voor ons te versnellen.
Als je het morgen opnieuw probeert, zal je computer
eerst de DNS-cache controleren en zien dat er
een record is.
Maar als die tijd om te leven al voorbij is,
wordt die record ongeldig gemaakt
en wordt er opnieuw gezocht.
Het laatste dat we moeten behandelen
is het concept van een recursieve lookup.
Als uw computer een bepaalde website
zoals diontraining. com, moet het eerst zijn DNS-server
vragen waar het zich bevindt.
Dus als je thuis zit
en bijvoorbeeld een Verizon Fios-verbinding gebruikt,
vraag je hun DNS-server:
"Who's diontraining. com? De DNS van Verizon kent al dan niet het IP-adres
voor diontraining.
com.
Er zijn immers miljoenen en miljoenen websites en als ze onze records
elke 24 uur opnieuw zouden moeten
synchroniseren, zou dat lang duren.
In plaats daarvan gebruikt DNS deze
recursieve strategie om het opzoeken uit te voeren.
Dus je vraagt het aan Verizon en als zij het antwoord niet weten, gaan ze een niveau hoger en vragen
ze het aan de volgende DNS-server.
Als die server het antwoord niet weet, gaat hij een niveau
hoger en gaat hij door tot hij iemand vindt die het
IP-adres van diontraining
kent. com.
Als het tijdens deze recursie
helemaal tot aan de . com of het routedomein voor diontraining. com, dan kan
het de . com routeserver welke DNS-server gezaghebbend
is voor diontrain. com en krijg direct van hen
het juiste antwoord.
Met een recursieve lookup zegt
je DNS-resolver eigenlijk: "Ik weet niet wat het
IP van dit domein is, maar ik ga het
aan mijn DNS-server vragen en
die server zoekt het op totdat hij het
vindt en vertelt me dan dat IP. Er is nog een andere methode die gebruikt
kan worden, die bekend staat als een iteratieve
lookup.
Met een iteratieve lookup is het vergelijkbaar
met een recursieve lookup, behalve dat de DNS-server
de informatie niet voor je blijft opzoeken en je het resultaat stuurt.
In plaats daarvan zal je DNS-oplosser bij een iteratieve
opzoeking aan de DNS-server vragen wat het IP-adres voor het
domein is en als de DNS-server het niet
weet, zal hij je oplosser vertellen om het aan de volgende
DNS-server te vragen en die server zal
het IP-adres leveren.
Bij een recursieve zoekopdracht zal de DNS-server
het opsporen en rapporteren aan de
resolver, maar bij een iteratieve
zoekopdracht zal je DNS-resolver
deze zoekopdracht blijven uitvoeren, helemaal
tot aan de recursie, totdat hij degene vindt met het IP voor dat domein.
Oké, we hebben veel informatie behandeld in deze
les, dus een korte samenvatting:
wat moet je weten voor het examen?
Je moet begrijpen hoe DNS werkt door de verschillende recordtypes
te gebruiken om domeinnamen om te zetten naar IP-adressen
en IP-adressen naar domeinnamen.
Je moet onthouden dat A-records worden gebruikt voor domeinnamen
met IPv4-adressen, terwijl AAAA-records worden gebruikt
voor domeinnamen met IPV6-adressen.
CNAME-records worden gebruikt om domeinnamen aan
andere domeinnamen te koppelen.
MX records worden gebruikt voor e-mail en NS records
worden gebruikt voor nameservers.
TXT-records slaan tekst op als menselijk
leesbare of machinaal leesbare gegevens.
Als je deze samenvatting onthoudt, zou je in staat moeten zijn om vrijwel
alle DNS-vragen te beantwoorden die je op
het examen zult tegenkomen.