Hallo Steffen, Steffen Dettmer schrieb:

* Micha Wali wrote on Sat, Mar 11, 2000 at 21:39 +0100:

...

echo -e "nameserver $MS_DNS1 $MS_DNS2" >> /etc/resolv.conf wenn Du selber einen DNS server verwendest mußt du die beiden Variablen eben anders verwursten :-)

Nein, wenn er selbst einen DNS-Server verwendet, kann er diesen immer direkt verwenden, denn dieser hat immer 127.0.0.1, dann entsteht da überhaupt kein Problem.

er dachte vielleicht daran die zugewiesenen DNS-Server in der named.(boot|conf) einzutragen und danach den named zu reloaden. cu Michael --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com

Hi, Steffen Dettmer schrieb:

* Michael Stumpf wrote on Sun, Mar 12, 2000 at 21:42 +0100:

...

er dachte vielleicht daran die zugewiesenen DNS-Server in der named.(boot|conf) einzutragen und danach den named zu reloaden.

Und was bringt das dann - mal von Spezialfällen abgesehen natürlich.

z.B. Anwendungszweck: ISDN-Dial-Up-Verbindung mit lokalem DNS (.invalid-Domain), mehreren Clients und wechselnden Internet-By- Call-Providern ... cu Michael --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com

* Andreas Bock wrote on Mon, Mar 13, 2000 at 23:18 +0100:

Michael Stumpf wrote:

...

Steffen Dettmer schrieb:

...

...

er dachte vielleicht daran die zugewiesenen DNS-Server in der named.(boot|conf) einzutragen und danach den named zu reloaden.

Und was bringt das dann - mal von Spezialfällen abgesehen natürlich.

z.B. Anwendungszweck: ISDN-Dial-Up-Verbindung mit lokalem DNS (.invalid-Domain), mehreren Clients und wechselnden Internet-By- Call-Providern ...

Ähh... Ja, und? Du weißt, daß man DNS-Forwarder verwenden _kann_, aber nicht muß, da ein DNS-Server die root-Namenserver kennt (wenn man nicht gerade die root.hint kaputtmacht :) ) ?

das mit mehreren Providern ist ein Argument, aber wer nur freenet verwendet, kann die Adressen auch fest eintragen. Hatte ich so

Die DNS-Caches (also die, die Otto Normaluser von seinem Windoofs fragen läßt) prüfen i.d.R. nicht mal, von wem die Anfragen kommen.

gemacht, fest die IP von deren DNS in meinen bind8 eingetragen. Hab nich mal gemerkt, dass die sich geändert hatte. Erst durch diesen Thread bin ich drauf gekommen, doch mal wieder nachzuschauen.

Ich bin gar nicht so ein Freund von Forwardern... Hat das praktische Vorteile?! Gut, die DNS-"Huren" haben i.d.R. einen guten Cache, weil viele über die Dinger gehen, aber dafür auch ältere Daten, eine Anfrage, die nicht im Cache ist, dauert länger, und der eigene DNS-Server kann die drüberliegenden Domains nicht cachen (weil er die Daten ja nicht bekommt, nur das "Ergebnis"). Übersehe ich was?! oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel. --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com

Steffen Dettmer schrieb in 1,8K (51 Zeilen):

Ähh... Ja, und? Du weißt, daß man DNS-Forwarder verwenden _kann_,

Ich bin gar nicht so ein Freund von Forwardern... Hat das praktische Vorteile?!

Ja, z.B. - Entlastung der Rootserver - Beschleunigung, wenn cached (Beides wie bei webcaches!) - zentrales DNS-Repository bei groesseren/Dialup-Netzwerken

Gut, die DNS-"Huren" haben i.d.R. einen guten Cache, weil viele über die Dinger gehen, aber dafür auch ältere Daten, eine Anfrage, die nicht im Cache ist, dauert länger,

