On Sat, 2 Apr 2005, Martin Reising wrote:
> On Sat, Apr 02, 2005 at 06:43:42PM +0200, Thomas Antepoth wrote:
[BCP snipped]
Bist Du bei denen noch am Lesen?
> > Versuch' doch mal, sofa.so.antepoth.de (siehe received: Zeilen) zu
> > resolven. ;-)
> Wieso sollte ich auf diese Idee kommen? Whois reicht wenn man mehr wissen
> will.
Dir - als denkendem Wesen - durchaus!
Es gibt aber einen Haufen komischer Software, die k�nnen nur mit
unqualifizierten Hostnamen arbeiten. Und die kann man nur �ber �ppige
Searchlists abfackeln. Domino R5 ist z.B. so ein Kamerad.
> > Die Sache mit dem .local kam mir erst nach dem Lesen von [2]
> > in den Sinn, da mir da erst bewusst wurde, da� man zum Resolven meiner
> > lokalen Hostnamen zuerst einmal .de resolven muss.
> Dein Nameserver ist zust�ndig f�r .so.antepoth.de und gut ist. Wo kommen da
> die Nameserver von DeNIC ins Spiel?
.de (ns) - .antepoth (ns) - .so (autsch!)
Diese ganze Query-Kette wird unn�tig, wenn man .local nimmt und diese
Subdomain auf seinem lokalen DNS kurzschlie�t. Bei antepoth.de gibt es
ausserhalb des LAN nur noch eine Wildcard und das sollte den Traffic
minimieren, sollte eine Anfrage von au�erhalb ankommen.
> Naja, alle Programme die ihre MessageID aus dem FQDN des Client bilden,
> erzeugen somit keine eindeutigen ID mehr, sobald die Daten das eigene Netz
> verlassen.
Das ist wahr und die Kollision von irgendwelchen Hash-Gebilden ist
beliebtes Thema in Doktorarbeiten von Kryptologen. Mir Kleingeist ist
das aber alles zu hoch und daher sehe ich das eher pragmatisch. ;-)
Wenn das mit dem weiter unten beschriebenen Draft kommt - und davon kann
man bei den Namen getrost ausgehen - dann ist das Argument auch hinf�llig.
> > wenn der lokale BIND richtig konfiguriert wurde und die Clients nirgends
> > anders anfragen als beim lokalen BIND und die searchlist in Ordnung ist.
> Das gilt aber auch f�r .so.antepoth.de. Warum also .local?
Weil sowas:
20:09:11.664523 80.145.176.207.3032 > 212.227.20.60.53: 14104+ [1au] A?
www.local. (38) (DF)
20:09:11.732774 212.227.20.60.53 > 80.145.176.207.3032: 14104 NXDomain* 0/1/1
(95) (DF)
auf einem externen Interface sowas von falsch ist, da� einem davon die
Augen brennen, wenn man das sieht. .so.antepoth.de k�nnte aber durchaus
sein - hat ja durch .de die besten Referenzen! Da fragen wir - als
"komische Software(tm)" doch gleich mal nach dem NS der beiden anderen.
Das passiert bei den Fremdnetzen, die .local nicht "erden", nicht im
eigenen! Dort hat man ja die Finger auf .local drauf und der lokale DNS
kann dar�ber kompetent Antwort geben.
Es gilt ja auch die Empfehlung, die RFC1918-Adressen im eigenen DNS zu
"erden", damit Host-unknown nicht erst durch eine Anfrage beim externen
DNS erstellt werden mu�.
> > [ 98% aller DNS-Queries bei den Root-Servern sind gaga ]
> Hm, nach fl�chtiger Durchsicht sehe ich keinen Zusammenhang. Da geht es um
> "eigenwillig" Resolver, AAAA-Records, fehlenden PTR, fragen nach Rootservern
> f�r .local und fragen nach Namen f�r RFC 1918-Adressen.
Haha - das fand ich auch hei�! .local - eine Sache, die hervorragend dazu
geeignet w�re, um DNS-Maltraffic abzufackeln, bringt die Rootserver ins
Wanken und ist Hauptursache von falschen DNS-Anfragen.
Das war als Beispiel gedacht, was passiert, wenn man den Empfehlungen
nicht so richtig folgt. (.local und rfc1918 adressen im lokalen DNS
"nullen" - wie es "anst�ndige Mitteleurop�er(tm)" f�r gemeinhin tun).
Mal aber wieder im Ernst: Beim Recherchieren heute fr�h ist mir die
RFC2606 �ber den Weg gelaufen. Dort gibt's dann in der Tat Reservierung
von von TLD-Namensr�umen f�r Test, Dokumentation, "invalid" und
"localhost".
In einem Draft[1] (!) von 02/2004 taucht dann in der Tat ".local" als
reservierter TLD-Name auf. Dieser Draft gibt aber auch Empfehlungen ab,
wie die neuen privaten Adressr�ume[2] umzusetzen sind.
t++
[1] http://files.multicastdns.org/draft-cheshire-dnsext-multicastdns.txt
[2] .intranet, .internal, .private, .corp und .home
