Stubzonen vs. conditional forwarder

[neurotoxin 10]

Hallo,

 

ich bereite mich gerade auf die 291 vor und bin über eine Frage gestolpert, die ich nicht ganz nachvollziehen kann.

 

Ein Aussenstelle soll über eine 128 Kbit leitung angebunden werden. Mein Primärer DNS Server steht in der Hauptnierlassung. Ich soll in der Aussenstelle einen DNS Server einrichten und entscheiden, wie ich die Namensauflösung zu der Haupstelle sicherstelle.

 

Es werden folgende drei Möglichkeiten angeboten

 

1. Sec. Zone

2. Stubzone

3. Con. Forwarding

 

Unter berücksichtigung der langsamen Anbindung fällt die Sec. Zone weg. Con. Forward würde funktioniren, fänd ich persönlich aber nicht so toll, da bei änderungen der NS in der Hauptnierderlassung diese manuell in der Aussenstelle nachegtragen werden müssten.

Stubzone wäre meiner Meinung nach die sinnvollste Möglichkeit.

Laut antwort soll man allerdings ein Con. Forwarding einrichten.

Ich habe mir im Netz und im MS Buch einen abgesucht um herauszufinden, ob der DNS Server auf der die Stubzone eingerichtet ist, auch ständig mit dem Primären DNS Serverver quatscht.

 

Vielleicht könnt Ihr mir ja einen denkanstoß geben

 

Danke im Voraus!!!

[IThome 10]

Stubzone bedeutet Zonentransfer (wenn auch abgespeckt), wegen der geringen Bandbreite daher das bedingte Weiterleiten. Der Zonentransfer findet regelmässig statt ...

[neurotoxin 10]

Also werden bei Stubzones regelmäßig Daten über die Leitung geschoben und nicht nur dann, wenn sich ein NS der Primären Zone ändert.

 

Dann ergibt das mit der Bedingten Weiterleitung einen Sinn.

 

Danke

[IThome 10]

Genau so ist es ... :)

[Hirgelzwift 10]

ich widerspreche ungern obgleich die antwort als solches richtig ist. die entscheidung ob stub zone oder bedingte weiterleitung eingerichtet wird ,lt. (m)eines MCT, bei dem ich meinen MOC hatte, aufgrund anderer kriterien entschieden und hängt einzig und alleine mit dem domänen konzept zusammen.

 

grundsätzlich verwendet man in der 1. sub domäne eine weiterleitung und ab der 2. eine stub zone. will sagen wenn du in der zentrale domäne.com als domäne am start hast und in der niederlassung zweig.domäne.com dann machst du eine weiterleitung wenn du aber als domäne in der niederlassung unter.zweig.domäne.com hast wäre dann machst du eine stub zone.

 

der wesentliche unterschied zwischen weiterleitung und stub zone ist das die stub zone änderungen an den DNS servern automatisch an andere DNS server weitermeldet, erzeugt aber, wie IThome schon angemerkt hat, einen etwas höheren traffic. als begründung habe ich gelernt: in der 1. sub domäne geht man von kurzen kommuniktionswegen aus und das änderung dieser art normalerweise kein problem darstellen. in weiterverzweigten strukturen geht man davon aus das diese kommunikation nicht mehr auf den kurzen dienstweg möglich ist und das diese kommunikation problematisch ist bzw. sein könnte. daher ist "stub" sozusagen erfunden worden.

 

bei grösser verschachtelten domänen mit mehreren zweigen ist das meiner meinung nach durchaus nachvollziehbar.

[grizzly999 11]

Nun, dann will ich auch meinen Senf dazugeben :D

Die eben gegebene Ausführung ist eine etwas eingengte Betrachtungsweise, die ernstzunehmenden Designüberlegungen nicht unbedingt entspricht.

Das merkt man schon daran, dass da solche Phrasen auftauchen wie "Das macht man grundsätzlich so, oder so,...."

Design in der IT (hier Design der Namensauflösung) ist ein Prozess, der alle Faktoren einer Umgebung, zusammenträgt, abwägt und dann nach Inbetrachtziehen aller Alternativen möglichst objektiv die beste der Alternativen zum Erreichen des Ziels auswählt.

Sofern keine technischen Muss-Anforderungen bestehen, bzw. eigentlich keine anderen Alternativen etwas zu lösen (als Beispiel: mehrere Domänen bei unterschiedlichen Kennwortanforderungen), sind Aussagen wie "Das macht man immer SO...." kontraproduktiv zu einem ordentlichen Design.

 

Das dazu.

 

Und:

in weiterverzweigten strukturen geht man davon aus das diese kommunikation nicht mehr auf den kurzen dienstweg möglich ist und das diese kommunikation problematisch ist bzw. sein könnte. daher ist "stub" sozusagen erfunden worden.

Das ist in mehrfacher Hinsicht nicht korrekt. Zum einen technisch nicht korrekt: Was bitte soll kürzer oder länger bei der DNS-Abfrage per Conditional Forwarding oder Stub-Zone sein?! Man erkläre mir das. In beiden Fällen habe ich einen anderen DNS zur Namensauflösung abzufragen, die dürften i.d.R. in beiden Fällen die selben sein, oder zumindest "genauso weit", was auch immer ""weit" bedeuten mag, oder hier wurde der Begriff des "kurzen Dienstweges" gebraucht. Der ist weder beim einen noch beim anderen wesentlich kürzer oder länger.

 

/edit: Oh, 4000 Zeichen Limit überschritten :eek:

 

