Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Ist das ein Ergebnis der Legalisierung von Marihuana?
2 views
Skip to first unread message
Juergen Ilse
Mar 28, 2017, 4:27:54 AM3/28/17
to
Hallo,
in einigen US-Bundesstaaten ist ja Marihuana legalisiert worden. Ist diese
absolut hirnkranke Idee:
https://www.icann.org/resources/pages/name-collision-2013-12-06-en
ein Ergebnis dieser Legalisierung? Oder kam diese hirnverbrannte Idee von
irgendwelchen anderen wahnsinnigen? Das ist doch absolut krank. Wenn nun
ein Kunde durch irgend etwas (z.B. Betrieb seines Rechners hinter einer
Fritzbox oder einem Speedtouch DSL Router) einen Eintrag fuer eine nicht
weltweit delegierte Domain wie "fritz.box" oder "speedtouch.ip" oder der-
gleichen in seinen Domain Searchpatch gebastelt hat und das beim Betrieb
des Rechners an anderer Stelle nicht korrigiert hat, dann landen bei seinem
DNS Provider (der ueberhaupt nichts dafuer kann) die Anfragen, warum denn
dies und jenes nicht funktioniert (weil z.B. der Name "meinserver.fritz.box"
nicht wie bisher zu "gibt es nicht" aufgeloest wird und dann mit dem naechs-
ten Eintrag im Searchpath weiterprobiert wird, sondern der ungueltige Name
nun von den Root-Servern zu 127.0.53.53 aufgeloest wird). Wer hat sich nur
diesen elenden Schwachsinn ausgedacht??? Kam man diesen Idioten nicht mal
die Drogen wegnehmen? Ich war jedenfalls gar nicht amuesiert, als ich diesen
hahnebuechenen Unsinn heute debuggen musste!
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
PS: Und dass dieser Dreck nun auch noch mit "Stabilitaet des Internet"
begruendet wird, schlaegt ja wirklich dem Fass den Boden aus!
in einigen US-Bundesstaaten ist ja Marihuana legalisiert worden. Ist diese
absolut hirnkranke Idee:
https://www.icann.org/resources/pages/name-collision-2013-12-06-en
ein Ergebnis dieser Legalisierung? Oder kam diese hirnverbrannte Idee von
irgendwelchen anderen wahnsinnigen? Das ist doch absolut krank. Wenn nun
ein Kunde durch irgend etwas (z.B. Betrieb seines Rechners hinter einer
Fritzbox oder einem Speedtouch DSL Router) einen Eintrag fuer eine nicht
weltweit delegierte Domain wie "fritz.box" oder "speedtouch.ip" oder der-
gleichen in seinen Domain Searchpatch gebastelt hat und das beim Betrieb
des Rechners an anderer Stelle nicht korrigiert hat, dann landen bei seinem
DNS Provider (der ueberhaupt nichts dafuer kann) die Anfragen, warum denn
dies und jenes nicht funktioniert (weil z.B. der Name "meinserver.fritz.box"
nicht wie bisher zu "gibt es nicht" aufgeloest wird und dann mit dem naechs-
ten Eintrag im Searchpath weiterprobiert wird, sondern der ungueltige Name
nun von den Root-Servern zu 127.0.53.53 aufgeloest wird). Wer hat sich nur
diesen elenden Schwachsinn ausgedacht??? Kam man diesen Idioten nicht mal
die Drogen wegnehmen? Ich war jedenfalls gar nicht amuesiert, als ich diesen
hahnebuechenen Unsinn heute debuggen musste!
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
PS: Und dass dieser Dreck nun auch noch mit "Stabilitaet des Internet"
begruendet wird, schlaegt ja wirklich dem Fass den Boden aus!
Juergen P. Meier
Mar 29, 2017, 12:35:29 AM3/29/17
to
Juergen Ilse <il...@greenwood.usenet-verwaltung.de>:
aufspannen?
> Hallo,
>
> in einigen US-Bundesstaaten ist ja Marihuana legalisiert worden. Ist diese
> absolut hirnkranke Idee:
>
> https://www.icann.org/resources/pages/name-collision-2013-12-06-en
>
> ein Ergebnis dieser Legalisierung? Oder kam diese hirnverbrannte Idee von
> irgendwelchen anderen wahnsinnigen? Das ist doch absolut krank. Wenn nun
> ein Kunde durch irgend etwas (z.B. Betrieb seines Rechners hinter einer
> Fritzbox oder einem Speedtouch DSL Router) einen Eintrag fuer eine nicht
> weltweit delegierte Domain wie "fritz.box" oder "speedtouch.ip" oder der-
> gleichen in seinen Domain Searchpatch gebastelt hat und das beim Betrieb
> des Rechners an anderer Stelle nicht korrigiert hat, dann landen bei seinem
> DNS Provider (der ueberhaupt nichts dafuer kann) die Anfragen, warum denn
> dies und jenes nicht funktioniert (weil z.B. der Name "meinserver.fritz.box"
> nicht wie bisher zu "gibt es nicht" aufgeloest wird und dann mit dem naechs-
> ten Eintrag im Searchpath weiterprobiert wird, sondern der ungueltige Name
> nun von den Root-Servern zu 127.0.53.53 aufgeloest wird). Wer hat sich nur
> diesen elenden Schwachsinn ausgedacht??? Kam man diesen Idioten nicht mal
> die Drogen wegnehmen? Ich war jedenfalls gar nicht amuesiert, als ich diesen
> hahnebuechenen Unsinn heute debuggen musste!
Koennen wir bitte eine NEUE, SINNVOLLE und KORRUPTIONSFREIE Root-Zone
>
> in einigen US-Bundesstaaten ist ja Marihuana legalisiert worden. Ist diese
> absolut hirnkranke Idee:
>
> https://www.icann.org/resources/pages/name-collision-2013-12-06-en
>
> ein Ergebnis dieser Legalisierung? Oder kam diese hirnverbrannte Idee von
> irgendwelchen anderen wahnsinnigen? Das ist doch absolut krank. Wenn nun
> ein Kunde durch irgend etwas (z.B. Betrieb seines Rechners hinter einer
> Fritzbox oder einem Speedtouch DSL Router) einen Eintrag fuer eine nicht
> weltweit delegierte Domain wie "fritz.box" oder "speedtouch.ip" oder der-
> gleichen in seinen Domain Searchpatch gebastelt hat und das beim Betrieb
> des Rechners an anderer Stelle nicht korrigiert hat, dann landen bei seinem
> DNS Provider (der ueberhaupt nichts dafuer kann) die Anfragen, warum denn
> dies und jenes nicht funktioniert (weil z.B. der Name "meinserver.fritz.box"
> nicht wie bisher zu "gibt es nicht" aufgeloest wird und dann mit dem naechs-
> ten Eintrag im Searchpath weiterprobiert wird, sondern der ungueltige Name
> nun von den Root-Servern zu 127.0.53.53 aufgeloest wird). Wer hat sich nur
> diesen elenden Schwachsinn ausgedacht??? Kam man diesen Idioten nicht mal
> die Drogen wegnehmen? Ich war jedenfalls gar nicht amuesiert, als ich diesen
> hahnebuechenen Unsinn heute debuggen musste!
aufspannen?
Juergen Ilse
Mar 29, 2017, 2:58:47 AM3/29/17
to
Hallo,
Juergen P. Meier <nospa...@jors.net> wrote:
> Juergen Ilse <il...@greenwood.usenet-verwaltung.de>:
Nach durchlesen der Realisierung dieser Schnapsidee muss ich mich *etwas*
korrigieren: das Vorgehen mit den Wildcard-Records betrifft nur TLDs, die
"demnaechst" ihren neuen Betrieb aufnehmen. Trotzdem sollte die ICANN (wenn
sie sich schon in die Inhalte der TLD-Zonen einmischt) das gefaelligst in
*sinnvoller* Weise tun: In TLD-Zonen *grundsaetzlich* keine Wildcard-Records,
und diesen ganzen Dreck mit "DNS-Admins auf moegliche Namenskollisionen
hinweisen" komüplett ersatzlos entsorgen. Wer meint in fremden Namensraeumen
wildern zu muessen, hat den daraus resultierenden Aerger redlich verdient
(und das betrifft auch die Hersteller von DSL-Routern wie fritzbox oder auch
speedtouch mit ihren illegal verwendeten .box und .ip TLDs). Ausserdem soll-
te man versisign die Kontrolle ueber die .com Zone entziehen, wenn die immer
noch den Wildcard-Record fuer nicht delegierte com Domains auf ihren eigenen
Registrierungsservice gesetzt haben sollten. Das waeren vernueftige Mass-
nahmen aber nicht dieser elende Dreck, denn sie da implementiert haben.
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
Juergen P. Meier <nospa...@jors.net> wrote:
> Juergen Ilse <il...@greenwood.usenet-verwaltung.de>:
korrigieren: das Vorgehen mit den Wildcard-Records betrifft nur TLDs, die
"demnaechst" ihren neuen Betrieb aufnehmen. Trotzdem sollte die ICANN (wenn
sie sich schon in die Inhalte der TLD-Zonen einmischt) das gefaelligst in
*sinnvoller* Weise tun: In TLD-Zonen *grundsaetzlich* keine Wildcard-Records,
und diesen ganzen Dreck mit "DNS-Admins auf moegliche Namenskollisionen
hinweisen" komüplett ersatzlos entsorgen. Wer meint in fremden Namensraeumen
wildern zu muessen, hat den daraus resultierenden Aerger redlich verdient
(und das betrifft auch die Hersteller von DSL-Routern wie fritzbox oder auch
speedtouch mit ihren illegal verwendeten .box und .ip TLDs). Ausserdem soll-
te man versisign die Kontrolle ueber die .com Zone entziehen, wenn die immer
noch den Wildcard-Record fuer nicht delegierte com Domains auf ihren eigenen
Registrierungsservice gesetzt haben sollten. Das waeren vernueftige Mass-
nahmen aber nicht dieser elende Dreck, denn sie da implementiert haben.
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
Juergen P. Meier
Mar 29, 2017, 3:46:26 AM3/29/17
to
Juergen Ilse <il...@greenwood.usenet-verwaltung.de>:
> sie sich schon in die Inhalte der TLD-Zonen einmischt) das gefaelligst in
> *sinnvoller* Weise tun: In TLD-Zonen *grundsaetzlich* keine Wildcard-Records,
> und diesen ganzen Dreck mit "DNS-Admins auf moegliche Namenskollisionen
> hinweisen" komüplett ersatzlos entsorgen. Wer meint in fremden Namensraeumen
> wildern zu muessen, hat den daraus resultierenden Aerger redlich verdient
> (und das betrifft auch die Hersteller von DSL-Routern wie fritzbox oder auch
> speedtouch mit ihren illegal verwendeten .box und .ip TLDs). Ausserdem soll-
> te man versisign die Kontrolle ueber die .com Zone entziehen, wenn die immer
> noch den Wildcard-Record fuer nicht delegierte com Domains auf ihren eigenen
> Registrierungsservice gesetzt haben sollten. Das waeren vernueftige Mass-
> nahmen aber nicht dieser elende Dreck, denn sie da implementiert haben.
ACK.
Gibts irgendwo eine komplette Liste fuer den eigenen Resolver zum Blacklisten?
Diesen Fuck-UP von ICANN fixen geht damit dann einfach (z.B. BIND):
#ICANN fuckup:
zone "box." {
type master;
file "nxdomain.db";
notify no;
};
Mit zonefile nxdomain.db:
@ IN SOA my.resolver.tld. hostmaster.localhost. ( 1 2H 4H 4D 1H )
@ 4H IN NS my.resolver.tld.
Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)
> Nach durchlesen der Realisierung dieser Schnapsidee muss ich mich *etwas*
> korrigieren: das Vorgehen mit den Wildcard-Records betrifft nur TLDs, die
> "demnaechst" ihren neuen Betrieb aufnehmen. Trotzdem sollte die ICANN (wenn
.box?
> korrigieren: das Vorgehen mit den Wildcard-Records betrifft nur TLDs, die
> "demnaechst" ihren neuen Betrieb aufnehmen. Trotzdem sollte die ICANN (wenn
> sie sich schon in die Inhalte der TLD-Zonen einmischt) das gefaelligst in
> *sinnvoller* Weise tun: In TLD-Zonen *grundsaetzlich* keine Wildcard-Records,
> und diesen ganzen Dreck mit "DNS-Admins auf moegliche Namenskollisionen
> hinweisen" komüplett ersatzlos entsorgen. Wer meint in fremden Namensraeumen
> wildern zu muessen, hat den daraus resultierenden Aerger redlich verdient
> (und das betrifft auch die Hersteller von DSL-Routern wie fritzbox oder auch
> speedtouch mit ihren illegal verwendeten .box und .ip TLDs). Ausserdem soll-
> te man versisign die Kontrolle ueber die .com Zone entziehen, wenn die immer
> noch den Wildcard-Record fuer nicht delegierte com Domains auf ihren eigenen
> Registrierungsservice gesetzt haben sollten. Das waeren vernueftige Mass-
> nahmen aber nicht dieser elende Dreck, denn sie da implementiert haben.
Gibts irgendwo eine komplette Liste fuer den eigenen Resolver zum Blacklisten?
Diesen Fuck-UP von ICANN fixen geht damit dann einfach (z.B. BIND):
#ICANN fuckup:
zone "box." {
type master;
file "nxdomain.db";
notify no;
};
Mit zonefile nxdomain.db:
@ IN SOA my.resolver.tld. hostmaster.localhost. ( 1 2H 4H 4D 1H )
@ 4H IN NS my.resolver.tld.
Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)
Juergen Ilse
Mar 29, 2017, 5:02:31 AM3/29/17
to
> .box?
Ja, die geht wohl demnaechst in den Regelbetrieb ueber, weshalb jetzt
aktuell diese seltsamen wildcard-records gesetzt sind (A-record auf
127.0.53.53, TXT und einige SRV records auf einen String, der darauf
hinweist, man moege seine DNS-Konfiguration ueberpruefen).
> Gibts irgendwo eine komplette Liste fuer den eigenen Resolver zum Blacklisten?
Das aendert sich wohl dauernd. Bei jeder neuen TLD wird sie wohl fuer
mindestens 90 Tage mit diesen wildcard records bestueckt, bevor sie in
den Regelbetrieb uebergeht, wenn ich das Dokument dazu richtig verstanden
habe ...
https://www.icann.org/en/system/files/files/name-collision-framework-30jul14-en.pdf
> Diesen Fuck-UP von ICANN fixen geht damit dann einfach (z.B. BIND):
>
> #ICANN fuckup:
> zone "box." {
> type master;
> file "nxdomain.db";
> notify no;
> };
>
> Mit zonefile nxdomain.db:
>
> @ IN SOA my.resolver.tld. hostmaster.localhost. ( 1 2H 4H 4D 1H )
> @ 4H IN NS my.resolver.tld.
Da muesstest du wohl dauern am fixen dran bleiben, und ich bezweifle, dass
du ímmer eine tagesaktuelle Liste der betroffenen Domains finden wirst ...
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
Ja, die geht wohl demnaechst in den Regelbetrieb ueber, weshalb jetzt
aktuell diese seltsamen wildcard-records gesetzt sind (A-record auf
127.0.53.53, TXT und einige SRV records auf einen String, der darauf
hinweist, man moege seine DNS-Konfiguration ueberpruefen).
> Gibts irgendwo eine komplette Liste fuer den eigenen Resolver zum Blacklisten?
mindestens 90 Tage mit diesen wildcard records bestueckt, bevor sie in
den Regelbetrieb uebergeht, wenn ich das Dokument dazu richtig verstanden
habe ...
https://www.icann.org/en/system/files/files/name-collision-framework-30jul14-en.pdf
> Diesen Fuck-UP von ICANN fixen geht damit dann einfach (z.B. BIND):
>
> #ICANN fuckup:
> zone "box." {
> type master;
> file "nxdomain.db";
> notify no;
> };
>
> Mit zonefile nxdomain.db:
>
> @ IN SOA my.resolver.tld. hostmaster.localhost. ( 1 2H 4H 4D 1H )
> @ 4H IN NS my.resolver.tld.
du ímmer eine tagesaktuelle Liste der betroffenen Domains finden wirst ...
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
Juergen Ilse
Mar 29, 2017, 5:07:39 AM3/29/17
to
Ach ja, erwaehnte ich schon, fuer was fuer einen hahnebuechenen Unsinn ich
die neuen gTLDs ueberhaupt halte? Musste man denn das DNS-System von einem
Baum unbedingt auf etwas mit der Struktur eines Rasens (was die Breite
angeht) umbauen? Muss man denn unbedingt die root-Server mit aller Gewalt
in die Knie zu zwingen versuchen? Das cachen der TLD-Eintraege funktioniert
sehr gut (was die root-Server entlastet), solange es maximal ein paar hundert
TLDs sind, aber wenn es zigtausende TLDs gibt, skaliert das System nicht mehr,
weil kaum ein Nameserver von allen zigtausend TLDs immer alle Daten gecached
halten wird ...
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
PS: hoffentlich finden diese Vollidioten nicht noch eine Moeglichkeit, den
gesamten DNS-"Baum" auf eine maximal-Tiefe von 1 zu reduzieren ...
die neuen gTLDs ueberhaupt halte? Musste man denn das DNS-System von einem
Baum unbedingt auf etwas mit der Struktur eines Rasens (was die Breite
angeht) umbauen? Muss man denn unbedingt die root-Server mit aller Gewalt
in die Knie zu zwingen versuchen? Das cachen der TLD-Eintraege funktioniert
sehr gut (was die root-Server entlastet), solange es maximal ein paar hundert
TLDs sind, aber wenn es zigtausende TLDs gibt, skaliert das System nicht mehr,
weil kaum ein Nameserver von allen zigtausend TLDs immer alle Daten gecached
halten wird ...
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
PS: hoffentlich finden diese Vollidioten nicht noch eine Moeglichkeit, den
gesamten DNS-"Baum" auf eine maximal-Tiefe von 1 zu reduzieren ...
frank paulsen
Mar 29, 2017, 6:34:09 AM3/29/17
to
Juergen Ilse <il...@greenwood.usenet-verwaltung.de> writes:
> Ach ja, erwaehnte ich schon, fuer was fuer einen hahnebuechenen Unsinn ich
> die neuen gTLDs ueberhaupt halte? Musste man denn das DNS-System von einem
> Baum unbedingt auf etwas mit der Struktur eines Rasens (was die Breite
> angeht) umbauen? Muss man denn unbedingt die root-Server mit aller Gewalt
> in die Knie zu zwingen versuchen? Das cachen der TLD-Eintraege funktioniert
> sehr gut (was die root-Server entlastet), solange es maximal ein paar hundert
> TLDs sind, aber wenn es zigtausende TLDs gibt, skaliert das System nicht mehr,
> weil kaum ein Nameserver von allen zigtausend TLDs immer alle Daten gecached
> halten wird ...
um das zu cachen braucht man, nicht komplett verrueckte software
> Ach ja, erwaehnte ich schon, fuer was fuer einen hahnebuechenen Unsinn ich
> die neuen gTLDs ueberhaupt halte? Musste man denn das DNS-System von einem
> Baum unbedingt auf etwas mit der Struktur eines Rasens (was die Breite
> angeht) umbauen? Muss man denn unbedingt die root-Server mit aller Gewalt
> in die Knie zu zwingen versuchen? Das cachen der TLD-Eintraege funktioniert
> sehr gut (was die root-Server entlastet), solange es maximal ein paar hundert
> TLDs sind, aber wenn es zigtausende TLDs gibt, skaliert das System nicht mehr,
> weil kaum ein Nameserver von allen zigtausend TLDs immer alle Daten gecached
> halten wird ...
vorausgesetzt, ein paar bis ein paar zig GB. wenn man nicht gerade alte
Sun-hardware als DNS-cache missbraucht, sondern was solides von Aldi
verwendet, ist das bereits seit jahren kein ding mehr.
faktisch begrenzt doch heute eher die rechenleistung (fuer DNSSEC) als
der speicher.
das aendert natuerlich nichts daran, dass die ausweitung der TLD
komische probleme erzeugt, und nicht zwingend eine gute idee ist.
da mit *speicherproblemen* zu argumentieren ist aber albern.
--
frobnicate foo
Juergen P. Meier
Mar 29, 2017, 7:14:52 AM3/29/17
to
Juergen Ilse <il...@greenwood.usenet-verwaltung.de>:
Siehe .africa
>> #ICANN fuckup:
>> zone "box." {
>> type master;
>> file "nxdomain.db";
>> notify no;
>> };
>>
>> Mit zonefile nxdomain.db:
>>
>> @ IN SOA my.resolver.tld. hostmaster.localhost. ( 1 2H 4H 4D 1H )
>> @ 4H IN NS my.resolver.tld.
>
> Da muesstest du wohl dauern am fixen dran bleiben, und ich bezweifle, dass
> du ímmer eine tagesaktuelle Liste der betroffenen Domains finden wirst ...
Oder man blendet den korrupten Sumpf einfach weiter aus.
>> zone "box." {
>> type master;
>> file "nxdomain.db";
>> notify no;
>> };
>>
>> Mit zonefile nxdomain.db:
>>
>> @ IN SOA my.resolver.tld. hostmaster.localhost. ( 1 2H 4H 4D 1H )
>> @ 4H IN NS my.resolver.tld.
>
> Da muesstest du wohl dauern am fixen dran bleiben, und ich bezweifle, dass
> du ímmer eine tagesaktuelle Liste der betroffenen Domains finden wirst ...
Siehe .africa
Juergen Ilse
Mar 29, 2017, 7:47:39 AM3/29/17
to
Hallo,
frank paulsen <frank....@gmx.net> wrote:
> Juergen Ilse <il...@greenwood.usenet-verwaltung.de> writes:
>> Ach ja, erwaehnte ich schon, fuer was fuer einen hahnebuechenen Unsinn ich
>> die neuen gTLDs ueberhaupt halte? Musste man denn das DNS-System von einem
>> Baum unbedingt auf etwas mit der Struktur eines Rasens (was die Breite
>> angeht) umbauen? Muss man denn unbedingt die root-Server mit aller Gewalt
>> in die Knie zu zwingen versuchen? Das cachen der TLD-Eintraege funktioniert
>> sehr gut (was die root-Server entlastet), solange es maximal ein paar hundert
>> TLDs sind, aber wenn es zigtausende TLDs gibt, skaliert das System nicht mehr,
>> weil kaum ein Nameserver von allen zigtausend TLDs immer alle Daten gecached
>> halten wird ...
> um das zu cachen braucht man, nicht komplett verrueckte software
> vorausgesetzt, ein paar bis ein paar zig GB. wenn man nicht gerade alte
> Sun-hardware als DNS-cache missbraucht, sondern was solides von Aldi
> verwendet, ist das bereits seit jahren kein ding mehr.
Faktisch cached ein caching DNS aber nicht nut TLDs (noch nicht einmal
bevorzugt TLDs), so dass die zusaetzliche Menge an TLDs durchaus zu mehr
Anfragen und die root-Server fuehren wird, weil cache-Eintraege fuer TLDs
aus dem cache fliegen (und nein, ich halte eine zuversichtliche "ich muss
die cache-groesse nicht begrenzen, das passt scho ..." Konfiguration nicht
fuer eine gute Idee, wenn es sich z.B. um einen vom ISP fuer Kunden bereit
gestellter caching resolver ist ...).
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
frank paulsen <frank....@gmx.net> wrote:
> Juergen Ilse <il...@greenwood.usenet-verwaltung.de> writes:
>> Ach ja, erwaehnte ich schon, fuer was fuer einen hahnebuechenen Unsinn ich
>> die neuen gTLDs ueberhaupt halte? Musste man denn das DNS-System von einem
>> Baum unbedingt auf etwas mit der Struktur eines Rasens (was die Breite
>> angeht) umbauen? Muss man denn unbedingt die root-Server mit aller Gewalt
>> in die Knie zu zwingen versuchen? Das cachen der TLD-Eintraege funktioniert
>> sehr gut (was die root-Server entlastet), solange es maximal ein paar hundert
>> TLDs sind, aber wenn es zigtausende TLDs gibt, skaliert das System nicht mehr,
>> weil kaum ein Nameserver von allen zigtausend TLDs immer alle Daten gecached
>> halten wird ...
> um das zu cachen braucht man, nicht komplett verrueckte software
> vorausgesetzt, ein paar bis ein paar zig GB. wenn man nicht gerade alte
> Sun-hardware als DNS-cache missbraucht, sondern was solides von Aldi
> verwendet, ist das bereits seit jahren kein ding mehr.
bevorzugt TLDs), so dass die zusaetzliche Menge an TLDs durchaus zu mehr
Anfragen und die root-Server fuehren wird, weil cache-Eintraege fuer TLDs
aus dem cache fliegen (und nein, ich halte eine zuversichtliche "ich muss
die cache-groesse nicht begrenzen, das passt scho ..." Konfiguration nicht
fuer eine gute Idee, wenn es sich z.B. um einen vom ISP fuer Kunden bereit
gestellter caching resolver ist ...).
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
Stefan Reuther
Mar 29, 2017, 12:54:21 PM3/29/17
to
mein.hamster.ihm.seine.webseite
oder
mein-hamster-ihm-seine-webseite.com
cached, ist jetzt kein Unterschied von Größenordnungen.
Aber auch das ändert nichts daran, dass die TLD-Inflation Unsinn ist.
Stefan
Juergen Ilse
Mar 31, 2017, 4:31:55 AM3/31/17
to
Hallo,
Stefan Reuther <stefa...@arcor.de> wrote:
> Naja, mal ehrlich, ob der Caching DNS nun
> mein.hamster.ihm.seine.webseite
Im Zweifelsfall zu cachen:
NS Records fuer "webseite."
NS Records fuer "seine.webseite."
NS Records fuer "ihm.seine.webseite."
NS Records fuer "hamster.im.seine.webseite."
angefragte Records fuer "mein.hamster.ihm.seine.webseite"
> oder
> mein-hamster-ihm-seine-webseite.com
> cached, ist jetzt kein Unterschied von Größenordnungen.
NS Records fuer "com."
angefragte Records fuer "mein-hamster-ihm-seine-webseite.com"
Sieht fuer mich doch nach einem deutlichen Unterschied aus ...
> Aber auch das ändert nichts daran, dass die TLD-Inflation Unsinn ist.
Da stimme ich dir auf jeden Fall zu.
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
Stefan Reuther <stefa...@arcor.de> wrote:
> Naja, mal ehrlich, ob der Caching DNS nun
> mein.hamster.ihm.seine.webseite
NS Records fuer "webseite."
NS Records fuer "seine.webseite."
NS Records fuer "ihm.seine.webseite."
NS Records fuer "hamster.im.seine.webseite."
angefragte Records fuer "mein.hamster.ihm.seine.webseite"
> oder
> mein-hamster-ihm-seine-webseite.com
> cached, ist jetzt kein Unterschied von Größenordnungen.
angefragte Records fuer "mein-hamster-ihm-seine-webseite.com"
Sieht fuer mich doch nach einem deutlichen Unterschied aus ...
> Aber auch das ändert nichts daran, dass die TLD-Inflation Unsinn ist.
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
Florian Weimer
Mar 31, 2017, 4:50:38 AM3/31/17
to
* Juergen Ilse:
> Hallo,
>
> Stefan Reuther <stefa...@arcor.de> wrote:
>> Naja, mal ehrlich, ob der Caching DNS nun
>> mein.hamster.ihm.seine.webseite
>
> Im Zweifelsfall zu cachen:
>
> NS Records fuer "webseite."
> NS Records fuer "seine.webseite."
> NS Records fuer "ihm.seine.webseite."
> NS Records fuer "hamster.im.seine.webseite."
> angefragte Records fuer "mein.hamster.ihm.seine.webseite"
>
>> oder
>> mein-hamster-ihm-seine-webseite.com
>> cached, ist jetzt kein Unterschied von Größenordnungen.
>
> NS Records fuer "com."
> angefragte Records fuer "mein-hamster-ihm-seine-webseite.com"
>
> Sieht fuer mich doch nach einem deutlichen Unterschied aus ...
So funktioniert DNS aber derzeit nicht (auch wenn das vielleicht in
der Wikipedia). Es wird immer der volle Name an alle Server geschickt,
d.h. wenn der Name in der Zone »seine.webseite« steht, kommt schon zum
zweiten Schritt die Antwort, genauso wie bei
»mein-hamster-ihm-seine-webseite.com«.
Es gibt einen Vorschlag, DNS in etwa so zu implementieren, wie Du es
beschreibst (RFC 7816), aber die Implementierung ist nicht sonderlich
verbreitet.
> Hallo,
>
> Stefan Reuther <stefa...@arcor.de> wrote:
>> Naja, mal ehrlich, ob der Caching DNS nun
>> mein.hamster.ihm.seine.webseite
>
> Im Zweifelsfall zu cachen:
>
> NS Records fuer "webseite."
> NS Records fuer "seine.webseite."
> NS Records fuer "ihm.seine.webseite."
> NS Records fuer "hamster.im.seine.webseite."
> angefragte Records fuer "mein.hamster.ihm.seine.webseite"
>
>> oder
>> mein-hamster-ihm-seine-webseite.com
>> cached, ist jetzt kein Unterschied von Größenordnungen.
>
> NS Records fuer "com."
> angefragte Records fuer "mein-hamster-ihm-seine-webseite.com"
>
> Sieht fuer mich doch nach einem deutlichen Unterschied aus ...
der Wikipedia). Es wird immer der volle Name an alle Server geschickt,
d.h. wenn der Name in der Zone »seine.webseite« steht, kommt schon zum
zweiten Schritt die Antwort, genauso wie bei
»mein-hamster-ihm-seine-webseite.com«.
Es gibt einen Vorschlag, DNS in etwa so zu implementieren, wie Du es
beschreibst (RFC 7816), aber die Implementierung ist nicht sonderlich
verbreitet.
Juergen Ilse
Mar 31, 2017, 5:51:53 AM3/31/17
to
Hallo,
Florian Weimer <f...@deneb.enyo.de> wrote:
> * Juergen Ilse:
(was ich hier einfach mal vorausgesetzt habe).
> Es wird immer der volle Name an alle Server geschickt,
Korrekt. Ich habe mich ja nur dazu geaeussert, was im Cache landet, wenn
diese Delegationen existieren, nicht darueber, wie denn die Anfragen an
die einzelnen Server aussehen.
> d.h. wenn der Name in der Zone »seine.webseite« steht, kommt schon zum
> zweiten Schritt die Antwort, genauso wie bei
> »mein-hamster-ihm-seine-webseite.com«.
Wenn aber die Delegationen alle existieren (was ich zugegebenermassen
vorausgesetzt habe, auch wenn das nicht explizit dort stand), kommt im
dabei nicht bereits im zweiten Schritt die Antwort.
> Es gibt einen Vorschlag, DNS in etwa so zu implementieren, wie Du es
> beschreibst (RFC 7816), aber die Implementierung ist nicht sonderlich
> verbreitet.
Nochmal: Ich habe *NICHTS* darueber geschrieben, welche Anfragen gestellt
werden, sondern nur aufgezaehlt, welche Records bei den Abfragen zurueck-
kommen, wenn denn fuer jeden Level eigene DNS-Server existieren (und diese
Records landen dann alle im Cache).
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
Florian Weimer <f...@deneb.enyo.de> wrote:
> * Juergen Ilse:
>> Stefan Reuther <stefa...@arcor.de> wrote:
>>> Naja, mal ehrlich, ob der Caching DNS nun
>>> mein.hamster.ihm.seine.webseite
>> Im Zweifelsfall zu cachen:
>>
>> NS Records fuer "webseite."
>> NS Records fuer "seine.webseite."
>> NS Records fuer "ihm.seine.webseite."
>> NS Records fuer "hamster.im.seine.webseite."
>> angefragte Records fuer "mein.hamster.ihm.seine.webseite"
>>
>>> oder
>>> mein-hamster-ihm-seine-webseite.com
>>> cached, ist jetzt kein Unterschied von Größenordnungen.
>>
>> NS Records fuer "com."
>> angefragte Records fuer "mein-hamster-ihm-seine-webseite.com"
>>
>> Sieht fuer mich doch nach einem deutlichen Unterschied aus ...
>
> So funktioniert DNS aber derzeit nicht (auch wenn das vielleicht in
> der Wikipedia).
Son funktiert DNS schon, wenn denn diese Delegationen alle vorhanden sind
>>> Naja, mal ehrlich, ob der Caching DNS nun
>>> mein.hamster.ihm.seine.webseite
>> Im Zweifelsfall zu cachen:
>>
>> NS Records fuer "webseite."
>> NS Records fuer "seine.webseite."
>> NS Records fuer "ihm.seine.webseite."
>> NS Records fuer "hamster.im.seine.webseite."
>> angefragte Records fuer "mein.hamster.ihm.seine.webseite"
>>
>>> oder
>>> mein-hamster-ihm-seine-webseite.com
>>> cached, ist jetzt kein Unterschied von Größenordnungen.
>>
>> NS Records fuer "com."
>> angefragte Records fuer "mein-hamster-ihm-seine-webseite.com"
>>
>> Sieht fuer mich doch nach einem deutlichen Unterschied aus ...
>
> So funktioniert DNS aber derzeit nicht (auch wenn das vielleicht in
> der Wikipedia).
(was ich hier einfach mal vorausgesetzt habe).
> Es wird immer der volle Name an alle Server geschickt,
diese Delegationen existieren, nicht darueber, wie denn die Anfragen an
die einzelnen Server aussehen.
> d.h. wenn der Name in der Zone »seine.webseite« steht, kommt schon zum
> zweiten Schritt die Antwort, genauso wie bei
> »mein-hamster-ihm-seine-webseite.com«.
vorausgesetzt habe, auch wenn das nicht explizit dort stand), kommt im
dabei nicht bereits im zweiten Schritt die Antwort.
> Es gibt einen Vorschlag, DNS in etwa so zu implementieren, wie Du es
> beschreibst (RFC 7816), aber die Implementierung ist nicht sonderlich
> verbreitet.
werden, sondern nur aufgezaehlt, welche Records bei den Abfragen zurueck-
kommen, wenn denn fuer jeden Level eigene DNS-Server existieren (und diese
Records landen dann alle im Cache).
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
Stefan Reuther
Mar 31, 2017, 11:44:47 AM3/31/17
to
Am 31.03.2017 um 11:51 schrieb Juergen Ilse:
> Florian Weimer <f...@deneb.enyo.de> wrote:
>> * Juergen Ilse:
>>> Stefan Reuther <stefa...@arcor.de> wrote:
>>>> Naja, mal ehrlich, ob der Caching DNS nun
>>>> mein.hamster.ihm.seine.webseite
>>> Im Zweifelsfall zu cachen:
>>>
>>> NS Records fuer "webseite."
>>> NS Records fuer "seine.webseite."
>>> NS Records fuer "ihm.seine.webseite."
>>> NS Records fuer "hamster.im.seine.webseite."
>>> angefragte Records fuer "mein.hamster.ihm.seine.webseite"
>>>
>>>> oder
>>>> mein-hamster-ihm-seine-webseite.com
>>>> cached, ist jetzt kein Unterschied von Größenordnungen.
>>>
>>> NS Records fuer "com."
>>> angefragte Records fuer "mein-hamster-ihm-seine-webseite.com"
>>>
>>> Sieht fuer mich doch nach einem deutlichen Unterschied aus ...
>>
>> So funktioniert DNS aber derzeit nicht (auch wenn das vielleicht in
>> der Wikipedia).
>
> Son funktiert DNS schon, wenn denn diese Delegationen alle vorhanden sind
> (was ich hier einfach mal vorausgesetzt habe).
Das dürfte aber in der Realität einfach mal nicht passieren.
> Florian Weimer <f...@deneb.enyo.de> wrote:
>> * Juergen Ilse:
>>> Stefan Reuther <stefa...@arcor.de> wrote:
>>>> Naja, mal ehrlich, ob der Caching DNS nun
>>>> mein.hamster.ihm.seine.webseite
>>> Im Zweifelsfall zu cachen:
>>>
>>> NS Records fuer "webseite."
>>> NS Records fuer "seine.webseite."
>>> NS Records fuer "ihm.seine.webseite."
>>> NS Records fuer "hamster.im.seine.webseite."
>>> angefragte Records fuer "mein.hamster.ihm.seine.webseite"
>>>
>>>> oder
>>>> mein-hamster-ihm-seine-webseite.com
>>>> cached, ist jetzt kein Unterschied von Größenordnungen.
>>>
>>> NS Records fuer "com."
>>> angefragte Records fuer "mein-hamster-ihm-seine-webseite.com"
>>>
>>> Sieht fuer mich doch nach einem deutlichen Unterschied aus ...
>>
>> So funktioniert DNS aber derzeit nicht (auch wenn das vielleicht in
>> der Wikipedia).
>
> Son funktiert DNS schon, wenn denn diese Delegationen alle vorhanden sind
> (was ich hier einfach mal vorausgesetzt habe).
Zumindest halte ich für unwahrscheinlich, dass der Registrar von
"webseite." an einen Groß-ISP delegiert, der "seine.webseite.", dessen
Kunde Klein-ISP "ihm.seine.webseite." an seinen Kunden
"hamster.ihm.seine.webseite." delegiert, der wiederum im Wohnheim den
Nameserver betreibt, welcher an seine Kumpels
"mein.hamster.ihm.seine.webseite." und
"dein.hamster.ihm.seine.webseite." verweist. Da wird schon eher die
flache Datenbank konsultiert.
>> Es wird immer der volle Name an alle Server geschickt,
>
> Korrekt. Ich habe mich ja nur dazu geaeussert, was im Cache landet, wenn
> diese Delegationen existieren, nicht darueber, wie denn die Anfragen an
> die einzelnen Server aussehen.
normale .com per CNAME auf kundennr.stadt.bundesland.land.provider.de
umleiten und da auf jeder Hierarchiestufe delegieren.
Stefan
Juergen Ilse
Apr 1, 2017, 2:56:53 AM4/1/17
to
> Am 31.03.2017 um 11:51 schrieb Juergen Ilse:
>> Florian Weimer <f...@deneb.enyo.de> wrote:
>>> * Juergen Ilse:
>>>> Stefan Reuther <stefa...@arcor.de> wrote:
>>>>> Naja, mal ehrlich, ob der Caching DNS nun
>>>>> mein.hamster.ihm.seine.webseite
>>>> Im Zweifelsfall zu cachen:
>>>> NS Records fuer "webseite."
>>>> NS Records fuer "seine.webseite."
>>>> NS Records fuer "ihm.seine.webseite."
>>>> NS Records fuer "hamster.im.seine.webseite."
>>>> angefragte Records fuer "mein.hamster.ihm.seine.webseite"
>>>>> oder
>>>>> mein-hamster-ihm-seine-webseite.com
>>>>> cached, ist jetzt kein Unterschied von Größenordnungen.
>>>> NS Records fuer "com."
>>>> angefragte Records fuer "mein-hamster-ihm-seine-webseite.com"
>>>> Sieht fuer mich doch nach einem deutlichen Unterschied aus ...
>>> So funktioniert DNS aber derzeit nicht (auch wenn das vielleicht in
>>> der Wikipedia).
>> Son funktiert DNS schon, wenn denn diese Delegationen alle vorhanden sind
>> (was ich hier einfach mal vorausgesetzt habe).
> Das dürfte aber in der Realität einfach mal nicht passieren.
Das sehe ich anders.
>> Florian Weimer <f...@deneb.enyo.de> wrote:
>>> * Juergen Ilse:
>>>> Stefan Reuther <stefa...@arcor.de> wrote:
>>>>> Naja, mal ehrlich, ob der Caching DNS nun
>>>>> mein.hamster.ihm.seine.webseite
>>>> Im Zweifelsfall zu cachen:
>>>> NS Records fuer "webseite."
>>>> NS Records fuer "seine.webseite."
>>>> NS Records fuer "ihm.seine.webseite."
>>>> NS Records fuer "hamster.im.seine.webseite."
>>>> angefragte Records fuer "mein.hamster.ihm.seine.webseite"
>>>>> oder
>>>>> mein-hamster-ihm-seine-webseite.com
>>>>> cached, ist jetzt kein Unterschied von Größenordnungen.
>>>> NS Records fuer "com."
>>>> angefragte Records fuer "mein-hamster-ihm-seine-webseite.com"
>>>> Sieht fuer mich doch nach einem deutlichen Unterschied aus ...
>>> So funktioniert DNS aber derzeit nicht (auch wenn das vielleicht in
>>> der Wikipedia).
>> Son funktiert DNS schon, wenn denn diese Delegationen alle vorhanden sind
>> (was ich hier einfach mal vorausgesetzt habe).
> Das dürfte aber in der Realität einfach mal nicht passieren.
> Zumindest halte ich für unwahrscheinlich, dass der Registrar von
> "webseite." an einen Groß-ISP delegiert, der "seine.webseite.", dessen
> Kunde Klein-ISP "ihm.seine.webseite." an seinen Kunden
> "hamster.ihm.seine.webseite." delegiert, der wiederum im Wohnheim den
> Nameserver betreibt, welcher an seine Kumpels
> "mein.hamster.ihm.seine.webseite." und
> "dein.hamster.ihm.seine.webseite." verweist. Da wird schon eher die
> flache Datenbank konsultiert.
(aber frag jetzt nicht nach dem Domainnamen, den habe ich mittlerweile ver-
gessen). Abgesehen davon ging es in dieser Diskussion eigentlich nicht um
die Tiefe des DNS-Baums sondern eher um die Breite. Und es geht nicht um
die Caches der Root-Server sondern um die Caches der rekursiven resolver
(denn wenn bei denen records aus der root-zone aus dem cache rausfliegen,
bedeutet das mehr Anfragen an die RootServer, und die Wahrscheinlichkeit,
dass so etwas passiert, steigt mit der Groesse der rootzone, spaetestens
dann, wenn die rootzone statt frueher <200 irgendwann mal >20.000 Domains
beinhaltet).
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
0 new messages