Re: host.conf manpage in SuSE-versau^H^H^Hesserter glibc?
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
Reply to: