[2003] Wat is een stub zone in dns*

[Bas]

Wat is eigenlijk precies een stub zone. Volgens mij is het een secundairy zone met alleen name servers erin... maar wat doet het dan? forward deze alle requests naar een primairy zone of ed?

Ik heb ff gegoogled en op http://www.microsoft.com/...p?frame=true&hidetoc=true
gekeken..

[elevator]

Even een kleine titel edit om dit wat beter in context te plaatsen
Wat snap je niet aan de uitleg die je zelf linkt?

[ Voor 29% gewijzigd door elevator op 31-01-2005 21:30 ]

[Anoniem: 19339]

Wat het doet? Stel dat je 2 dns-zones hebt bij verschillende bedrijven, zeg A en B. Als A nu een stub zone van B heeft, dan zal een query die bij A aankomt (uit het eigen bedrijf, zeg maar) met betrekking tot een resource uit B, doorgestuurd worden naar de nameservers van B.

Het voordeel boven secondary zones (of AD integrated zones) is dat een stub zone maar uit een handjevol records bestaat, en er dus vrijwel geen replicatie-verkeer is.

Zie ook http://www.windowsnetwork...rials/DNS_Stub_Zones.html

[ Voor 9% gewijzigd door Anoniem: 19339 op 01-02-2005 12:16 ]

[Berimbau]

Een stubzone kan je gebruiken in de situatie die jij net schetst. Twee bedrijven A en B gaan bv samenwerken/fuseren maar beide beherende partijen willen niet dat er in elkaars naamresolutie wordt gerommeld. Een stubzone maakt het dus mogelijk dat bedrijf A de meest recente info heeft van bedrijf B en andersom zonder dat het beheer door elkaar loopt.

[Anoniem: 57365]

30 mins course: http://support.microsoft....est.xml&WMPVer=8.0.0.4491

[Anoniem: 57365]

Anoniem: 19339 schreef op dinsdag 01 februari 2005 @ 12:15:
Wat het doet? Stel dat je 2 dns-zones hebt bij verschillende bedrijven, zeg A en B. Als A nu een stub zone van B heeft, dan zal een query die bij A aankomt (uit het eigen bedrijf, zeg maar) met betrekking tot een resource uit B, doorgestuurd worden naar de nameservers van B.

Het voordeel boven secondary zones (of AD integrated zones) is dat een stub zone maar uit een handjevol records bestaat, en er dus vrijwel geen replicatie-verkeer is.

Zie ook http://www.windowsnetwork...rials/DNS_Stub_Zones.html

maar dat betekent niet dat je weinig netwerk verkeer hebt. als je regelmatig records van B moet opvragen is een secondaire zone misschien wel minder netwerkverkeer...

Je kan stubzones beter vergelijken met een conditional forwarder, het voordeel van stubzones is echter dat de soa records geupdate worden, zodat als je de dns servers van B wijzigt, je geen wijzigingen op A hoeft te maken...

[Anoniem: 23534]

In de voorgaande replies gaf men al een aantal belangrijke punten aan:
- Een stub zone is slechts een wegwijzer (heeft zelf geen adres records), het kan dus niet als een soort buffer of cache dienen, wat een secondary zone wel kan. Dat wil zeggen dat een computer met alleen de secondary zone al namen op kan lossen voor clients. Bij een stub zone verwijst de stub zone naar de "echte" DNS server, zodat je nog steeds veel verkeer tussen clients en de "echte" DNS server hebt.
- Daar staat tegenover dat je op de primary zone niet hoeft in te stellen dat je zonetransfers toelaat. Het toelaten van zonetransfers staat in W2k3 standaard uit vanwege potentiele beveiligingsproblemen.

Samengevat doet een stub zone tot op zekere hoogte hetzelfde als een secondary zone, maar dan zonder de "caching" effecten maar je hoeft je "echte" DNS server niet open te zetten qua zone transfers.

[Anoniem: 113748]

Maar de stub zone slaat dus ook niks op in zijn cache als er b.v. een query wordt opgehaald bij de "echte DNS Server"? Dat wil dus zeggen dat ALLE query's afgehandeld worden door de "echte server" en er niks in de cache van de stub zone wordt opgeslagen?

[Question Mark]

Ja Geresolvde entry's worden echter wel in de cache bewaard, niet in de zone.

[ Voor 89% gewijzigd door Question Mark op 07-06-2006 11:59 ]

[Anoniem: 113748]

Maar dan snap ik waarom niet want als je dit gelijk in je cache opslaat dan handelt de stub zone toch alleen maar sneller alle query's af?

[Question Mark]

Anoniem: 113748 schreef op woensdag 07 juni 2006 @ 11:34:
Maar dan snap ik waarom niet want als je dit gelijk in je cache opslaat dan handelt de stub zone toch alleen maar sneller alle query's af?

JE hebt gelijk, geresolvde entry's worden door de (lokale) DNS-server wel gecached.

Wanneer een DNS-client een recursieve query uitvoert op een DNS-server die host is van een stub-zone, gebruikt de DNS-server de bronrecords in de stub-zone om de query op te lossen. De DNS-server verstuurt een iteratieve query naar de bevoegde DNS-servers die zijn opgegeven in de NS-bronrecords van de stub-zone. De bewerking wordt uitgevoerd alsof het NS-bronrecords in de eigen cache betreft. Als de DNS-server de DNS-servers met autoriteit in de stub-zone niet kan vinden, probeert de DNS-server die host is van de stub-zone standaardrecursie uit te voeren via de ingestelde aanbevolen basisservers.

De DNS-server slaat de bronrecords die worden ontvangen van de bevoegde DNS-servers in een stub-zone op in de eigen cache. De records worden niet in de stub-zone zelf opgeslagen. Alleen de SOA-, NS- en glue-A-bronrecords die deel uitmaken van het antwoord op de query worden opgeslagen in de stub-zone. De bronrecords worden opgeslagen en bewaard in de cache volgens de TTL (Time-to-Live) in elke bronrecord. De SOA-, NS- en glue-A-bronrecords, die niet worden opgeslagen in de cache, verlopen op basis van het verloopinterval dat is opgegeven in de SOA-record van de stub-zone. Deze record wordt gemaakt tijdens het definiëren van de stub-zone en wordt bijgewerkt tijdens overdrachten naar de stub-zone vanuit de oorspronkelijke, primaire zone.

bron: Naamomzetting voor stub-zones

[Anoniem: 113748]

Thnx ik begin het een beetje te snappen. Ik vraag me dan alleen nog af wat het verschil tussen forwarders en stub zones zijn. Omdat forwarders ook query's doorsturen....

[mutsje]

als je goed zoekt op www.microsoft.com/technet kom je een video tegen die ongeveer 1 1/2 uur duurd en waarin alles over de werking van dns en stubzones uitgekwauwd wordt. Het was mij duidelijk toen ik deze ongeveer 1 1/2 jaar geleden gezien heb. FF zoeken het is de moeite waard.

[Question Mark]

Anoniem: 113748 schreef op woensdag 07 juni 2006 @ 12:08:
Thnx ik begin het een beetje te snappen. Ik vraag me dan alleen nog af wat het verschil tussen forwarders en stub zones zijn. Omdat forwarders ook query's doorsturen....

Bij Conditional Forwarders worden de forwarder adressen handmatig ingevoerd/bijgehouden. Bij stubzones worden de records van de namesserver gerepliceerd. Mochten er nameservers veranderen, dan moet er bij Forwarders dus handmatig ingegrepen worden om eea weer te laten werken, bij stubzones hoeft dit dus niet (de nameservers worden immers gerepliceerd).

[Anoniem: 113748]

Dus ff een korte samenvatting:

Als een client een query uitvoerd op server A (stub zone) dan wordt de record de 1ste keer opgehaald bij Server B (waar de record op staat) en als een andere client weer dezelfde record opvraagt op Server A dan geeft Server A dit aan de client door het uit zijn cache te halen. En dit zelfde geldt bij forwarders. Heb ik het juist?

[Anoniem: 57365]

yup, alleen caching hangt af van de ttl van de records en die worden dus bepaalt door de soa server.

de keuze of je conditional forwarders of stub zones moet gebruiken is simpel. Stub zones altijd kiezen als dit mogelijk is. conditional forwarders alleen gebruiken voor dns servers die buiten je beheer vallen.

de keuze stub/conditional of zone transfers ligt complexer en zal gebaseerd moeten worden op de hoeveelheid netwerkverkeer die de beide oplossingen oplevert. In beginsel dus een verwachting (hoeveel zal er gequeried gaan worden) en later simpelweg meten

[DeMoN]

I know, redelijk oud topic maar wel erg interessant en ik wil graag wat opheldering hebben indien mogelijk

Anoniem: 57365 schreef op woensdag 07 juni 2006 @ 14:31:
yup, alleen caching hangt af van de ttl van de records en die worden dus bepaalt door de soa server.

de keuze of je conditional forwarders of stub zones moet gebruiken is simpel. Stub zones altijd kiezen als dit mogelijk is. conditional forwarders alleen gebruiken voor dns servers die buiten je beheer vallen.

Maar je kunt stub-zones toch ook gebruiken icm servers die buiten je beheer vallen?

de keuze stub/conditional of zone transfers ligt complexer en zal gebaseerd moeten worden op de hoeveelheid netwerkverkeer die de beide oplossingen oplevert. In beginsel dus een verwachting (hoeveel zal er gequeried gaan worden) en later simpelweg meten

Is conditional forwarding eigenlijk niet precies hetzelfde als een stub-zone als het aankomt op snelheid? Eigenlijk doet het hetzelfde alleen heb je met een stub-zone wat minder beheer aangezien het de evt. veranderde IP's van de Nameservers meteen update via de replicatie van de SOA record?

Want het doet allebei ook caching.. toch?

[DeMoN]

Hmm tegenwoordig nog maar weinig mensen die hier echt verstand van hebben zeker?

[Question Mark]

DeMoN schreef op maandag 27 november 2006 @ 16:50:
Maar je kunt stub-zones toch ook gebruiken icm servers die buiten je beheer vallen?

Kan, mits zone-replicatie naar jouw DNS-servers (waar je dus de stub-zone op wilt hosten) maar toegestaan is... Vandaar de opmerking van IIS5 over de beheersscope van DNS-servers. DNS servers waar je geen beheer over hebt, mag je waarschijnlijk ook niet van repliceren en dus werken stubzones in dat geval niet.

In dat geval heb je geen andere keuze dan Conditional Forwarding.

[DeMoN]

Question Mark schreef op woensdag 29 november 2006 @ 14:51:
[...]
Kan, mits zone-replicatie naar jouw DNS-servers (waar je dus de stub-zone op wilt hosten) maar toegestaan is... Vandaar de opmerking van IIS5 over de beheersscope van DNS-servers. DNS servers waar je geen beheer over hebt, mag je waarschijnlijk ook niet van repliceren en dus werken stubzones in dat geval niet.

In dat geval heb je geen andere keuze dan Conditional Forwarding.

Bedankt voor je opheldering.. leuke sig trouwens

[PolarWolf]

MS raadt aan om stub zones te gebruiken in situaties waarbij de site waarnaar verwezen wordt veel veranderingen kent in de DNS infrastructuur, en dan met name in de adressering van de nameserver. Bij een stub zone wordt namelijk het "glue" gedeelte van de zone overgehaald van (een of meerdere) master servers, dus alleen de SOA en de NS records (ja, dit is een zone transfer, dus dat moet ook even geregeld zijn). Bij conditional forwarders zou je die constant moeten aanpassen indien je alle NS servers van die andere site zou willen gebruiken voor name resolving.

Overigens heeft het type query ook nog een vrij belangrijke rol in het hele DNS verhaal. Forwarding queries zijn recursief, terwijl het gebruik van stubzones iteratieve queries toelaat. Dit is van invloed op de hoeveelheid resolving verkeer, en ook de caching. Wat er in de cache komt hangt weer heel erg af van het type van de oorspronkelijke query. Als die iteratief was, dan zal de cache alleen een NS record bevatten voor het gevraagde domein. Indien 'ie recursief was, dan zal de cache het uiteindelijke antwoord bevatten, dus ofwel een resolving of een "negative cache entry". Dit is omdat de DNS server zelf is gevraagd om met het antwoord op de proppen te komen, en niet met een referral.

Best leuk, DNS

Meestal volstaat een (conditional) forwarder.

[DeMoN]

PolarWolf schreef op donderdag 30 november 2006 @ 17:26:
Als die iteratief was, dan zal de cache alleen een NS record bevatten voor het gevraagde domein.

Nee toch?
Stel je vraagt widgets.voorbeeld.com op, iteratief.
Dan staan uiteindelijk de referrals naar .com, .voorbeeld.com en .widgets.voorbeeld.com in je cache, toch?

Indien 'ie recursief was, dan zal de cache het uiteindelijke antwoord bevatten,

Ja, in dit geval wel omdat de resolving eigenlijk buiten je netwerk om gaat. Pas als ie klaar is en het hele domein heeft gevonden (fqdn) komt ie terug naar jouw DNS servert, die het vervolgens cached en naar de DNS Client stuurt.

dus ofwel een resolving of een "negative cache entry". Dit is omdat de DNS server zelf is gevraagd om met het antwoord op de proppen te komen, en niet met een referral.

Zou je dit wat beter kunnen toelichten? Volgens mij reppen ze hier ook niet over in een gemiddeld boek zoals die van MSPress.. of ik moet er overheen hebben gelezen

Best leuk, DNS

Zeker! And still learning.. so correct me if I'm wrong

Verder al heel erg bedankt

[PolarWolf]

DeMoN schreef op donderdag 30 november 2006 @ 19:17:
Nee toch?
Stel je vraagt widgets.voorbeeld.com op, iteratief.
Dan staan uiteindelijk de referrals naar .com, .voorbeeld.com en .widgets.voorbeeld.com in je cache, toch?

