Ist das ein Ergebnis der Legalisierung von Marihuana?

Discussion:

(zu alt für eine Antwort)

Juergen Ilse

2017-03-28 08:27:53 UTC

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 (***@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

2017-03-29 04:34:40 UTC

Permalink

Post by Juergen Ilse
Hallo,
in einigen US-Bundesstaaten ist ja Marihuana legalisiert worden. Ist diese
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
aufspannen?

Juergen Ilse

2017-03-29 06:58:46 UTC

Permalink

Hallo,

Post by Juergen P. Meier

Post by Juergen Ilse
in einigen US-Bundesstaaten ist ja Marihuana legalisiert worden. Ist diese
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
aufspannen?

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 (***@usenet-verwaltung.de)

Juergen P. Meier

2017-03-29 07:35:06 UTC

Permalink

Post by Juergen Ilse
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?

Post by Juergen Ilse
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)

Juergen Ilse

2017-03-29 09:02:27 UTC

Permalink

Hallo,

Post by Juergen P. Meier
.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).

Post by Juergen P. Meier
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

Post by Juergen P. Meier
zone "box." {
type master;
file "nxdomain.db";
notify no;
};
@ 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 (***@usenet-verwaltung.de)

Juergen P. Meier

2017-03-29 11:14:22 UTC

Permalink

Post by Juergen Ilse

Post by Juergen P. Meier
zone "box." {
type master;
file "nxdomain.db";
notify no;
};
@ 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.

Siehe .africa

Juergen Ilse

2017-03-29 09:07:36 UTC

Permalink

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 (***@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

2017-03-29 10:33:40 UTC

Permalink

Post by Juergen Ilse
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 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 Ilse

2017-03-29 11:47:34 UTC

Permalink

Hallo,

Post by frank paulsen

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 (***@usenet-verwaltung.de)

Stefan Reuther

2017-03-29 16:42:18 UTC

Permalink

Post by Juergen Ilse

Post by frank paulsen

Naja, mal ehrlich, ob der Caching DNS nun
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

2017-03-31 08:31:54 UTC

Permalink

Hallo,

Post by Stefan Reuther
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"

Post by Stefan Reuther
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 ...

Post by Stefan Reuther
Aber auch das ändert nichts daran, dass die TLD-Inflation Unsinn ist.

Da stimme ich dir auf jeden Fall zu.

Tschuess,
Juergen Ilse (***@usenet-verwaltung.de)

Florian Weimer

2017-03-31 08:50:37 UTC

Permalink

Post by Juergen Ilse
Hallo,

Post by Stefan Reuther
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"

Post by Stefan Reuther
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.

Juergen Ilse

2017-03-31 09:51:49 UTC

Permalink

Hallo,

Post by Florian Weimer

Post by Juergen Ilse

Post by Stefan Reuther
Naja, mal ehrlich, ob der Caching DNS nun
mein.hamster.ihm.seine.webseite

Post by Stefan Reuther
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).

Post by Florian Weimer
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.

Post by Florian Weimer
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.

Post by Florian Weimer
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 (***@usenet-verwaltung.de)

Stefan Reuther

2017-03-31 15:41:14 UTC

Permalink

Post by Juergen Ilse

Post by Florian Weimer

Post by Juergen Ilse

Post by Stefan Reuther
Naja, mal ehrlich, ob der Caching DNS nun
mein.hamster.ihm.seine.webseite

Post by Stefan Reuther
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.

Post by Juergen Ilse

Post by Florian Weimer
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.

Naja, man kann mit DNS unendlich viel Unsinn bauen. Man kann auch eine
normale .com per CNAME auf kundennr.stadt.bundesland.land.provider.de
umleiten und da auf jeder Hierarchiestufe delegieren.

Stefan

Juergen Ilse

2017-04-01 06:56:52 UTC

Permalink

Hallo,

Post by Stefan Reuther

Post by Juergen Ilse

Post by Florian Weimer

Post by Juergen Ilse

Post by Stefan Reuther
Naja, mal ehrlich, ob der Caching DNS nun
mein.hamster.ihm.seine.webseite

Post by Stefan Reuther
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.

Post by Stefan Reuther
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.

Zumindest mit einer Ebene weniger habe ich so etwas durchaus schon gesehen
(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 (***@usenet-verwaltung.de)