D.H. dein Server will www.ph-cip.uni-koeln.de. aufloesen. Du kennst nur . (rootserver) oder gerade mal .de. Der Forwarder hat eine gute Chance, schon .uni-koeln.de. zu kennen. Macht einen lookup weniger. Ist also schneller. Oder bist du der Meinung, der Cache-Lookup des Providers + dessen in der Regel wesendlich schnellere Leitung zur Aussenwelt ist langsamer als den Root-Server selber zu fragen und sich dann durchzufragen?

und der eigene DNS-Server kann die drüberliegenden Domains nicht cachen (weil er die Daten ja nicht bekommt, nur das "Ergebnis"). Übersehe ich was?!

Ja. Angenommen, du willst auf h1, h2 und h3 von example.org zugreifen. kein forwarder forwarder h1 Lookup .org Lookup h1.example.org an forwarder[1] Lookup .example.org Lookup h1.example.org h2 Lookup h2.example.org Lookup h2.example.org an forwarder[2] h3 Lookup h3.example.org Lookup h3.example.org an forwarder[2] [1] Im schlimmsten Fall macht der Forwarder 3 lookups, im Normalfall nur .example.org und h1.example.org ... einen weniger als du. Und die Chance, dass er .example.org kennt, ist durchaus gegeben! [2] Der Forwarder merkt sich wie du die Ergebnisse. Du verlierst also nichts! -Wolfgang --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com

Steffen Dettmer schrieb in 3,2K (85 Zeilen):

* Wolfgang Weisselberg wrote on Sun, Mar 19, 2000 at 19:27 +0100:

...

Der Forwarder hat eine gute Chance, schon .uni-koeln.de. zu kennen. Macht einen lookup weniger. Ist also schneller.

Dann brauche ich noch mail.ph...., leider liefert der Forwarder nur den Eintrag für www, also muß der Forwarder den erst holen.

Ob du ihn holen musst oder der Forwarder, ist herzlich egal. Es ist und bleibt *ein* zusaetzlicher Lookup: auf mail.ph-cip... Oder saugst du bei einem lookup auf www.example.org immer gleich auch *.example.org mit?

Sonst könnte der richtige DNS-Server sofort gefragt werden. Ist also langsamer. Aber für rastlose Surfer spielt das vermutlich weniger ne Rolle.

1. richtig ist der, der die Antwort weiss. 2. Modem oder ISDN-Leitung ist langsamer als die Leitung vom Provider zur Aussenwelt. (wenn du www und mail brauchst, brauchst du nur 2 Anfragen, nicht noch 3 zusaetzliche auf .de., uni-koeln.de., ph-cip.uni-koeln.de. --- der Forwarder des Providers braucht diese Angaben selten (cache) udn ist IMHO schneller bei ph-cip.uni-koeln.de.) 3. Wenn genuegend Leute nach www.ph-cip.uni-koeln.de. (und Co) fragen, dann werden sich nicht nur die root-server bedanken. Auch ns*.uni-koeln.de sagt dann irgendwann *tschuess*, mal ganz abgesehen von der Leitung nach draussen. Von daher verstehe ich dein "langsamer" nicht, oder meinst du: "der Forwarder muss manchmal (nicht dauernd) einen Lookup machen, und im Schnitt ist der *so* langsam, dass eine direkte Anfrage im Schnitt schneller ist"?

...

Oder bist du der Meinung, der Cache-Lookup des Providers + dessen in der Regel wesendlich schnellere Leitung zur Aussenwelt ist langsamer als den Root-Server selber zu fragen und sich dann durchzufragen?

Sicher, wenn ich mehrere Hosts aus einer Domain brauche, gehen die alle den Umweg über einen DNS-Server, sonst kommen sie direkt, sofort. Ist also (außer eben beim ersten Domainanfrage natürlich) schneller.

