Public DENIC mailinglist

[Henning Brauer <lists-denic-public-l AT bsws.de>]

Hey Curd ;-)

On Wed, May 28, 2003 at 10:22:49AM +0200, Hostmaster INTERNETX wrote: 
> auf der einen Seite sprechen wir hier von einer qualitativ hochwertigen
> DE Zone, auf der anderen Seite sollen keine technisch unsinnigen DNS-
> Checks das Leben schwer machen. Du schreibst, Du siehst keine Möglich-
> keiten, das ganze automatisiert zu testen. Aber deshalb können wir es nicht
> weglassen.

doch, wir koennen.
es tut niemandem ausser den betroffenen domains selbst (und damit 
deren inhabern) wirklich weh. Und letzteres regelt der markt.
Wenn jemand tatsaechlich nur einen DNS betreiben will - mir soll das 
egal sein; ich kaeme nicht auf die idee, aber ich habe auch keine 
nachteile davon wenn das jemand macht.

mein punkt ist eigentlich ein ganz anderer. kein test dieser welt kann 
wirklich und zuverlaessig testen ob alle DNSse nicht auf einer 
einzigen maschine liegen. und die unabhaengigkeit von routen zu testen 
ist da nicht eben einfacher.
dass der test auf verschiedene /24 vollkommen bogus ist, darin sind 
wir uns ja wohl alle einig. was soll das dann also?
in dieser diskussion wird staendig nach den argumenten _gegen_ diesen 
test gefragt. IMHO ist das die falsche Frage. Was spricht _fuer_ 
diesen test? right, rein gar nichts, weil er nichts aussagt. das taugt 
allenfalls zu blumigen marketingaussagen ("in der .de-zone wird die 
qualitatet des nameservice ueberprueft" o. ae. - bullshit.).
relevanz dieses tests: zero.
im gegenzug stoert er aber ganz gewaltig - das argument eines anderen 
posters ist recht passend. ich schicke ein update los, einer meiner 
DNSse ist dummerweise gerade mal kurz weg vom fenster, und es gibt 
eine fehlermeldung. nun habe ich das bei uns seit einigen jahren nicht 
mehr erlebt, aber es kann durchaus passieren. warum ist eine kurzzeitige 
outage eines einzigen von mehreren NSsen ein grund eine 
registrierung/ein update zu verweigern? ein tagelanger oder sogar 
dauerhafter bis in alle ewigkeiten ausfall spaeter interessiert die 
denic nicht mehr. wie erklaerst Du das Deinem Kunden dass seine 
registrierung nicht geklappt hat und er fuer ihn nicht wirklich 
verstaendliche fehlermeldungen kriegt weil dein offsite-dns im fremden 
rechenzentrum wegen routing-fuckups ausserhalb deiner reichweite grad 
mal eine minute nicht erreichbar ist? right, passiert seltenst 
(ausgenommen dreimarkfuffzich-pro-HE angeboten latuernich, you get what 
you pay for...), und right, man koennte einfach dem kunden die 
fehlermeldungen vorenthalten, aber das bekaempft symptome eines 
schwachsinnigen tests, keine ursachen.

> Ich sehe da eher den Bedarf, eine annähernd technische Lösung dafür
> zu finden, als den Check wegzulassen - wenige glücklich zu machen
> und auf den Qualitätsvorteil für viele zu verzichten.

welcher qualitaetsvorteil? das ist reine illusion!

das einzige, was vielleicht funktionieren koennte, waere ein zwang die 
NSse aehnlich wie bei CNO ueber handles zu referenzieren, und beim 
neu anlegen derselben muesste der provider angaben zu standort, 
anbindung etc bla bla machen, und nur NSse mit gleichen standort etc 
in einer domain werden rejected - eventuell muesste man da sogar 
handles fuer einen ganzen satz von NSsen machen, und die werden 
haendisch verifiziert. aber will das jemand? wohl kaum. und es gibt 
auch dann noch genug moeglichkeiten drumherum zu arbeiten, und auch 
das muesste regelmaessig neu ueberprueft werden, etc.

das funktioniert einfach nicht. anstatt hier also eine illusion von 
de facto nicht vorhandener qualitaetsueberwachung aufrechtzuerhalten 
doch bitte lieber der wahrheit ins gesicht sehen und es sein lassen.

brauchen wir wirlich noch einen beweis fuer die schwachsinnigkeit 
dieses tests? ich kann gerne die daten einer domain so umbiegen dass 
die mit drei NSsen in drei verschiedenen /24 in drei verschiedenen 
ASsen zu liegen scheint, die denic-tests mit bravour uebersteht und 
dennoch alles auf eine einzige authns-instanz auf einer einizgen 
maschine geht. bei bedarf gerne mit einem dieser NSse scheinbar in 
uebersee. und das ganze geht dann auf irgendwas schoen gammeliges. 
sparc IPX waer ne moeglichkeit. oder ich find noch was schlimmeres.
und, selbstverstaendlich, das ganze dann direkt nach dem update 
abschalten; folgenlos.
toller test, nicht?

-- 
Henning Brauer, BS Web Services, http://bsws.de
hb AT bsws.de - henning AT openbsd.org
Unix is very simple, but it takes a genius to understand the simplicity.
(Dennis Ritchie)