END PART 1

Fortsetzung unten

[grizzly999 11]

Und die Stub Zone ist deshalb auch nicht erfunden worden. Der eigentliche Ansatz der Stub Zone ist eine Alternative zur "starren" Delegierung einer Sub-Domäne, bei der die authorisierneden NS der Sub Domain fest eingetragen werden. Damit diese Namensauflösung im Tree abwärts auf Dauer funktioniert, ist eine gute Kommunikation zwischen den DNS-Verantwortlichen der Sub Domain und der übergeordneten Domain unerlässlich. Wenn die DNS-Verantwortlichen in der Sub Domain NS hinzufügen, entfernen oder ändern, OHNE das den DNS-Verantwortlichen der übergeordneten Domäne zu kommunizieren, dann stimmt irgendwann die Delegierung in der übergeordneten Domain nicht mehr und eine Namensauflösung nach weiter unten schlägt fehl. Solche "gestörten" Kommunikationen findet man in der IT immer wieder, aus welchen Gründen auch immer. Sei es, aus Vergesslichkeit, oder aus dem "Wir sind unsere eigenen Herren und brauchen die da oben doch nicht" Gedanken, bis hin zu Dilletantismus.

 

Wenn man aber in der übergeordneten Domäne eine Stub Zone für die darunter liegende Domäne einrichtet, dann den DNS-Verantwortlichen der Sub-Domain eindringlich kommuniziert "Ihr dürft da unten Nameserver-technisch alles machen was ihr wollt, nur bitte, wenn ihr den/die Master DNS ändert, dann MÜSSEN wir da oben das erfahren", dann habe ich selbst bei einer recht agilen autarken Administration in der Sub-Domain auch bei den angesprochenen Kommuniationsproblemen keine Probleme mit der Namensauflösung nach unten. ;)

Das wäre eine der möglichen Design-Überlegungen, alle kann ich hier nicht aufzählen.

 

Natürlich kann die Stub Zone auch als Alternative zum Conditional Forwarding für Domänen dienen, die aus einem ganz anderen Tree stammen. Dabei sind dann wieder mehrere Faktoren zu bedenken, die die Entscheidung beeinflussen können, wie z.B. sind Firewalls dazwischen und welche Ports sind geöffnet (53 TCp oder UDP).

Der Traffic kann heutzutage objektiv eigentlich nicht das Entscheidungskriterium sein, denn der Unterschied an Traffic würde sich nicht mal bei einer 64 kB Leitung richtig bemerkbar machen (und wo hat man die noch).

Der Mehr-Traffic bei einer Stub-Zone besteht darin, dass der Stub Server in den vorgegenenen Intervallen (MS default: 15 min) bei seinem Master nachfragt, ob Updates da sind. Das sind ein paar Pakete und dann wird er ein Paket herunteladen, mit dem aktualisierten SOA-Record, weil wie oft ändern sich die Name Server?! Die paar Bytes mehr Trafic, da pfeiffe ich heute bei den üblichen Verbindungen drauf. Nichts desto trotz laufen da mehr Pakete als beim Cond. Forwarding, was bei Prüfungsfragen durchaus ein Kriterium sein kann.

 

Wollte ich einfach als Antwort hier loswerden, liegt daran, dass ich passionierter IT-Designer immer ein Kribbeln in den Stimmbändern bzw. in den Fingern verspüre, wenn ich o.a. Aussagen höre/lese.

 

END PART 2

 

grizzly999

[Hirgelzwift 10]

@grizzly: über sinn und unsinn von möglichkeiten kann man immer "streiten" aber ich vermisse aber einen ansatz in deinen ausführungen der jetzt eindeutig darlegt welches wohl die richtige (MS) antwort ist und warum und zu welchen regeln. ich habe nur das widergegeben was ich während eines MOC gelernt habe. selbst wenn das ein schlechtes praxisbeispiel ist, so wie ich es widergegeben habe, so habe ich sicher nicht während des MOC "umsonst" so gelernt, dass man es in der prüfung nach dieser regel beantworten soll. Eine FW ist wohl nicht in dem antworten bzw. fragenscope.

 

ich will jetzt keine namen nennen oder hinweise darauf geben wer mir das gesagt hat, aber was ich dazu sagen kann ist das dieser bewusste MCT vor einigen jahren MCT EMEA des Jahres war und das bei der mann bei seinen schülern einen sehr guten ruf hat weil diese nach dem besuch eines MOC mit über 80% erfolgsquote auch die prüfung auf anhieb schaffen und um das geht es hier wohl.

 

sehr häufig sind leider die prüfungsfragen nicht praxisorientiert, auch wenn sie nicht mehr so theoretisch sind wie noch vor einigen jahren. wie bereits erwähnt macht aber die regel die ich gelernt habe in grossen umgebungen mit mehreren zweigen usw. durchaus sinn. oft wird natürlich nach oben kommuniziert, ist dies dann aber nach unten in die anderen zweige auch so? Wo sonst würde denn eine stub zone sinn machen ausser in infrastrukturen in denen sich ständig etwas ändert (also gross) und in denen die kommunikation schwierig ist weil sie evtl. noch mehrere firmen umfasst?

[IThome 10]

Nichts desto trotz laufen da mehr Pakete als beim Cond. Forwarding, was bei Prüfungsfragen durchaus ein Kriterium sein kann

Ich denke auch, dass die Prüfungsrelevanz in diesem Fall entscheidend ist (da der TO sich auf ein offizielles Microsoft-Buch bezieht) ...