Wenn ich dich richtig verstehe, hat sich soeben u.a. der SQUID in Luft aufgeloest. Oder sagst du nicht: Caches (im allgemeinen) sind langsamer, egal ob sie die Daten schon haben"? Spielen wir den Fall durch: Wir haben www und wollen www2: Forwarder, nicht im Cache Du ---X ms--> Forwarder (F ms) ---Y ms--> NS.* (N ms) --. Du <--X ms--- Forwarder (F' ms) <--Y ms-- <-------------' Forwarder, im Cache Du ---X ms--> Forwarder (F ms) --. Du <--X ms--- <------------------' Kein Forwarder Du ---X ms--> ---Y ms--> NS.* (N ms) --. Du <--X ms--- <--Y ms--- <-------------' 2* X ms ~= Pingtime Du <-> ISP. F ms ~= Lookup-Time Forwarder[1] F' ms ~= Insertion-Time in den Cache + reply 2* Y ms ~= Pingtime ISP <-> Nameserver N ms ~= Lookup-Time Nameserver[2] C = Chance, dass der Forwarder die Daten hat (0 <= X <= 1) [1] Annahme: Hits sind nicht schneller als Misses. [2] Annahme: Der NS ist immer gleichschnell (was nicht der Fall ist, wenn Forwarders weithin nicht mehr benutzt werden) Zusaetzliche Annahme: Du bekommst keine Delegation auf einen besseren Server (dann geht das Ganze Spiel naemlich nochmal los, nur spart der Forwarder dann 2*X ...) bzw du bekommst keinen CNAME als Antwort (und das war nicht die Frage), dann muesstest du naemlich geg. einen weiteren Lookup machen (und wieder sparst du 2*X im Austausch gegen F' und F). Daraus folgt: Lookup ohne Forwarder: 2*X + 2*Y + N Lookup mit Forwarder: 2*X + F + ((1-C) * 2*Y + N + F') Daraus folgt: Forwarder abschalten nuetzt nur, wenn 2*Y + N < F + ((1-C) * 2*Y + N + F') also, wenn entweder der Forwarder im Schnitt selten cached (weil dann -- worst case -- F + F' hinzukommt) oder wenn F kaum schneller als 2*Y + N ist (also der Forwarder kaum schneller als die Leitung + der remote NS ist). Stimmts?

...

Ja. Angenommen, du willst auf h1, h2 und h3 von example.org zugreifen.

...

kein forwarder forwarder

...

h1 Lookup .org Lookup h1.example.org an forwarder[1] Lookup .example.org Lookup h1.example.org h2 Lookup h2.example.org Lookup h2.example.org an forwarder[2] h3 Lookup h3.example.org Lookup h3.example.org an forwarder[2]

...

[1] Im schlimmsten Fall macht der Forwarder 3 lookups, im Normalfall nur .example.org und h1.example.org ... einen weniger als du. Und die Chance, dass er .example.org kennt,

Aber ich muß dennoch einen machen, um das Ergebnis zu holen, also ohne forwarder insgesammt 5 Lookups, im anderen Falle 3 lookups an den Forwarder plus warten, bis dieser seine 3 lookups gemacht hat.

Der Forwarder muss *maximal* 3 Lookups fuer h1.example.org machen und *maximal* einen weiteren pro h*.example.org. Du musst praktisch immer 3 Lookups fuer h1.example.org und praktisch immer einen weiteren pro h*.example.org. Wenn 2*Y klein und F gross ist, dann klar, dann ist der Forwarder fuer dich nicht brauchbar.

Im günstigsten Falle. h4+ dauern aber alle länger, weil alle über den Forwarder laufen.

Maximal um F + F'. Wenn du ein brauchbar grosses C hast, bist du am Ende schneller. Wenn z.B. Y gross ist (nach Kanada oder .ru), faellt F und F' kaum in's Gewicht, ein einziger gecacheter Hit macht viele Misses dann schon wieder wett.

Im Falle des cachens kommt erschwerend hinzu, daß das Alter der Daten nicht mitübermittelt wird, also gelten dann TTL * DNS-Server.

Wuerdest du bitte die entsprechende Stelle in den RFCs angeben? Meine Leserei sagt naemlich genau das Gegenteil!

Im schlimmsten Falle forwarded der ISP intern auch nochmal... Und diesen kann man dann übrigens auch nicht notfalls mal neustarten, um ein Cache-Expire zu erzwingen.

Man kann natuerlich auch die 'authoritative information' verlangen ...

Es soll sogar vorzukommen, das DNS-Server die TTLs künstlich verlängern (hat jedenfalls mal ein ISP behauptet - kann mir allerdings kaum vorstellen, das die einen bind gepatcht haben; evtl. gibt's aber auch was anderes da...).

Klar. Kann man alles machen. Es gibt sogar Menschen, die falsche Daten (von aussen) in DNS-Server eintragen ...

Dann verdient so ein ISP mit forwardern nichts, also wird er in der Regel da nicht sehr in Performance investieren...

Versuch' mal ohne gute DNS-Server zu surfen ... Da kann der ISP auch auf den Webcache verzichten. :-) -Wolfgang --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com

Steffen Dettmer schrieb in 5,9K (174 Zeilen):

* Wolfgang Weisselberg wrote on Sun, Mar 26, 2000 at 19:18 +0200:

...

Steffen Dettmer schrieb in 3,2K (85 Zeilen):

...

...

* Wolfgang Weisselberg wrote on Sun, Mar 19, 2000 at 19:27 +0100: Dann brauche ich noch mail.ph...., leider liefert der Forwarder nur den Eintrag für www, also muß der Forwarder den erst holen.

...

Ob du ihn holen musst oder der Forwarder, ist herzlich egal. Es ist und bleibt *ein* zusaetzlicher Lookup: auf mail.ph-cip...

Nein, wenn der Forwarder ihn holen muß, braucht's ein lookup mehr: ich frage den Forwarder und dieser den DNS-Server. Ansonsten (ohne Forwarder) frage ich direkt den richtigen DNS-Server.

*seuftz* Wir koennen jetzt auch die Router und den NAT-Server dazuzaehlen, ja? Dann kommen wir auf nette Zahlen. Der forwardende DNS-Server ist ein Proxy, (wie ein squid auch) und der hat in der Regel mehr Cache als deiner. Spart den ISP ja auch traffic.

...

...

Sonst könnte der richtige DNS-Server sofort gefragt werden. Ist

...

1. richtig ist der, der die Antwort weiss.

Bitte?!

Richtig ist der DNS-Server, der dir korrekt auf deine Anfrage antwortet. Das ist oft genug der deines ISP.

...

2. Modem oder ISDN-Leitung ist langsamer als die Leitung vom Provider zur Aussenwelt. (wenn du www und mail brauchst,

Na na na... Oft hat der ISP zum erwünschten Netz ein delay von mehr als 100ms, die ISDN Leitung braucht nur 30ms (DNS braucht ja kaum Bandbreite).

Und, welchen delay hat deine Anfrage an deinen gewuenschten Server?

...

brauchst du nur 2 Anfragen, nicht noch 3 zusaetzliche auf .de., uni-koeln.de., ph-cip.uni-koeln.de. --- der Forwarder des Providers braucht diese Angaben selten (cache) udn ist IMHO schneller bei ph-cip.uni-koeln.de.)

Ja, der lokale cacht ja auch, also muß er die zusätzlichen nur einmal machen (wie ja auch der Forwarder).

Wieso also Netzwerk und den Ziel-DNS mehr als notwendig belasten? Wenn 100 Leute keinen Forwarder nehmen, hat der DNS 90 Anfragen (10 ISPs) mehr.

...

3. Wenn genuegend Leute nach www.ph-cip.uni-koeln.de. (und Co) fragen, dann werden sich nicht nur die root-server bedanken. Auch ns*.uni-koeln.de sagt dann irgendwann *tschuess*, mal ganz abgesehen von der Leitung nach draussen.

Wie jetzt: tschüß?

... wird der DNS ueberlastet, wird er langsam oder gibt gar ganz auf.

...

Von daher verstehe ich dein "langsamer" nicht, oder meinst du: "der Forwarder muss manchmal (nicht dauernd) einen Lookup machen, und im Schnitt ist der *so* langsam, dass eine direkte Anfrage im Schnitt schneller ist"?

[...]

Nee, ich sagte nur, nicht gecachte Daten holt man (bei einer einzigen Anfrage/der ersten Anfrage) schneller direkt als über einen Cache, ein Cache lohnt also erst ab der zweiten Anfrage (oder später, je nachdem).

Und hier ist dein Irrtum. Was fuer dich die erste Anfrage ist, ist fuer den ISP-DNS ne alte Kamelle. Nur weil du das noch nicht weisst darf es der ISP-DNS auch nicht wissen?

...

Spielen wir den Fall durch: Wir haben www und wollen www2:

...

Forwarder, nicht im Cache

(Mathematiker! Sorry, das ist mir zu unübersichtlich, ich setz mal Beispielzahlen ein:)

Keine Beleidigungen, bitte! :-)