Stel, ik ben een client. Ik doe een iteratieve query naar een server. Die server zal (afhankelijk van z'n instellingen) het best mogelijke antwoord geven. Dus ofwel wat ik moet hebben (het antwoord), ofwel een referral naar een NS server die het wel zou kunnen weten. Mijn client zal vervolgens die referral gebruiken om weer een query naar te sturen, buiten de eigen DNS server om. In de server cache zal dus alleen het antwoord staan wat deze aan mij als client heeft gegeven, niet de rest van de resolving.

Ja, in dit geval wel omdat de resolving eigenlijk buiten je netwerk om gaat. Pas als ie klaar is en het hele domein heeft gevonden (fqdn) komt ie terug naar jouw DNS servert, die het vervolgens cached en naar de DNS Client stuurt.

Da's recursief.

Zou je dit wat beter kunnen toelichten? Volgens mij reppen ze hier ook niet over in een gemiddeld boek zoals die van MSPress.. of ik moet er overheen hebben gelezen

Een antwoord dat de server het niet weet, en ook niet kan vinden via andere methoden (met andere woorden, de naam kan niet worden geresolved) is ook een antwoord, en wordt ook gecached. Door zowel de server zelf als de client. Dat heet "negative cache entry". Daarom moet je ook al je caches flushen (server en client) wanneer je problemen probeert op te lossen.

Scenario:
Je hebt een DNS server, waar je een conditional forwarder in hebt gezet naar domain.lan. Je probeert a.domain.lan te resolven, maar je krijgt terug dat die niet gevonden kan worden. Je checkt alles, en je komt tot de ontdekking dat je een typefout hebt gemaakt in de forwarder. Je herstelt dit, en probeert het nog een keer. Helaas, je krijgt nog steeds het antwoord terug dat je al had, namelijk dat de host niet bestaat: Dit komt uit je client cache. Dus, je flusht die (ipconfig /flushdns), en probeert het nog eens. Weer geen resolving. Het antwoord krijg je nu uit de server cache. Dus je flusht die ook nog maar eens. Wederom probeer je de naam te resolven.

Huiswerk: Wat zal het resultaat zijn, en waarom?

Zeker! And still learning.. so correct me if I'm wrong

Ik weet ook niet alles, dus als iemand betere of andere inzichten heeft...

[DeMoN]

PolarWolf schreef op donderdag 30 november 2006 @ 19:46:


Huiswerk: Wat zal het resultaat zijn, en waarom?

Es kijken

a.domain.lan wil je resolven. Deze is nergens op internet via de rootservers te vinden en je hebt er in dit geval ook geen zone's voor staan in je eigen DNS, dus gaat het fout.
Jij zegt nu dat je er een conditional forwarder voor maakt, maar dan incl. tikfout Dus laten we zeggen: a.domian.lan

dns client (recursive query for a.domain.lan (ziet niets in cache en hier geen tikfout)) -> dns server (ziet niks in cache en daarna ook geen forwarder ivm tikfout) -> rootservers -> komt op helemaal niks uit -> server EN client zetten een negative cache weg (voor a.domain.lan) want: niks gevonden

Op client: ipconfig /flushdns
Op server: tikfout corrigeren. domian -> domain

dns client (recursive query for a.domain.lan (ziet niets in cache (door flush) en hier geen tikfout)) -> dns server (kijkt eerst in cache) -> FOUT! ivm een negative stukje cache -> geeft het door aan de client -> client schrijft het WEER FOUT(!) in cache weg.

Op server: ipconfig /flushdns

dns client (recursive query for a.domain.lan) -> FOUT, client cache zegt nu namelijk weer al dat er iets niet klopt want dat zei de server net nog

Moraal: Op de server en de client de cache wissen en dan pas opnieuw proberen. Of een uur later pas proberen (TTL expire @ server) en de client rebooten (auto dns flush).

Wat jij en wat is mijn cijfer?

[PolarWolf]

Volle punten

[DeMoN]

Woei, thx voor de boeiende vraag. Eerst wilde ik meteen antwoorden maar toen ik het ter verduidelijking ging opschrijven zag ik het ineens anders

Leuk topic

[PolarWolf]

Overigens doe je op de server geen ipconfig /flushdns om de server cache te clearen (las ik gister even overheen). Daarmee flush je de cache van de client die op de server draait (jawel, de server zelf is ook een client). Om de server cache te flushen moet je in de DNS snapin de server selecteren, rechts klikken, en kiezen voor "clear cache".

[DeMoN]

PolarWolf schreef op vrijdag 01 december 2006 @ 09:21:
Overigens doe je op de server geen ipconfig /flushdns om de server cache te clearen (las ik gister even overheen). Daarmee flush je de cache van de client die op de server draait (jawel, de server zelf is ook een client). Om de server cache te flushen moet je in de DNS snapin de server selecteren, rechts klikken, en kiezen voor "clear cache".

Dat klopt, scherp