Gehen wir mal davon aus, daß der Forwarder 5ms Bearbeitungszeit braucht, und 10ms um erreicht zu werden (oder 14 um erreicht zu werden, und 1 ms bearbeitung)

Eben, hier fangen die Zahlenspielereien an.

...

Du ---X ms--> Forwarder (F ms) ---Y ms--> NS.* (N ms) --. Du <--X ms--- Forwarder (F' ms) <--Y ms-- <-------------'

Du ---30 ms--> Forwarder (F 15ms) ---200 ms--> NS.* (N 5ms) --. Du <--30 ms--- Forwarder (F' 15ms) <--200 ms-- <-------------'

sind dann 30+5+200+5+200+5+30= 495ms ^ ^ ^^^ Hmmm? Ich dachte 15 ? Sonst auch 475, ja?

Nehmen wir fuer Y mal 100, 200 und 500 ms an, und N sollte in aehnlicher Groesse wie F/F' liegen, also 5 ms: X F Y N Y F' X Schnell: 30 + 15 + 100 + 15 + 100 + 15 + 30 == 305 Normal: 30 + 15 + 200 + 15 + 200 + 15 + 30 == 505 Langsam: 30 + 15 + 500 + 15 + 500 + 15 + 30 == 1105

...

Forwarder, im Cache Du ---X ms--> Forwarder (F ms) --. Du <--X ms--- <------------------'

=30+15+10+30= 85ms

Lassen wir die Zahl mal so stehen.

...

Kein Forwarder Du ---X ms--> ---Y ms--> NS.* (N ms) --. Du <--X ms--- <--Y ms--- <-------------'

=30+200+5+200+30= 465ms

.o.: X X' Y N Y X' X Schnell: 30 + 10 + 100 + 15 + 100 + 10 + 30 == 295 Normal: 30 + 10 + 200 + 15 + 200 + 10 + 30 == 495 Langsam: 30 + 10 + 500 + 15 + 500 + 10 + 30 == 1095 Wobei X' die inneren Verbindungskosten zum Aussennetz darstellt.

(eine direkte Anfrage ist schneller als eine, die nicht im Cache liegt)

Ja, aber. Eine beim ISP gecachte Anfrage ist 3.5/5.8/12.9 mal so schnell (==> 2.5/4.8/11.9 mal schneller als) wie eine direkte Anfrage. Dagegen ist ein Cache-Miss nur um .03/.02/0.01 langsamer. Nach deiner Rechnung: 5.8 mal so schnell bzw. 6% langsamer. D.h. pro MISS sparst du 30 ms, aber ein HIT bringt dir (gegen die Direktverbindung 380ms, also gewinnst du bei einem MISS:HIT Ratio von schlechter als 12.6:1. In anderen Worten: Nach *deinen* Daten solltest du den Forwarder verwenden, wenn du 2 Hits auf 25 Namen hast.[1] Und dabei haben wir noch nicht einmal die rekursiven Nachfragen betrachtet (i.e. edu. -> mit.edu -> rtfm.mit.edu). Dann sparst du naemlich pro Aufruf 60 ms (2*X) ... die Rechenkosten fuer den DNS sollten identisch sein. [1] Nach meinen Werten: Schnell: 220:20 ms 11:1 Mittel: 420:20 ms 21:1 Langsam: 1020:20 ms 51:1

...

F ms ~= Lookup-Time Forwarder[1] plus Erreichbar keit (der DNS läuft ja nicht auf dem Dialin router) Sollte sich aufheben, da du _durch_ den ISP hindurch musst: die Ausgaenge sind auch nicht am Dial-up router. F' ms ~= Insertion-Time in den Cache + reply plus Erreichbarkeit s.o.

Annahme[3]: Der ISP hat 0% Packetverlust.

Nein, du hast den gleichen Paketverlust, du nimmst die gleiche Leitung. Wenn der ISP intern nennenswerte Paketverluste hat, solltest du schnell wechseln.

...

Maximal um F + F'. Wenn du ein brauchbar grosses C hast, bist du am Ende schneller. Wenn z.B. Y gross ist (nach Kanada oder .ru), faellt F und F' kaum in's Gewicht, ein einziger gecacheter Hit macht viele Misses dann schon wieder wett.

Siehst du, ich hab's gesagt.

Yepp, spannend wirds dann, wenn nur 75% der Packete zum/vom DNS ankommen, haben wir so sogar Verluste von 0,75*0,75...

.o. 25% Packet-loss, der nur den ISP-DSP betrifft, tritt nicht auf. (Okok, bei M$ oder AOL oder Metronet vielleicht, aber wir reden hier von einem ISP, ja?)

...

...

Im Falle des cachens kommt erschwerend hinzu, daß das Alter der Daten nicht mitübermittelt wird, also gelten dann TTL * DNS-Server.

...

Wuerdest du bitte die entsprechende Stelle in den RFCs angeben? Meine Leserei sagt naemlich genau das Gegenteil!

Ja? Tja, nee, ähh, ich hab da nicht angelesen, es "nur zu gehört" :)

Halbwissen ... :-|

...

Versuch' mal ohne gute DNS-Server zu surfen ... Da kann der ISP auch auf den Webcache verzichten. :-)

Der gute Cache kann ja bei mir stehen :)

forward-first.

Mir ist es so jedenfalls lieber, weil ein Risiko weniger da ist, und wer Freenet-DNS benutzt hat, weiß auch, wie stark ein DNS-Server bremsen kann... Außerdem funktioniert es unabhängig vom Einwahlpunkt.

forward-first. Und in ip-up/ip-down statt der /etc/resolv.conf einfach /etc/named.conf aendern und killproc -HUP /usr/sbin/named machen geht IIRC sehr gut.

Und richtig: einen perfekten DNS beim ISP vorrausgesetzt, lohnt sich dieser, selbst wenn man nur 10% Cache Hits bei diesem annimmt.

In manchen Faellen lohnt er sich noch bei 3-4% sehr (ping ~ 1s). s.o.

Wie gesagt, bei perfektem Server :) Aber ein lokaler Cache enthält sowieso schnell alles, was man (zum arbeiten, nicht Ein-Person-surfen) braucht...

Klar, aber warum ihn nicht ueber einen Forwarder beschleunigen, bis er alles hat? -Wolfgang --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com

Micha Wali wrote:

- in die /etc/ppp/options.ipppX (X entsprechend ersetzen!) folgendes eintragen: ms-get-dns

Es soll auch getpeerdns (= get - peer - DNS ) mit den neueren ppp-Daemons funktionieren. Wie die DNS dann in die resolv.conf wandert weiss ich nicht. Kann dazu jemand was sagen? (Ich habe nur pppd 2.3.5 ohne diese Unterstützung) Ekkard --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com

Marc Schiffbauer wrote:

...

getpeerdns (= get - peer - DNS )

mit den neueren ppp-Daemons funktionieren.

pppd uebergibt die variablen DNS1 und DNS2 an das ip-up Script. In diesem muss dann die resolf.conf veraendert werden.

Also zusammenfassend: gleichwertig sind: ======================================== getpeerdns -> DNS1 und DNS2 ms-get-dns -> MS_DNS1 und MS_DNS2 (habe ich noch nicht testen können) BTW: klar, wer nimmt schon MS ... :-)) Gruss Ekkard --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com