info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Groups keyboard shortcuts have been updated
Dismiss
See shortcuts
Terrorgefahr durch DNS-Manipulation praktisch möglich?
3 views
Skip to first unread message
Jonas Hoppe
Sep 19, 2021, 2:27:10 PM9/19/21
to
Hallo
Mutationen im DNS der obersten Hierarchie (TLDs) könnten das Internet
imho als Ganzes grösstenteils lahmlegen.
Ist das Risiko einer solchen Manipulation gross?
Wenn nein, warum nicht?
Vielen Dank.
--
Grüsse, Jonas
---
Mutationen im DNS der obersten Hierarchie (TLDs) könnten das Internet
imho als Ganzes grösstenteils lahmlegen.
Ist das Risiko einer solchen Manipulation gross?
Wenn nein, warum nicht?
Vielen Dank.
--
Grüsse, Jonas
---
Juergen Ilse
Sep 20, 2021, 6:47:12 AM9/20/21
to
Hallo,
Jonas Hoppe <maus...@gmx.net> wrote:
> Mutationen im DNS der obersten Hierarchie (TLDs) könnten das Internet
> imho als Ganzes grösstenteils lahmlegen.
Das ist vor einigen Jhren auch schon mal passiert.DNS-Aufloesung funktionierte
dann nur noch fuer die Eintraege im Cache des verwendeten rekursiven resolvers
(und da vermutlich der DNS des Providers mehr Eintraege im Cache hat als ein
ggfs. selbst aufgesetzter privater vollwertiger DNS war es damals moeglicher-
weise ein Vorteil, den Provider DNS zu verwenden ...).
Ein Betreiber von "alternativen rootservern" wollte damals die rootserver
bei der DNS-Aufloesung durch diee eigenen ersetzen, um die Leistungsfaehig-
keit seiner Infrastruktur zu zeigen, aber bei dem Hack ging irgend etwas
schief, und es dauerte ca. 24 Stunden, bis alles wieder korrigiert war.
> Ist das Risiko einer solchen Manipulation gross?
Zumindest ist es moeglich.
> Wenn nein, warum nicht?
Mittels DNSSEC laesst sich ein solcher HACK zumindest erkennen. Allerdings
verhindert das dann nur ggfs. falsche Aufloeasungen, es ermoeglicht keine
Aufloesungen bei nicht Verfueguegbarkeit der "richtigen" Rootserver.
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
Jonas Hoppe <maus...@gmx.net> wrote:
> Mutationen im DNS der obersten Hierarchie (TLDs) könnten das Internet
> imho als Ganzes grösstenteils lahmlegen.
dann nur noch fuer die Eintraege im Cache des verwendeten rekursiven resolvers
(und da vermutlich der DNS des Providers mehr Eintraege im Cache hat als ein
ggfs. selbst aufgesetzter privater vollwertiger DNS war es damals moeglicher-
weise ein Vorteil, den Provider DNS zu verwenden ...).
Ein Betreiber von "alternativen rootservern" wollte damals die rootserver
bei der DNS-Aufloesung durch diee eigenen ersetzen, um die Leistungsfaehig-
keit seiner Infrastruktur zu zeigen, aber bei dem Hack ging irgend etwas
schief, und es dauerte ca. 24 Stunden, bis alles wieder korrigiert war.
> Ist das Risiko einer solchen Manipulation gross?
> Wenn nein, warum nicht?
Mittels DNSSEC laesst sich ein solcher HACK zumindest erkennen. Allerdings
verhindert das dann nur ggfs. falsche Aufloeasungen, es ermoeglicht keine
Aufloesungen bei nicht Verfueguegbarkeit der "richtigen" Rootserver.
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
Christian Hanné
Oct 4, 2021, 8:01:12 AM10/4/21
to
Am 19.09.2021 um 20:27 schrieb Jonas Hoppe:
> Hallo
>
> Mutationen im DNS der obersten Hierarchie (TLDs) könnten das Internet
> imho als Ganzes grösstenteils lahmlegen.
>
> Ist das Risiko einer solchen Manipulation gross?
> Wenn nein, warum nicht?
>
> Vielen Dank.
Wenn Du nur rumsurfst: Die Authentizität der Hostnamen wird noch via
> Hallo
>
> Mutationen im DNS der obersten Hierarchie (TLDs) könnten das Internet
> imho als Ganzes grösstenteils lahmlegen.
>
> Ist das Risiko einer solchen Manipulation gross?
> Wenn nein, warum nicht?
>
> Vielen Dank.
HTTPS verifiziert, insofern braucht man sich an der Stelle um Manipula-
tionen keine Gedanken machen.
Juergen Ilse
Oct 4, 2021, 9:32:39 AM10/4/21
to
Hallo,
Christian Hanné <the....@gmail.com> wrote:
> Am 19.09.2021 um 20:27 schrieb Jonas Hoppe:
>> Mutationen im DNS der obersten Hierarchie (TLDs) könnten das Internet
>> imho als Ganzes grösstenteils lahmlegen.
>>
>> Ist das Risiko einer solchen Manipulation gross?
>> Wenn nein, warum nicht?
Es hat schon einemal einen solchen Fall gegeben. Die Namensaufloesung
funktionierte da nur noch fuer die Eintraege, die noch im Cache des
verwendeten resolvers vorlagen (bis zum Ablauf der TTL verbleiben die
normalerweise im Cache, und wenn die Delegationen der TLDs nicht mehr
korrekt sind, koennen Domains, fuer die die Delegation nicht mehr per
Cache aufgeloest werden koennen, nicht mehr aufgeloest werden, auch
nicht ddie Eintraege unterhalb der jeweiligen Domain).
Da DNS Server Software i.a. staendig nachgebessert werden, um Angriffe
weniger wirksam zu machen, ud die Nameserver eigentlich immer restriktiver
konfiguriert werden (rekursive Aufloesung nur fuer die eigenen Kunden,
strikte Trennung zwischen autoritativen Servern, die *nicht* rekursiv
aufloesen und rekursiven resolvern, die fuer keine Domain authotitativ
sind), wird das Risiko immer kleiner, aber ganz auszuschliesssen ist es
wohl dennoch nicht.
>> Vielen Dank.
> Wenn Du nur rumsurfst: Die Authentizität der Hostnamen wird noch via
> HTTPS verifiziert, insofern braucht man sich an der Stelle um Manipula-
> tionen keine Gedanken machen.
Es geht nicht um die Aufloesung einzelner Hosts sondern um das lahmlegen
des gesamten weltweiten DNS durch Manipulation der root DNS (oder deren
Caches). Da spielen auch Zertifikate fuer Webseiten nicht die geriingste
Rolle. Aber DNSSEC kann genutzt werden, um zumindest keine *falschen*
DNS Eintraege zu akzeptieren, wenn denn es Maniipulationen in einer
DNSSEC gesichertwen DNS Zone gab. Es kann aber in solchen Faellen nicht
gewaehrleisten, dass die korrekte Aufloesung nach DNS Manipulationen noch
funktioniert, sondern damit koennen nur falsch signierte Antworten erkannt
werden (die dann vom entsprechenden resolver nicht mehr akzeptiert werden),
frei nach dem Motto "ein nicht funktionierende DNS Aufloesung ist immer
noch besser als eine falsche DNS Aufloesung" (u.a. aus Sicherheitsgruenden,
um z.B. Phishiing zu erschweren).
Ich denke, du hast da irgendwie die falsche Perspektive, um wirklich auf
die Frage zu antworten.
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
Christian Hanné <the....@gmail.com> wrote:
> Am 19.09.2021 um 20:27 schrieb Jonas Hoppe:
>> Mutationen im DNS der obersten Hierarchie (TLDs) könnten das Internet
>> imho als Ganzes grösstenteils lahmlegen.
>>
>> Ist das Risiko einer solchen Manipulation gross?
>> Wenn nein, warum nicht?
funktionierte da nur noch fuer die Eintraege, die noch im Cache des
verwendeten resolvers vorlagen (bis zum Ablauf der TTL verbleiben die
normalerweise im Cache, und wenn die Delegationen der TLDs nicht mehr
korrekt sind, koennen Domains, fuer die die Delegation nicht mehr per
Cache aufgeloest werden koennen, nicht mehr aufgeloest werden, auch
nicht ddie Eintraege unterhalb der jeweiligen Domain).
Da DNS Server Software i.a. staendig nachgebessert werden, um Angriffe
weniger wirksam zu machen, ud die Nameserver eigentlich immer restriktiver
konfiguriert werden (rekursive Aufloesung nur fuer die eigenen Kunden,
strikte Trennung zwischen autoritativen Servern, die *nicht* rekursiv
aufloesen und rekursiven resolvern, die fuer keine Domain authotitativ
sind), wird das Risiko immer kleiner, aber ganz auszuschliesssen ist es
wohl dennoch nicht.
>> Vielen Dank.
> Wenn Du nur rumsurfst: Die Authentizität der Hostnamen wird noch via
> HTTPS verifiziert, insofern braucht man sich an der Stelle um Manipula-
> tionen keine Gedanken machen.
des gesamten weltweiten DNS durch Manipulation der root DNS (oder deren
Caches). Da spielen auch Zertifikate fuer Webseiten nicht die geriingste
Rolle. Aber DNSSEC kann genutzt werden, um zumindest keine *falschen*
DNS Eintraege zu akzeptieren, wenn denn es Maniipulationen in einer
DNSSEC gesichertwen DNS Zone gab. Es kann aber in solchen Faellen nicht
gewaehrleisten, dass die korrekte Aufloesung nach DNS Manipulationen noch
funktioniert, sondern damit koennen nur falsch signierte Antworten erkannt
werden (die dann vom entsprechenden resolver nicht mehr akzeptiert werden),
frei nach dem Motto "ein nicht funktionierende DNS Aufloesung ist immer
noch besser als eine falsche DNS Aufloesung" (u.a. aus Sicherheitsgruenden,
um z.B. Phishiing zu erschweren).
Ich denke, du hast da irgendwie die falsche Perspektive, um wirklich auf
die Frage zu antworten.
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
Marc Haber
Oct 4, 2021, 11:39:40 AM10/4/21
to
Juergen Ilse <ne...@usenet-verwaltung.de> wrote:
>Ich denke, du hast da irgendwie die falsche Perspektive, um wirklich auf
>die Frage zu antworten.
"Christian Hanné" ist ein Troll. Einfach ignorieren.
>Ich denke, du hast da irgendwie die falsche Perspektive, um wirklich auf
>die Frage zu antworten.
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Christian Hanné
Oct 4, 2021, 11:56:42 AM10/4/21
to
Am 04.10.2021 um 17:39 schrieb Marc Haber:
> Juergen Ilse <ne...@usenet-verwaltung.de> wrote:
>> Ich denke, du hast da irgendwie die falsche Perspektive, um wirklich auf
>> die Frage zu antworten.
>
> "Christian Hanné" ist ein Troll. Einfach ignorieren.
Was war jetzt bitte an dem was ich sagte Trollerei ?
> Juergen Ilse <ne...@usenet-verwaltung.de> wrote:
>> Ich denke, du hast da irgendwie die falsche Perspektive, um wirklich auf
>> die Frage zu antworten.
>
> "Christian Hanné" ist ein Troll. Einfach ignorieren.
Juergen Ilse
Oct 4, 2021, 1:56:18 PM10/4/21
to
moeglicherweise falsche Perspektive war da zwar erheblich freundlicher
und ging von einer nicht mutwillig falsch gegebenen Antwort aus, aber
deutete ansonsten in die selbe Richtung ...
DNS Manipulationen "sehr weit oben" in der DNS Hierarchie kann grosse
Teile des Internets faktisch lahmlegen. Auf TLD Ebene sogar das gesamte
Netz. Auf TLD Ebene ist das Problem dann i.d.R. nicht, dass Namen falch
aufgeloest werden, sondern dass die Aufloesung von den Root-Servern
her gar nicht mehr funktioniert. Wenn dann die angefragten Domains
nicht noch zufaellig im DNS Cache des verwendeten Resolvers stehen,
funktioniert die Namensaufloesung gar nicht mehr. Es kommen dann keine
falschen Antworten (wogegen beim "sufen" per HTTPS die Zertifikatpruefung
noch helfen wuerde, den Fehler zu erkennen, wenn auch nicht zu beheben),
sondern gar keine DNS Aufloesung mehr, wogegen eben auch kein HTTPS
helfen wuerde.
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
Marc Haber
Oct 5, 2021, 3:39:42 AM10/5/21
to
zerstört Deine sowieso nicht vorhandene Kredibilität. Du brauchst
dringend ein neues Pseudonym, das hier ist verbrannt.
Peter J. Holzer
Oct 5, 2021, 1:34:13 PM10/5/21
to
On 2021-10-04 13:32, Juergen Ilse <ne...@usenet-verwaltung.de> wrote:
> Es hat schon einemal einen solchen Fall gegeben. Die Namensaufloesung
> funktionierte da nur noch fuer die Eintraege, die noch im Cache des
> verwendeten resolvers vorlagen (bis zum Ablauf der TTL verbleiben die
> normalerweise im Cache, und wenn die Delegationen der TLDs nicht mehr
> korrekt sind, koennen Domains, fuer die die Delegation nicht mehr per
> Cache aufgeloest werden koennen, nicht mehr aufgeloest werden, auch
> nicht ddie Eintraege unterhalb der jeweiligen Domain).
Nachdem Du das jetzt binnn kurzem zum zweiten mal erwähnst: Hast Du eine
> Es hat schon einemal einen solchen Fall gegeben. Die Namensaufloesung
> funktionierte da nur noch fuer die Eintraege, die noch im Cache des
> verwendeten resolvers vorlagen (bis zum Ablauf der TTL verbleiben die
> normalerweise im Cache, und wenn die Delegationen der TLDs nicht mehr
> korrekt sind, koennen Domains, fuer die die Delegation nicht mehr per
> Cache aufgeloest werden koennen, nicht mehr aufgeloest werden, auch
> nicht ddie Eintraege unterhalb der jeweiligen Domain).
Quelle, wo man das nachlesen kann? Ich habe eine vage Erinnerung, dass
da was war, die reicht aber offenbar nicht für suchmaschinentaugliche
Stichworte.
hp
Juergen Ilse
Oct 5, 2021, 9:17:32 PM10/5/21
to
Hallo,
Peter J. Holzer <hjp-u...@hjp.at> wrote:
> On 2021-10-04 13:32, Juergen Ilse <ne...@usenet-verwaltung.de> wrote:
>> Es hat schon einemal einen solchen Fall gegeben. Die Namensaufloesung
>> funktionierte da nur noch fuer die Eintraege, die noch im Cache des
>> verwendeten resolvers vorlagen (bis zum Ablauf der TTL verbleiben die
>> normalerweise im Cache, und wenn die Delegationen der TLDs nicht mehr
>> korrekt sind, koennen Domains, fuer die die Delegation nicht mehr per
>> Cache aufgeloest werden koennen, nicht mehr aufgeloest werden, auch
>> nicht ddie Eintraege unterhalb der jeweiligen Domain).
>
> Nachdem Du das jetzt binnn kurzem zum zweiten mal erwähnst: Hast Du eine
> Quelle, wo man das nachlesen kann?
Leider ergab eine kurze Recherche von mir keinen Hinweis auf das damalige
Eeignis. IIRC ist es mehr als 10 Jahre her. Ich erinnere mich daran, weil
ich damals fuer die DNS-Server meines Arbeitgebers zustaendig war. Als
Konsequenz daraus hatte ich damals einen der beiden rekursiven DNS-Server
von den Standard Root Servern auf die alternativen Root Server des ORSN
umgestellt (was ich jedoch nach der Ankuendigung des abschaltens der ORSN
Root Server weder rueckgaengig machen musste).
Was ich jedoch gefunden habe, waren die katastrophalen Auswirkungen auf
viele Internetdienste eines grossen DNS Problems bei Amazon:
https://www.stephenwagner.com/2018/04/24/worldwide-dns-issues-failure-to-resolve-or-lookup-queries/
Diesen Vorfall habe ich allerdings nicht mehr so genau in Erinnerung.
Aber auch der Ausfall der DNS Server fuer die weltweiten Loadbalancing
Dienste kann schon fatale Folgen haben:
https://clarion.causeaction.com/2021/07/22/29000-websites-down-worldwide-on-major-dns-failure/
https://www.metalsmine.com/news/1096625-over-32000-websites-down-after-critical-akamai-dns
> Ich habe eine vage Erinnerung, dass
> da was war, die reicht aber offenbar nicht für suchmaschinentaugliche
> Stichworte.
Leider war ich da auch nicht erfolgreich. Ich versuchte zuletzt die
Suchbegriffe "root + dns + issue + worldwide" auf duckduckgo.com.
Die englische Wikipedia kennt auch noch einige Attacken auf die root Server:
https://en.wikipedia.org/wiki/Distributed_denial-of-service_attacks_on_root_nameservers
Allerdings finde ich dort niocht das, an was ich mich zu erinnern glaube,
bei dem DNS Ausfall ueber den ich geschrieben habe. Moeglicherweise ist
die Auflistung in der englischen Wikipedia nicht vollstaendig ...
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
Peter J. Holzer <hjp-u...@hjp.at> wrote:
> On 2021-10-04 13:32, Juergen Ilse <ne...@usenet-verwaltung.de> wrote:
>> Es hat schon einemal einen solchen Fall gegeben. Die Namensaufloesung
>> funktionierte da nur noch fuer die Eintraege, die noch im Cache des
>> verwendeten resolvers vorlagen (bis zum Ablauf der TTL verbleiben die
>> normalerweise im Cache, und wenn die Delegationen der TLDs nicht mehr
>> korrekt sind, koennen Domains, fuer die die Delegation nicht mehr per
>> Cache aufgeloest werden koennen, nicht mehr aufgeloest werden, auch
>> nicht ddie Eintraege unterhalb der jeweiligen Domain).
>
> Nachdem Du das jetzt binnn kurzem zum zweiten mal erwähnst: Hast Du eine
> Quelle, wo man das nachlesen kann?
Eeignis. IIRC ist es mehr als 10 Jahre her. Ich erinnere mich daran, weil
ich damals fuer die DNS-Server meines Arbeitgebers zustaendig war. Als
Konsequenz daraus hatte ich damals einen der beiden rekursiven DNS-Server
von den Standard Root Servern auf die alternativen Root Server des ORSN
umgestellt (was ich jedoch nach der Ankuendigung des abschaltens der ORSN
Root Server weder rueckgaengig machen musste).
Was ich jedoch gefunden habe, waren die katastrophalen Auswirkungen auf
viele Internetdienste eines grossen DNS Problems bei Amazon:
https://www.stephenwagner.com/2018/04/24/worldwide-dns-issues-failure-to-resolve-or-lookup-queries/
Diesen Vorfall habe ich allerdings nicht mehr so genau in Erinnerung.
Aber auch der Ausfall der DNS Server fuer die weltweiten Loadbalancing
Dienste kann schon fatale Folgen haben:
https://clarion.causeaction.com/2021/07/22/29000-websites-down-worldwide-on-major-dns-failure/
https://www.metalsmine.com/news/1096625-over-32000-websites-down-after-critical-akamai-dns
> Ich habe eine vage Erinnerung, dass
> da was war, die reicht aber offenbar nicht für suchmaschinentaugliche
> Stichworte.
Suchbegriffe "root + dns + issue + worldwide" auf duckduckgo.com.
Die englische Wikipedia kennt auch noch einige Attacken auf die root Server:
https://en.wikipedia.org/wiki/Distributed_denial-of-service_attacks_on_root_nameservers
Allerdings finde ich dort niocht das, an was ich mich zu erinnern glaube,
bei dem DNS Ausfall ueber den ich geschrieben habe. Moeglicherweise ist
die Auflistung in der englischen Wikipedia nicht vollstaendig ...
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
Laurenz Trossel
Oct 5, 2021, 10:46:51 PM10/5/21
to
On 2021-10-05, Peter J. Holzer <hjp-u...@hjp.at> wrote:
>
> Nachdem Du das jetzt binnn kurzem zum zweiten mal erwähnst: Hast Du eine
> Quelle, wo man das nachlesen kann? Ich habe eine vage Erinnerung, dass
> da was war, die reicht aber offenbar nicht für suchmaschinentaugliche
> Stichworte.
https://www.spiegel.de/netzwelt/web/ausfall-der-adresszentrale-server-crash-blockiert-viele-deutsche-webseiten-a-694551.html
>
> Nachdem Du das jetzt binnn kurzem zum zweiten mal erwähnst: Hast Du eine
> Quelle, wo man das nachlesen kann? Ich habe eine vage Erinnerung, dass
> da was war, die reicht aber offenbar nicht für suchmaschinentaugliche
> Stichworte.
https://blog.imagmbh.de/index.php/2010/05/18/dns-ausfall-der-denic-am-12-5-2010/
https://www.df.eu/blog/denic-ausfall-supportvolumen-pressenennungen/
Juergen Ilse
Oct 5, 2021, 11:01:34 PM10/5/21
to
Hallo,
Das betraf "nur" die DENIC DNS Server (und damit die TLD .de). Es ging aber
um einen Ausfall der Delegationen der Root Nameserver.
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
um einen Ausfall der Delegationen der Root Nameserver.
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
Laurenz Trossel
Oct 5, 2021, 11:25:36 PM10/5/21
to
> Das betraf "nur" die DENIC DNS Server (und damit die TLD .de). Es ging aber
> um einen Ausfall der Delegationen der Root Nameserver.
Ich denke, daß du dich da falsch erinnerst. Es gab diverse
> um einen Ausfall der Delegationen der Root Nameserver.
Beeinträchtigungen der Root-Dienste aber keine kompletten Ausfälle.
https://de.wikipedia.org/wiki/Root-Nameserver#Ausfallsicherheit_und_Angriffe
https://en.wikipedia.org/wiki/Distributed_denial-of-service_attacks_on_root_nameservers
Nicht genannt ist ein weiterer Vorfall, bei dem die in China liegenden Root
Nameserver auch von Netzen außerhalb Chinas bevorzugt wurde, was zu
Ausfällen durch chinesische DNS-Filter führte. Das betraf aber eher
West-USA und keine deutschen Nutzer.
https://blogs.oracle.com/internetintelligence/accidentally-importing-censorship
https://archive.nanog.org/meetings/nanog49/presentations/Tuesday/Madory-I-root-lightning-talk.pdf
Die Root-Zone per RFC 7706 auf den eigenen Resolvern zu spiegeln, ist
natürlich trotzdem eine gute Idee. Alleine schon, um den ganzen Müll
("mein-computer.") von den Root NS fernzuhalten.
https://datatracker.ietf.org/doc/html/rfc7706
https://www.dns.icann.org/services/axfr/
Juergen Ilse
Oct 6, 2021, 2:39:04 AM10/6/21
to
HAllo,
Laurenz Trossel <m...@example.invalid> wrote:
>> Das betraf "nur" die DENIC DNS Server (und damit die TLD .de). Es ging aber
>> um einen Ausfall der Delegationen der Root Nameserver.
>
> Ich denke, da?? du dich da falsch erinnerst. Es gab diverse
> Beeintr??chtigungen der Root-Dienste aber keine kompletten Ausf??lle.
Ja, es gab auch ANgriffe auf die Root Server (u.a. auch ein dokumentierter
Angriff im Jahr 2015), aber die Links in dem Posting auf dass ich geantwwortet
habe, bezogen sicch auf einen Angriff auf die DENIC Nameserver.
> Nicht genannt ist ein weiterer Vorfall, bei dem die in China liegenden Root
> Nameserver auch von Netzen au??erhalb Chinas bevorzugt wurde, was zu
> Ausf??llen durch chinesische DNS-Filter f??hrte. Das betraf aber eher
Antwort bezog.
> Die Root-Zone per RFC 7706 auf den eigenen Resolvern zu spiegeln, ist
> nat??rlich trotzdem eine gute Idee. Alleine schon, um den ganzen M??ll
nicht so gravierend ist, wie anscheinend manche Leute denken ...
Ich halte es fuer eine bessere Idee, fuer haeufig angefragte nicht im
globalen DNS Dumm-Zonen aufzuseten (z.B. fuer die reverse DNS Aufloesung
der RFC1918 Adressen). Anfragen fuer die Vorwaertsaufloesung von Namen in
nicht existierenden TLDs werden da erheblich seltener sein. Domins, fuer
die solche Anfragen haeusif vorkommen, werden teils mit in die Delegation
auf die AS112 Nameserver aufgenommen, was (da die Delegation von anderen
DNS-Servern gecached wird) auf diese Weise Last von den Root Servern nimmt.
Den Ansatz halte ich fuer einfacher und nicht weniger sinnvoll.
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
Laurenz Trossel <m...@example.invalid> wrote:
>> Das betraf "nur" die DENIC DNS Server (und damit die TLD .de). Es ging aber
>> um einen Ausfall der Delegationen der Root Nameserver.
>
> Beeintr??chtigungen der Root-Dienste aber keine kompletten Ausf??lle.
Ja, es gab auch ANgriffe auf die Root Server (u.a. auch ein dokumentierter
Angriff im Jahr 2015), aber die Links in dem Posting auf dass ich geantwwortet
habe, bezogen sicch auf einen Angriff auf die DENIC Nameserver.
> Nicht genannt ist ein weiterer Vorfall, bei dem die in China liegenden Root
> Ausf??llen durch chinesische DNS-Filter f??hrte. Das betraf aber eher
> West-USA und keine deutschen Nutzer.
>
> https://blogs.oracle.com/internetintelligence/accidentally-importing-censorship
> https://archive.nanog.org/meetings/nanog49/presentations/Tuesday/Madory-I-root-lightning-talk.pdf
Ja, aber auch das war nicht der Vorfall, auf den ich mich in meiner ersten
>
> https://blogs.oracle.com/internetintelligence/accidentally-importing-censorship
> https://archive.nanog.org/meetings/nanog49/presentations/Tuesday/Madory-I-root-lightning-talk.pdf
Antwort bezog.
> Die Root-Zone per RFC 7706 auf den eigenen Resolvern zu spiegeln, ist
> ("mein-computer.") von den Root NS fernzuhalten.
>
> https://datatracker.ietf.org/doc/html/rfc7706
> https://www.dns.icann.org/services/axfr/
Ich halte das eher fuer einen Workaround fuer ein Problem, dass bei weitem
>
> https://datatracker.ietf.org/doc/html/rfc7706
> https://www.dns.icann.org/services/axfr/
nicht so gravierend ist, wie anscheinend manche Leute denken ...
Ich halte es fuer eine bessere Idee, fuer haeufig angefragte nicht im
globalen DNS Dumm-Zonen aufzuseten (z.B. fuer die reverse DNS Aufloesung
der RFC1918 Adressen). Anfragen fuer die Vorwaertsaufloesung von Namen in
nicht existierenden TLDs werden da erheblich seltener sein. Domins, fuer
die solche Anfragen haeusif vorkommen, werden teils mit in die Delegation
auf die AS112 Nameserver aufgenommen, was (da die Delegation von anderen
DNS-Servern gecached wird) auf diese Weise Last von den Root Servern nimmt.
Den Ansatz halte ich fuer einfacher und nicht weniger sinnvoll.
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
Marco Moock
Oct 7, 2021, 1:34:59 PM10/7/21
to
Am Mon, 4 Oct 2021 14:01:11 +0200
schrieb Christian Hanné <the....@gmail.com>:
> Die Authentizität der Hostnamen wird noch via
> HTTPS verifiziert
Nein, HTTPS macht das nicht.
Bei HTTPS prüft der Browser, ob das Zertifikat zur Domain passt.
Der hat root-Zertifikate von Zertifizierungsstellen, denen der Browser vertraut. Wenn die für eine Domain ein Zertifikat rausgeben, wird dem vertraut, welche IP-Adresse dann per DNS übergeben wird, ist egal, solange das Zertifikat zum Domainnamen passt. Damit das aber funktioniert muss der Angreifer auch den privaten Schlüssel vom Webserver haben, daher ist eine unbemerkte Manipulation schwieriger.
Er kann aber z.B. einfach einen CNAME-Record setzen, dann wird der
genutzt und wenn der User nicht aufpasst merkt er nicht, dass er einen
ganz anderen Domainnamen in der URL hat. So läuft das z.B. mit den
Websperren bzgl. Urheberrecht über die Telekom-DNS-Resolver.
--
Marco
schrieb Christian Hanné <the....@gmail.com>:
> Die Authentizität der Hostnamen wird noch via
> HTTPS verifiziert
Bei HTTPS prüft der Browser, ob das Zertifikat zur Domain passt.
Der hat root-Zertifikate von Zertifizierungsstellen, denen der Browser vertraut. Wenn die für eine Domain ein Zertifikat rausgeben, wird dem vertraut, welche IP-Adresse dann per DNS übergeben wird, ist egal, solange das Zertifikat zum Domainnamen passt. Damit das aber funktioniert muss der Angreifer auch den privaten Schlüssel vom Webserver haben, daher ist eine unbemerkte Manipulation schwieriger.
Er kann aber z.B. einfach einen CNAME-Record setzen, dann wird der
genutzt und wenn der User nicht aufpasst merkt er nicht, dass er einen
ganz anderen Domainnamen in der URL hat. So läuft das z.B. mit den
Websperren bzgl. Urheberrecht über die Telekom-DNS-Resolver.
--
Marco
Laurenz Trossel
Oct 7, 2021, 11:03:44 PM10/7/21
to
On 2021-10-07, Marco Moock <marco...@gmail.com> wrote:
> Er kann aber z.B. einfach einen CNAME-Record setzen, dann wird der
> genutzt und wenn der User nicht aufpasst merkt er nicht, dass er einen
> ganz anderen Domainnamen in der URL hat.
Ein CNAME ändert nicht den Hostnamen, den der Browser anzeigt und im
> Er kann aber z.B. einfach einen CNAME-Record setzen, dann wird der
> genutzt und wenn der User nicht aufpasst merkt er nicht, dass er einen
> ganz anderen Domainnamen in der URL hat.
Zertifikat erwartet.
> So läuft das z.B. mit den
> Websperren bzgl. Urheberrecht über die Telekom-DNS-Resolver.
und DNSSEC-Validierung schlagen dann jedoch fehl.
Die Telekom *könnte* unberechtigt ein SSL-Zertifikat für die umgeleitete
Domain ausstellen, wäre dann jedoch sehr schnell ihren Status als CA los.
Christian Hanné
Oct 8, 2021, 2:34:41 AM10/8/21
to
Am 05.10.2021 um 09:39 schrieb Marc Haber:
> Christian Hanné <the....@gmail.com> wrote:
>> Am 04.10.2021 um 17:39 schrieb Marc Haber:
>>> Juergen Ilse <ne...@usenet-verwaltung.de> wrote:
>>>> Ich denke, du hast da irgendwie die falsche Perspektive, um wirklich auf
>>>> die Frage zu antworten.
>>>
>>> "Christian Hanné" ist ein Troll. Einfach ignorieren.
>>
>> Was war jetzt bitte an dem was ich sagte Trollerei ?
>
> Das was Du in anderen Gruppen und anderen Threads von Dir
> gibst zerstört Deine sowieso nicht vorhandene Kredibilität.
Nochmal: was war an meiner Antwort Trollerei ?
> Christian Hanné <the....@gmail.com> wrote:
>> Am 04.10.2021 um 17:39 schrieb Marc Haber:
>>> Juergen Ilse <ne...@usenet-verwaltung.de> wrote:
>>>> Ich denke, du hast da irgendwie die falsche Perspektive, um wirklich auf
>>>> die Frage zu antworten.
>>>
>>> "Christian Hanné" ist ein Troll. Einfach ignorieren.
>>
>> Was war jetzt bitte an dem was ich sagte Trollerei ?
>
> Das was Du in anderen Gruppen und anderen Threads von Dir
> gibst zerstört Deine sowieso nicht vorhandene Kredibilität.
Christian Hanné
Oct 8, 2021, 2:35:42 AM10/8/21
to
Am 07.10.2021 um 19:34 schrieb Marco Moock:
> Am Mon, 4 Oct 2021 14:01:11 +0200
> schrieb Christian Hanné <the....@gmail.com>:
>
>> Die Authentizität der Hostnamen wird noch via
>> HTTPS verifiziert
>
> Nein, HTTPS macht das nicht.
> Bei HTTPS prüft der Browser, ob das Zertifikat zur Domain passt.
Eben, und das meinte ich.
> Am Mon, 4 Oct 2021 14:01:11 +0200
> schrieb Christian Hanné <the....@gmail.com>:
>
>> Die Authentizität der Hostnamen wird noch via
>> HTTPS verifiziert
>
> Nein, HTTPS macht das nicht.
> Bei HTTPS prüft der Browser, ob das Zertifikat zur Domain passt.
Marc Haber
Oct 8, 2021, 4:47:11 AM10/8/21
to
Marco Moock
Oct 8, 2021, 5:05:24 AM10/8/21
to
Am Thu, 7 Oct 2021 19:34:58 +0200
schrieb Marco Moock <marco...@gmail.com>:
> Damit das aber funktioniert muss der Angreifer auch den privaten
> Schlüssel vom Webserver haben, daher ist eine unbemerkte Manipulation
> schwieriger.
Kleine Ergänzung von mir:
Das ist zwar richtig, aber sobald der Angreifer des DNS andere A- und
AAAA-Record im autoritativen DNS-Server setzen kann (die ja auch von den
anderen gefragt werden), kann man dieses Problem umgehen.
Der Angreifer beantragt einfach bei einer CA ein eigenes Zertifikat. Da
er zeigen kann, dass er die Kontrolle über den Server hat (die CA
bekommt ja nun die Angreifer-Records und kontaktiert den
Angreifer-Server), stellt ihm damit ein Zertifikat für die
Domain und seinen (Angreifer) privaten Schlüssel aus.
Damit hilft HTTPS dann nichts mehr gegen DNS-Manipulation, sofern es
die root-Server oder autoritative Server betrifft.
--
Marco
schrieb Marco Moock <marco...@gmail.com>:
> Damit das aber funktioniert muss der Angreifer auch den privaten
> Schlüssel vom Webserver haben, daher ist eine unbemerkte Manipulation
> schwieriger.
Das ist zwar richtig, aber sobald der Angreifer des DNS andere A- und
AAAA-Record im autoritativen DNS-Server setzen kann (die ja auch von den
anderen gefragt werden), kann man dieses Problem umgehen.
Der Angreifer beantragt einfach bei einer CA ein eigenes Zertifikat. Da
er zeigen kann, dass er die Kontrolle über den Server hat (die CA
bekommt ja nun die Angreifer-Records und kontaktiert den
Angreifer-Server), stellt ihm damit ein Zertifikat für die
Domain und seinen (Angreifer) privaten Schlüssel aus.
Damit hilft HTTPS dann nichts mehr gegen DNS-Manipulation, sofern es
die root-Server oder autoritative Server betrifft.
--
Marco
Laurenz Trossel
Oct 8, 2021, 6:09:45 AM10/8/21
to
On 2021-10-08, Marco Moock <marco...@gmail.com> wrote:
> Kleine Ergänzung von mir:
> Das ist zwar richtig, aber sobald der Angreifer des DNS andere A- und
> AAAA-Record im autoritativen DNS-Server setzen kann (die ja auch von den
> anderen gefragt werden), kann man dieses Problem umgehen.
Wenn jemand Zugriff auf deinen Webserver, DNS-Master oder Registry-Zugang
> Kleine Ergänzung von mir:
> Das ist zwar richtig, aber sobald der Angreifer des DNS andere A- und
> AAAA-Record im autoritativen DNS-Server setzen kann (die ja auch von den
> anderen gefragt werden), kann man dieses Problem umgehen.
hat, kann er vieles umgehen. Ein hidden/offline Master mit DNSSEC kann hier
helfen. Zusätzlich CAA und TLSA Records.
> Damit hilft HTTPS dann nichts mehr gegen DNS-Manipulation, sofern es
> die root-Server oder autoritative Server betrifft.
erkennen.
Christian Hanné
Oct 8, 2021, 10:15:58 AM10/8/21
to
Am 08.10.2021 um 10:47 schrieb Marc Haber:
> Christian Hanné <the....@gmail.com> wrote:
>> Nochmal: was war an meiner Antwort Trollerei ?
>
> <sjeqa5$3i3$1...@gioia.aioe.org> hat Dich völlig diskreditiert.
Meine beiden BKH haben auch keine Zähne und können damit
> Christian Hanné <the....@gmail.com> wrote:
>> Nochmal: was war an meiner Antwort Trollerei ?
>
> <sjeqa5$3i3$1...@gioia.aioe.org> hat Dich völlig diskreditiert.
problemlos ihr Futter fressen.
Christian Hanné
Oct 8, 2021, 10:18:02 AM10/8/21
to
Am 08.10.2021 um 11:05 schrieb Marco Moock:
> Am Thu, 7 Oct 2021 19:34:58 +0200
> schrieb Marco Moock <marco...@gmail.com>:
>
>> Damit das aber funktioniert muss der Angreifer auch den privaten
>> Schlüssel vom Webserver haben, daher ist eine unbemerkte Manipulation
>> schwieriger.
>
> Kleine Ergänzung von mir:
> Das ist zwar richtig, aber sobald der Angreifer des DNS andere
> A- und AAAA-Record im autoritativen DNS-Server setzen kann ...
> Am Thu, 7 Oct 2021 19:34:58 +0200
> schrieb Marco Moock <marco...@gmail.com>:
>
>> Damit das aber funktioniert muss der Angreifer auch den privaten
>> Schlüssel vom Webserver haben, daher ist eine unbemerkte Manipulation
>> schwieriger.
>
> Kleine Ergänzung von mir:
> Das ist zwar richtig, aber sobald der Angreifer des DNS andere
Und wieso soll er das können wenn an der Stelle schon Einträge vom
bisherigen Eigner sitzen ?
Marco Moock
Oct 8, 2021, 10:22:37 AM10/8/21
to
Am Fri, 8 Oct 2021 16:18:02 +0200
schrieb Christian Hanné <the....@gmail.com>:
> Und wieso soll er das können wenn an der Stelle schon Einträge vom
> bisherigen Eigner sitzen ?
Wenn der Angreifer die für die Zone autoritativen Server (oder höherrangige) manipulieren kann, kann er die vorhandenen Records entfernen und durch seine eigenen ersetzen.
Wenn höherrangige Server übernommen werden geht es genauso, ggf. halt dann noch mit Delegation auf den eigenen Nameserver, damit es nicht so auffällt.
schrieb Christian Hanné <the....@gmail.com>:
> Und wieso soll er das können wenn an der Stelle schon Einträge vom
> bisherigen Eigner sitzen ?
Wenn höherrangige Server übernommen werden geht es genauso, ggf. halt dann noch mit Delegation auf den eigenen Nameserver, damit es nicht so auffällt.
Christian Hanné
Oct 8, 2021, 10:25:02 AM10/8/21
to
Am 08.10.2021 um 16:15 schrieb Christian Hanné:
> Am 08.10.2021 um 10:47 schrieb Marc Haber:
>> Christian Hanné <the....@gmail.com> wrote:
>>> Nochmal: was war an meiner Antwort Trollerei ?
>>
>> <sjeqa5$3i3$1...@gioia.aioe.org> hat Dich völlig diskreditiert.
>
> Meine beiden BKH haben auch keine Zähne ...
> Am 08.10.2021 um 10:47 schrieb Marc Haber:
>> Christian Hanné <the....@gmail.com> wrote:
>>> Nochmal: was war an meiner Antwort Trollerei ?
>>
>> <sjeqa5$3i3$1...@gioia.aioe.org> hat Dich völlig diskreditiert.
>
Ach, ist gar nicht so genau: ich hab nur alle Zähne
hinter den Reißzähnen entfernen lassen. Die Reißzähne
bzw. die Mini-Zähnchen dazwischen sind geblieben.
Christian Hanné
Oct 8, 2021, 10:26:08 AM10/8/21
to
Am 08.10.2021 um 16:22 schrieb Marco Moock:
> Am Fri, 8 Oct 2021 16:18:02 +0200
> schrieb Christian Hanné <the....@gmail.com>:
>
>> Und wieso soll er das können wenn an der Stelle schon Einträge vom
>> bisherigen Eigner sitzen ?
> Wenn der Angreifer die für die Zone autoritativen Server (oder höherrangige) manipulieren kann, kann er die vorhandenen Records entfernen und durch seine eigenen ersetzen.
Ach, und Du meinst, dass er das a) so einfach kann und b) dass zu dem
> Am Fri, 8 Oct 2021 16:18:02 +0200
> schrieb Christian Hanné <the....@gmail.com>:
>
>> Und wieso soll er das können wenn an der Stelle schon Einträge vom
>> bisherigen Eigner sitzen ?
> Wenn der Angreifer die für die Zone autoritativen Server (oder höherrangige) manipulieren kann, kann er die vorhandenen Records entfernen und durch seine eigenen ersetzen.
Zeitpunkt auch noch kein Zertifikat auf die Domain ausgestellt ist ?
Marco Moock
Oct 8, 2021, 10:38:10 AM10/8/21
to
Am Fri, 8 Oct 2021 16:26:08 +0200
schrieb Christian Hanné <the....@gmail.com>:
> Ach, und Du meinst, dass er das a) so einfach kann und b) dass zu dem
> Zeitpunkt auch noch kein Zertifikat auf die Domain ausgestellt ist ?
Wenn da einer reinkommt geht das - ggf. Sicherheitslücke oder eine andere Methode.
Wenn eine CA ein Zertifikat ausstellt und die Browser diesem vertrauen funktioniert der Angriff auch bei HTTPS und kaum einer bekommt es mit.
Wie prüfen die denn, ob es für diese Domain schon ein Zertifikat gibt?
Was ist, wenn es der Eigentümer ist, der einfach nur die CA wechseln will?
schrieb Christian Hanné <the....@gmail.com>:
> Ach, und Du meinst, dass er das a) so einfach kann und b) dass zu dem
> Zeitpunkt auch noch kein Zertifikat auf die Domain ausgestellt ist ?
Wenn eine CA ein Zertifikat ausstellt und die Browser diesem vertrauen funktioniert der Angriff auch bei HTTPS und kaum einer bekommt es mit.
Wie prüfen die denn, ob es für diese Domain schon ein Zertifikat gibt?
Was ist, wenn es der Eigentümer ist, der einfach nur die CA wechseln will?
Christian Hanné
Oct 8, 2021, 10:52:53 AM10/8/21
to
Am 08.10.2021 um 16:38 schrieb Marco Moock:
> Am Fri, 8 Oct 2021 16:26:08 +0200
> schrieb Christian Hanné <the....@gmail.com>:
>
>> Ach, und Du meinst, dass er das a) so einfach kann und b) dass zu dem
>> Zeitpunkt auch noch kein Zertifikat auf die Domain ausgestellt ist ?
>
> Wenn da einer reinkommt geht das - ggf. Sicherheitslücke oder eine andere Methode.
Naja, is mir alles zu spekulativ.
> Am Fri, 8 Oct 2021 16:26:08 +0200
> schrieb Christian Hanné <the....@gmail.com>:
>
>> Ach, und Du meinst, dass er das a) so einfach kann und b) dass zu dem
>> Zeitpunkt auch noch kein Zertifikat auf die Domain ausgestellt ist ?
>
> Wenn da einer reinkommt geht das - ggf. Sicherheitslücke oder eine andere Methode.
Da kann ich ja auch einfach sagen, dass ich den Webserver übernehmen könnte.
Marco Moock
Oct 8, 2021, 10:55:42 AM10/8/21
to
Am Fri, 8 Oct 2021 16:52:53 +0200
Wenn ich example.org. habe und den autoritativen DNS dafür betreibe kann ich nur meine Server absichern, aber nicht den Server, der für .org. zuständig ist.
Wenn den jemand gehackt hat kann er beliebige NS-Records setzen und damit die Zone an einen beliebigen DNS-Server delegieren. Der Admin von example.org. kann dagegen gar nichts unternehmen.
schrieb Christian Hanné <the....@gmail.com>:
> Am 08.10.2021 um 16:38 schrieb Marco Moock:
> > Am Fri, 8 Oct 2021 16:26:08 +0200
> > schrieb Christian Hanné <the....@gmail.com>:
> >
> >> Ach, und Du meinst, dass er das a) so einfach kann und b) dass zu
> >> dem Zeitpunkt auch noch kein Zertifikat auf die Domain ausgestellt
> >> ist ?
> >
> > Wenn da einer reinkommt geht das - ggf. Sicherheitslücke oder eine
> > andere Methode.
>
> Naja, is mir alles zu spekulativ.
> Da kann ich ja auch einfach sagen, dass ich den Webserver übernehmen
> könnte.
Wobei es beim DNS aber auch ein höherrangiger sein kann und der Admin Vom Webserver und des autoritativen DNS-Servers für seine Domain da nichts gegen machen kann.
> Am 08.10.2021 um 16:38 schrieb Marco Moock:
> > Am Fri, 8 Oct 2021 16:26:08 +0200
> > schrieb Christian Hanné <the....@gmail.com>:
> >
> >> Ach, und Du meinst, dass er das a) so einfach kann und b) dass zu
> >> dem Zeitpunkt auch noch kein Zertifikat auf die Domain ausgestellt
> >> ist ?
> >
> > Wenn da einer reinkommt geht das - ggf. Sicherheitslücke oder eine
> > andere Methode.
>
> Naja, is mir alles zu spekulativ.
> Da kann ich ja auch einfach sagen, dass ich den Webserver übernehmen
> könnte.
Wenn ich example.org. habe und den autoritativen DNS dafür betreibe kann ich nur meine Server absichern, aber nicht den Server, der für .org. zuständig ist.
Wenn den jemand gehackt hat kann er beliebige NS-Records setzen und damit die Zone an einen beliebigen DNS-Server delegieren. Der Admin von example.org. kann dagegen gar nichts unternehmen.
Christian Hanné
Oct 8, 2021, 11:20:05 AM10/8/21
to
Leute sitzen die von Sicherheits-Themen _richtig_ Ahnung haben.
Marco Moock
Oct 8, 2021, 11:21:58 AM10/8/21
to
Am Fri, 8 Oct 2021 17:19:59 +0200
schrieb Christian Hanné <the....@gmail.com>:
>
Bei großen Internet-Firmen gab es auch schon erfolgreiche Angriffe.
Ich wollte damit nur klarmacehn, dass HTTPS hier nicht unbedingt helfen kann, diese Angriffe zu erkennen.
schrieb Christian Hanné <the....@gmail.com>:
>
> Du kannst aber davon ausgehen, dass bei den delegierenden TLDs
> Leute sitzen die von Sicherheits-Themen _richtig_ Ahnung haben.
Ja, was aber nicht bedeutet, dass es da keine Fehler geben kann.
> Leute sitzen die von Sicherheits-Themen _richtig_ Ahnung haben.
Bei großen Internet-Firmen gab es auch schon erfolgreiche Angriffe.
Ich wollte damit nur klarmacehn, dass HTTPS hier nicht unbedingt helfen kann, diese Angriffe zu erkennen.
Jonas Hoppe
Oct 8, 2021, 12:09:18 PM10/8/21
to
Also sprach Marc Haber am 08.10.2021 um 10:47:
etikettieren, ist nicht angemessen und gar nicht "Trollerei". "Zähne
ziehen", er meinte wohl nicht alle, ist oder war für das beschriebene
Verhalten der Katze durchaus eine Option.
Der Kater meiner Mutter hatte sie schon mehrmals so stark gebissen, dass
sie jedes Mal in Behandlung musste. Lösung: je zwei, oben unten, der
Reiss- bzw. Fangzähne gezogen, und die Katze biss 1. immer weniger, 2.
nicht mehr tief eindringend und 3. heute eigentlich gar nicht mehr.
Nur dass ich auch mal eine off-topic Antwort gegeben habe. -;)
--
Grüsse, Jonas
---
> Christian Hanné <the....@gmail.com> wrote:
>> Nochmal: was war an meiner Antwort Trollerei ?
>
> <sjeqa5$3i3$1...@gioia.aioe.org> hat Dich völlig diskreditiert.
>
Ich finde, seine Antwort dort mit "völlig diskreditiert" zu
>> Nochmal: was war an meiner Antwort Trollerei ?
>
> <sjeqa5$3i3$1...@gioia.aioe.org> hat Dich völlig diskreditiert.
>
etikettieren, ist nicht angemessen und gar nicht "Trollerei". "Zähne
ziehen", er meinte wohl nicht alle, ist oder war für das beschriebene
Verhalten der Katze durchaus eine Option.
Der Kater meiner Mutter hatte sie schon mehrmals so stark gebissen, dass
sie jedes Mal in Behandlung musste. Lösung: je zwei, oben unten, der
Reiss- bzw. Fangzähne gezogen, und die Katze biss 1. immer weniger, 2.
nicht mehr tief eindringend und 3. heute eigentlich gar nicht mehr.
Nur dass ich auch mal eine off-topic Antwort gegeben habe. -;)
--
Grüsse, Jonas
---
Jonas Hoppe
Oct 8, 2021, 12:15:56 PM10/8/21
to
Also sprach Jonas Hoppe am 08.10.2021 um 18:09:
> Der Kater meiner Mutter hatte sie schon mehrmals so stark gebissen, dass
> sie jedes Mal in Behandlung musste. Lösung: ...Fangzähne gezogen...
Bevor ich jetzt zusammengeschissen werde: Dem Kater gehts prächtig. Er
zeigt *überhaupt keine* Verhaltensänderung (fressen, putzen,
herumvagabundieren wie eh und je). Vermuteter, erfreulicher Nebeneffekt:
Miau kann weniger Tiere töten, die ihm unterlegen sind.
--
Grüsse, Jonas
---
> Der Kater meiner Mutter hatte sie schon mehrmals so stark gebissen, dass
Bevor ich jetzt zusammengeschissen werde: Dem Kater gehts prächtig. Er
zeigt *überhaupt keine* Verhaltensänderung (fressen, putzen,
herumvagabundieren wie eh und je). Vermuteter, erfreulicher Nebeneffekt:
Miau kann weniger Tiere töten, die ihm unterlegen sind.
--
Grüsse, Jonas
---
Christian Hanné
Oct 8, 2021, 12:59:53 PM10/8/21
to
Am 08.10.2021 um 17:21 schrieb Marco Moock:
> Am Fri, 8 Oct 2021 17:19:59 +0200
> schrieb Christian Hanné <the....@gmail.com>:
>>
>> Du kannst aber davon ausgehen, dass bei den delegierenden TLDs
>> Leute sitzen die von Sicherheits-Themen _richtig_ Ahnung haben.
> Ja, was aber nicht bedeutet, dass es da keine Fehler geben kann.
Theoretisch, aber wann ist es denn jemals gelungen, die Delegierungen
> Am Fri, 8 Oct 2021 17:19:59 +0200
> schrieb Christian Hanné <the....@gmail.com>:
>>
>> Du kannst aber davon ausgehen, dass bei den delegierenden TLDs
>> Leute sitzen die von Sicherheits-Themen _richtig_ Ahnung haben.
> Ja, was aber nicht bedeutet, dass es da keine Fehler geben kann.
bei einer TLD umzuleiten ?
Christian Hanné
Oct 8, 2021, 1:02:53 PM10/8/21
to
Am 08.10.2021 um 18:09 schrieb Jonas Hoppe:
> Also sprach Marc Haber am 08.10.2021 um 10:47:
>> Christian Hanné <the....@gmail.com> wrote:
>>> Nochmal: was war an meiner Antwort Trollerei ?
>>
>> <sjeqa5$3i3$1...@gioia.aioe.org> hat Dich völlig diskreditiert.
>>
>
> Ich finde, seine Antwort dort mit "völlig diskreditiert" zu
> etikettieren, ist nicht angemessen und gar nicht "Trollerei". "Zähne
> ziehen", er meinte wohl nicht alle, ist oder war für das beschriebene
> Verhalten der Katze durchaus eine Option.
Ich habe bei meinen beiden BKH alle Zähne oben und unten, links und
> Also sprach Marc Haber am 08.10.2021 um 10:47:
>> Christian Hanné <the....@gmail.com> wrote:
>>> Nochmal: was war an meiner Antwort Trollerei ?
>>
>> <sjeqa5$3i3$1...@gioia.aioe.org> hat Dich völlig diskreditiert.
>>
>
> Ich finde, seine Antwort dort mit "völlig diskreditiert" zu
> etikettieren, ist nicht angemessen und gar nicht "Trollerei". "Zähne
> ziehen", er meinte wohl nicht alle, ist oder war für das beschriebene
> Verhalten der Katze durchaus eine Option.
rechts hinter den Reißzähnen ziehen lassen, also alles was Hebelwirkung
hat - die anderen dienen ja nur zum Festhalten der Beute und nich zum
Zerbeißen.
Mein erster Tierarzt wurde durch meine Katze gebissen und hat sich einen
Tag Auszeit mit Antibiotika-Behandlung im KKH nehmen müssen, das selbe
ist bei meinem Kater (ihr Bruder) bei der nächsten Tierärztin passiert
und Kabel haben die sowieso durchgebissen. Und da das kein Problem ist
mit den Futtern habe ich die Zähne halt ziehen lassen.
Marc Haber
Oct 8, 2021, 5:38:21 PM10/8/21
to
Christian Hanné <the....@gmail.com> wrote:
>Ich habe bei meinen beiden BKH alle Zähne oben und unten, links und
>rechts hinter den Reißzähnen ziehen lassen, also alles was Hebelwirkung
>hat - die anderen dienen ja nur zum Festhalten der Beute und nich zum
>Zerbeißen.
>Mein erster Tierarzt wurde durch meine Katze gebissen und hat sich einen
>Tag Auszeit mit Antibiotika-Behandlung im KKH nehmen müssen, das selbe
>ist bei meinem Kater (ihr Bruder) bei der nächsten Tierärztin passiert
>und Kabel haben die sowieso durchgebissen. Und da das kein Problem ist
>mit den Futtern habe ich die Zähne halt ziehen lassen.
Wäre ich bei dir Katze, würde ich Dich auch beißen. Und dann
>Ich habe bei meinen beiden BKH alle Zähne oben und unten, links und
>rechts hinter den Reißzähnen ziehen lassen, also alles was Hebelwirkung
>hat - die anderen dienen ja nur zum Festhalten der Beute und nich zum
>Zerbeißen.
>Mein erster Tierarzt wurde durch meine Katze gebissen und hat sich einen
>Tag Auszeit mit Antibiotika-Behandlung im KKH nehmen müssen, das selbe
>ist bei meinem Kater (ihr Bruder) bei der nächsten Tierärztin passiert
>und Kabel haben die sowieso durchgebissen. Und da das kein Problem ist
>mit den Futtern habe ich die Zähne halt ziehen lassen.
weglaufen. Eigentlich müsste man jetzt eine Strafanzeige stellen.
Aber Du bist ja eh nur ein Troll und hast hoffentlich sowohl die Katze
als auch die Geschichte erfunden.
Christian Hanné
Oct 9, 2021, 3:20:39 AM10/9/21
to
Am 08.10.2021 um 23:38 schrieb Marc Haber:
> Wäre ich bei dir Katze, würde ich Dich auch beißen. Und dann
> weglaufen. Eigentlich müsste man jetzt eine Strafanzeige stellen.
_Mich_ haben die selten gebessen, aber eben zwei Tierärzte.
> Wäre ich bei dir Katze, würde ich Dich auch beißen. Und dann
> weglaufen. Eigentlich müsste man jetzt eine Strafanzeige stellen.
Und Kabel beißen die weiter - aber eben nicht mehr so, dass
die kaputtgehen.
Jonas Hoppe
Oct 9, 2021, 4:46:29 AM10/9/21
to
Also sprach Marc Haber am 08.10.2021 um 23:38:
> ...Eigentlich müsste man jetzt eine Strafanzeige stellen.
Warum?
> Aber Du bist ja eh nur ein Troll und hast hoffentlich sowohl die Katze
> als auch die Geschichte erfunden.
Was genau denkst Du, Marc, ist daran falsch, einer Katze ein paar Zähne
zu ziehen (zB. die 4 gröberen Schaden anrichtenden Reisszähne), wenn man
damit ein potenziell gefährliches Verhalten (tiefgehendes Beissen mit
bspw. Tollwutgefahr) verhindern kann? Zumal solche Katzen nach den
Zahnextraktionen *keine* Verhaltensänderungen zeigen, also kein
grösseres Problem damit haben?
--
Grüsse, Jonas
---
> ...Eigentlich müsste man jetzt eine Strafanzeige stellen.
Warum?
> Aber Du bist ja eh nur ein Troll und hast hoffentlich sowohl die Katze
> als auch die Geschichte erfunden.
zu ziehen (zB. die 4 gröberen Schaden anrichtenden Reisszähne), wenn man
damit ein potenziell gefährliches Verhalten (tiefgehendes Beissen mit
bspw. Tollwutgefahr) verhindern kann? Zumal solche Katzen nach den
Zahnextraktionen *keine* Verhaltensänderungen zeigen, also kein
grösseres Problem damit haben?
--
Grüsse, Jonas
---
Christian Hanné
Oct 9, 2021, 5:56:29 AM10/9/21
to
Am 09.10.2021 um 10:46 schrieb Jonas Hoppe:
>> ...Eigentlich müsste man jetzt eine Strafanzeige stellen.
> Warum?
Eben, die TÄ dies gemacht hat (Kollegin von der die gebissen
>> ...Eigentlich müsste man jetzt eine Strafanzeige stellen.
> Warum?
wurde) würde sich ja auch strafbar gemacht haben. Wetten, dass
sowas von der StA sofort verworfen würde ?
Juergen Ilse
Oct 9, 2021, 7:27:38 PM10/9/21
to
Hallo,
Marco Moock <marco...@gmail.com> wrote:
> Am Mon, 4 Oct 2021 14:01:11 +0200
> schrieb Christian Hanné <the....@gmail.com>:
>
>> Die Authentizität der Hostnamen wird noch via
>> HTTPS verifiziert
>
> Nein, HTTPS macht das nicht.
> Bei HTTPS prüft der Browser, ob das Zertifikat zur Domain passt.
> Der hat root-Zertifikate von Zertifizierungsstellen, denen der Browser vertraut. Wenn die für eine Domain ein Zertifikat rausgeben, wird dem vertraut, welche IP-Adresse dann per DNS übergeben wird, ist egal, solange das Zertifikat zum Domainnamen passt. Damit das aber funktioniert muss der Angreifer auch den privaten Schlüssel vom Webserver haben, daher ist eine unbemerkte Manipulation schwieriger.
> Er kann aber z.B. einfach einen CNAME-Record setzen, dann wird der
> genutzt und wenn der User nicht aufpasst merkt er nicht, dass er einen
> ganz anderen Domainnamen in der URL hat.
Das ist nicht richtig. Der Name im Zertifikat wird gegen den Namen geprueft,
der in der URL steht, und das ist voellig unabhaengig von der Namensaufloesung
per DNS. Auch bei CNAAMEs im DNS schreibt der Browser keine Hostnamen in der
URL um. Bei der DNS Aufloesung wird zwar ein CNAME zuerst durch den Namen
ersetzt, auf den der CNAME zeigt, aber der Hostname in der URL ist Teil der
URL Syntax und wird nicht aufgrund von DNS Aufloesungen "umgeschrieben".
> So läuft das z.B. mit den Websperren bzgl. Urheberrecht über die
> Telekom-DNS-Resolver.
Nein. Daa wird die DNS-Aufloesung so manipuliert, dass sie eine andere
IP-Adresse liefern. CNAMEs die zur selben IP aufgeloest werden, wuerden
an der Stelle nicht funktionieren.
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
Marco Moock <marco...@gmail.com> wrote:
> Am Mon, 4 Oct 2021 14:01:11 +0200
> schrieb Christian Hanné <the....@gmail.com>:
>
>> Die Authentizität der Hostnamen wird noch via
>> HTTPS verifiziert
>
> Nein, HTTPS macht das nicht.
> Bei HTTPS prüft der Browser, ob das Zertifikat zur Domain passt.
> Der hat root-Zertifikate von Zertifizierungsstellen, denen der Browser vertraut. Wenn die für eine Domain ein Zertifikat rausgeben, wird dem vertraut, welche IP-Adresse dann per DNS übergeben wird, ist egal, solange das Zertifikat zum Domainnamen passt. Damit das aber funktioniert muss der Angreifer auch den privaten Schlüssel vom Webserver haben, daher ist eine unbemerkte Manipulation schwieriger.
> Er kann aber z.B. einfach einen CNAME-Record setzen, dann wird der
> genutzt und wenn der User nicht aufpasst merkt er nicht, dass er einen
> ganz anderen Domainnamen in der URL hat.
der in der URL steht, und das ist voellig unabhaengig von der Namensaufloesung
per DNS. Auch bei CNAAMEs im DNS schreibt der Browser keine Hostnamen in der
URL um. Bei der DNS Aufloesung wird zwar ein CNAME zuerst durch den Namen
ersetzt, auf den der CNAME zeigt, aber der Hostname in der URL ist Teil der
URL Syntax und wird nicht aufgrund von DNS Aufloesungen "umgeschrieben".
> So läuft das z.B. mit den Websperren bzgl. Urheberrecht über die
> Telekom-DNS-Resolver.
IP-Adresse liefern. CNAMEs die zur selben IP aufgeloest werden, wuerden
an der Stelle nicht funktionieren.
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
Juergen Ilse
Oct 9, 2021, 7:42:07 PM10/9/21
to
Hallo,
Wie ich schon schrieb, ist mir das *ein* solcher erfolgreicher Angriff auf
die root-Zone im Gedaechtnis geblieben, aber das ist so lange her, dass
die damals genutzte Sicherheitsluecke wohl bereits seit vielen Jahren
geschlossen ist, und es zeigt die Seltenheit solcher erfolgreicher An-
griffe. Auch die Liste der nicht erfolgreichen ernsthaften Angriffe auf
die root-Zone ist anscheinend eher sehr ueberschaubar (mit ernsthaft
meine ich solche, die aufgefallen sind).
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
die root-Zone im Gedaechtnis geblieben, aber das ist so lange her, dass
die damals genutzte Sicherheitsluecke wohl bereits seit vielen Jahren
geschlossen ist, und es zeigt die Seltenheit solcher erfolgreicher An-
griffe. Auch die Liste der nicht erfolgreichen ernsthaften Angriffe auf
die root-Zone ist anscheinend eher sehr ueberschaubar (mit ernsthaft
meine ich solche, die aufgefallen sind).
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
Florian Weimer
Oct 10, 2021, 5:48:14 AM10/10/21
to
* Peter J. Holzer:
> Nachdem Du das jetzt binnn kurzem zum zweiten mal erwähnst: Hast Du eine
> Quelle, wo man das nachlesen kann? Ich habe eine vage Erinnerung, dass
> da was war, die reicht aber offenbar nicht für suchmaschinentaugliche
> Stichworte.
Ein Stichwort lautet »AlterNIC«, der Vorfall war im Juli 1997. Die
eigentliche Datenquelle (d.h. die Zonendaten) wurde aber nicht
verändert. Es fehlte eine Prüfung in BIND, daß Daten für die Zonen
tatsächlich von einem Server für die Zone stammten, und nicht einfach
Huckepack von einem anderen Server zusammen mit einer erwarteten
Antwort eingereicht wurden. Konkrete und plausible Beschreibungen,
was damals technisch geschah, lassen sich aber kaum noch finden.
> Nachdem Du das jetzt binnn kurzem zum zweiten mal erwähnst: Hast Du eine
> Quelle, wo man das nachlesen kann? Ich habe eine vage Erinnerung, dass
> da was war, die reicht aber offenbar nicht für suchmaschinentaugliche
> Stichworte.
Ein Stichwort lautet »AlterNIC«, der Vorfall war im Juli 1997. Die
eigentliche Datenquelle (d.h. die Zonendaten) wurde aber nicht
verändert. Es fehlte eine Prüfung in BIND, daß Daten für die Zonen
tatsächlich von einem Server für die Zone stammten, und nicht einfach
Huckepack von einem anderen Server zusammen mit einer erwarteten
Antwort eingereicht wurden. Konkrete und plausible Beschreibungen,
was damals technisch geschah, lassen sich aber kaum noch finden.
Marco Moock
Oct 10, 2021, 6:22:24 AM10/10/21
to
Am Sun, 10 Oct 2021 11:48:13 +0200
schrieb Florian Weimer <f...@deneb.enyo.de>:
https://de.wikipedia.org/wiki/Cache_Poisoning
schrieb Florian Weimer <f...@deneb.enyo.de>:
> Ein Stichwort lautet »AlterNIC«, der Vorfall war im Juli 1997. Die
> eigentliche Datenquelle (d.h. die Zonendaten) wurde aber nicht
> verändert. Es fehlte eine Prüfung in BIND, daß Daten für die Zonen
> tatsächlich von einem Server für die Zone stammten, und nicht einfach
> Huckepack von einem anderen Server zusammen mit einer erwarteten
> Antwort eingereicht wurden.
Sowas wie DNS Cache Poisoning über die Additional Section?
> eigentliche Datenquelle (d.h. die Zonendaten) wurde aber nicht
> verändert. Es fehlte eine Prüfung in BIND, daß Daten für die Zonen
> tatsächlich von einem Server für die Zone stammten, und nicht einfach
> Huckepack von einem anderen Server zusammen mit einer erwarteten
> Antwort eingereicht wurden.
https://de.wikipedia.org/wiki/Cache_Poisoning
Florian Weimer
Oct 10, 2021, 9:30:41 AM10/10/21
to
* Marco Moock:
Nein, oder zumindest nicht nur das. BIND 9.4.6 hat u.a. diesen Code
hinzugefügt:
+ if (externalcname || strcasecmp(name, aname) != 0) {
+ if (!externalcname)
+ syslog(LOG_DEBUG,
+ "wrong ans. name (%s != %s)",
name, aname);
+ else
+ dprintf(3, (ddt,
+ "ignoring answer '%s' after external cname\n",
+ name));
db_free(dp);
continue;
}
if (type == T_CNAME &&
qtype != T_CNAME && qtype != T_ANY) {
strcpy(aname, (char *)dp->d_data);
+ if (!samedomain(aname, qp->q_domain))
+ externalcname = 1;
cname = 1;
lastwascname = 1;
Das sieht eher danach aus, daß zuvor einfach CNAME-Ketten und ihre
Daten weiterverarbeitet wurden, die aus dem eigentlichen
Zuständigkeitsbereich der Antwort herausführen. Unter dem damals
bereits gängigen DNS-Modell war das schon nicht mehr zulässig.
hinzugefügt:
+ if (externalcname || strcasecmp(name, aname) != 0) {
+ if (!externalcname)
+ syslog(LOG_DEBUG,
+ "wrong ans. name (%s != %s)",
name, aname);
+ else
+ dprintf(3, (ddt,
+ "ignoring answer '%s' after external cname\n",
+ name));
db_free(dp);
continue;
}
if (type == T_CNAME &&
qtype != T_CNAME && qtype != T_ANY) {
strcpy(aname, (char *)dp->d_data);
+ if (!samedomain(aname, qp->q_domain))
+ externalcname = 1;
cname = 1;
lastwascname = 1;
Das sieht eher danach aus, daß zuvor einfach CNAME-Ketten und ihre
Daten weiterverarbeitet wurden, die aus dem eigentlichen
Zuständigkeitsbereich der Antwort herausführen. Unter dem damals
bereits gängigen DNS-Modell war das schon nicht mehr zulässig.
Bonita Montero
Oct 10, 2021, 10:28:35 AM10/10/21
to
Marco Moock
Oct 10, 2021, 10:55:01 AM10/10/21
to
Am Sun, 10 Oct 2021 16:28:34 +0200
schrieb Bonita Montero <Bonita....@gmail.com>:
> C gehört ins Museum.
Und warum?
Um die 256. Programmiersprache einzuführen, die dann irgendwas besser
macht und 5 andere Sachen nicht mehr vorgesehen sind?
schrieb Bonita Montero <Bonita....@gmail.com>:
> C gehört ins Museum.
Und warum?
Um die 256. Programmiersprache einzuführen, die dann irgendwas besser
macht und 5 andere Sachen nicht mehr vorgesehen sind?
Bonita Montero
Oct 10, 2021, 12:43:33 PM10/10/21
to
von Systemsoftware: C++ und Rust.
Ich bin absoluter C++-Fan und finde, dass man sich in C nen Ast
abbricht für Dinge die man in C++ mit einem Schnipp mit gleicher
Effizienz realisiert.
C ist nur noch so verbreitet weil es ne Menge Leute mit Minimalis-
mus-Mindset gibt die nicht auf der Lowlevel- _und_ der abstrakteren
Highlevel-Ebene gleichzeitig denken können, wie es modernere Sprachen
erfordern.
Juergen Ilse
Oct 11, 2021, 10:49:13 AM10/11/21
to
Hallo,
Danke. Irgendwie kam ess mir in meiner Erinnerung gar nicht so lange in
der Vergangenheit vor. Dener Beschreibung nach klingt es also nach "cache
poisoning". Seit damals wurde meines Wissens nach einiges an bind geaendert
worden, um das zu verhindern oder zu erschweren.
Meines Wissens nach hat es eine damit wirklich vergleichbare "DNS Katastrophe"
seither nicht wieder gegeben (wohl aber andere Angriffe und teils auch spuer-
bare Beeintraechtigungen des DNS Dienstes, nur icht so umfassend wwie damals.
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
der Vergangenheit vor. Dener Beschreibung nach klingt es also nach "cache
poisoning". Seit damals wurde meines Wissens nach einiges an bind geaendert
worden, um das zu verhindern oder zu erschweren.
Meines Wissens nach hat es eine damit wirklich vergleichbare "DNS Katastrophe"
seither nicht wieder gegeben (wohl aber andere Angriffe und teils auch spuer-
bare Beeintraechtigungen des DNS Dienstes, nur icht so umfassend wwie damals.
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
Juergen Ilse
Oct 11, 2021, 11:08:22 AM10/11/21
to
Hallo,
Bonita Montero <Bonita....@gmail.com> wrote:
> C ist nur noch so verbreitet weil es ne Menge Leute mit Minimalis-
> mus-Mindset gibt die nicht auf der Lowlevel- _und_ der abstrakteren
> Highlevel-Ebene gleichzeitig denken können, wie es modernere Sprachen
> erfordern.
C ist aus vielen Gruenden noch vorhanden ud wird auch nicht so schnell
komplett durch anderes ersetzt werden. Zum einen weil es noch sehr viel
C-Sourcen von Software gibt, die noch in Gebrauch ist (und nicht alles
davon laesst sich ohne Aenderungen mit C++ uebersetzen, ohne dabei ggfs.
Bugs einzuschleppen, denn es gibt auch beim gemeinsamen Subset von C
und C++ ein paar kleine aber gemeine Unterschiede ...). Und ein anderer
Grund oist, dass C (insbesondere als freestanding implementation) fuer
das programmieren von Mikrocontrollern im Einsatz ist, fuer die es keine
brauchbare C++ Implementierung gibt.
Zum ersten Punkt: Bei einem Projekt wie z.B. bind (mit > 100.000 Zeilen
Quelltext) will (verstaendlicherweise) niemand mal eben den gesamten
Source auf moegliche Inkompatibilitaeten zwischen C und C++ durchsuchen.
Und wenn man ehrlich ist, benutzt bei C++ doch nahezu jeder nur einen
Teil der Sprache, und beherrscht den nicht benutzten Teil der Sprache
oftmals noch nicht einmal (was dann die Wartung von fremdem C++ Code
teils schwierig macht) ... Der Sprachumfaang von C ist so ueberschaubar,
dass nahezu jeder brauchbare C-Programmierer den gesamten Sprchumfang
kennt.
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
PS: In Frankreich soll es Institutionen geben, die zur Systemprogrammierung
sogar OCAML einsetzen (eine funktionale Sprache, die daneben auch noch
objektorietierte Elemente aufweist).
Bonita Montero <Bonita....@gmail.com> wrote:
> C ist nur noch so verbreitet weil es ne Menge Leute mit Minimalis-
> mus-Mindset gibt die nicht auf der Lowlevel- _und_ der abstrakteren
> Highlevel-Ebene gleichzeitig denken können, wie es modernere Sprachen
> erfordern.
komplett durch anderes ersetzt werden. Zum einen weil es noch sehr viel
C-Sourcen von Software gibt, die noch in Gebrauch ist (und nicht alles
davon laesst sich ohne Aenderungen mit C++ uebersetzen, ohne dabei ggfs.
Bugs einzuschleppen, denn es gibt auch beim gemeinsamen Subset von C
und C++ ein paar kleine aber gemeine Unterschiede ...). Und ein anderer
Grund oist, dass C (insbesondere als freestanding implementation) fuer
das programmieren von Mikrocontrollern im Einsatz ist, fuer die es keine
brauchbare C++ Implementierung gibt.
Zum ersten Punkt: Bei einem Projekt wie z.B. bind (mit > 100.000 Zeilen
Quelltext) will (verstaendlicherweise) niemand mal eben den gesamten
Source auf moegliche Inkompatibilitaeten zwischen C und C++ durchsuchen.
Und wenn man ehrlich ist, benutzt bei C++ doch nahezu jeder nur einen
Teil der Sprache, und beherrscht den nicht benutzten Teil der Sprache
oftmals noch nicht einmal (was dann die Wartung von fremdem C++ Code
teils schwierig macht) ... Der Sprachumfaang von C ist so ueberschaubar,
dass nahezu jeder brauchbare C-Programmierer den gesamten Sprchumfang
kennt.
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
PS: In Frankreich soll es Institutionen geben, die zur Systemprogrammierung
sogar OCAML einsetzen (eine funktionale Sprache, die daneben auch noch
objektorietierte Elemente aufweist).
Bonita Montero
Oct 11, 2021, 12:56:41 PM10/11/21
to
Am 11.10.2021 um 17:08 schrieb Juergen Ilse:
> C ist aus vielen Gruenden noch vorhanden ud wird auch nicht so schnell
> komplett durch anderes ersetzt werden. Zum einen weil es noch sehr viel
> C-Sourcen von Software gibt, die noch in Gebrauch ist (und nicht alles
> davon laesst sich ohne Aenderungen mit C++ uebersetzen, ohne dabei ggfs.
> Bugs einzuschleppen, denn es gibt auch beim gemeinsamen Subset von C
> und C++ ein paar kleine aber gemeine Unterschiede ...). Und ein anderer
> Grund oist, dass C (insbesondere als freestanding implementation) fuer
> das programmieren von Mikrocontrollern im Einsatz ist, fuer die es keine
> brauchbare C++ Implementierung gibt.
Für manche einfache Microcontroller wie 8051 oder so nicht, aber alles
> C ist aus vielen Gruenden noch vorhanden ud wird auch nicht so schnell
> komplett durch anderes ersetzt werden. Zum einen weil es noch sehr viel
> C-Sourcen von Software gibt, die noch in Gebrauch ist (und nicht alles
> davon laesst sich ohne Aenderungen mit C++ uebersetzen, ohne dabei ggfs.
> Bugs einzuschleppen, denn es gibt auch beim gemeinsamen Subset von C
> und C++ ein paar kleine aber gemeine Unterschiede ...). Und ein anderer
> Grund oist, dass C (insbesondere als freestanding implementation) fuer
> das programmieren von Mikrocontrollern im Einsatz ist, fuer die es keine
> brauchbare C++ Implementierung gibt.
für was ein gcc-Backend geschrieben wurde doch.
Aber andererseits kann man bei solchen Mini-Projekten für acht-bittige
Microcontroller auch bei C bleiben - da tut das nicht so weh, dass man
leichter Fehler macht oder eine gravierend geringere Produktivität hat.
Man hat ja keine Riesen-Projekte zu stemmen wo man auf die Zeit gucken
muss.
> Zum ersten Punkt: Bei einem Projekt wie z.B. bind (mit > 100.000 Zeilen
> Quelltext) will (verstaendlicherweise) niemand mal eben den gesamten
> Source auf moegliche Inkompatibilitaeten zwischen C und C++ durchsuchen.
> Und wenn man ehrlich ist, benutzt bei C++ doch nahezu jeder nur einen
> Teil der Sprache, und beherrscht den nicht benutzten Teil der Sprache
> oftmals noch nicht einmal (was dann die Wartung von fremdem C++ Code
> teils schwierig macht) ... Der Sprachumfaang von C ist so ueberschaubar,
> dass nahezu jeder brauchbare C-Programmierer den gesamten Sprchumfang
> kennt.
Zusätzliche Sprachmerkmale sind aber schnell erlernt.
Bonita Montero
Oct 11, 2021, 1:08:00 PM10/11/21
to
Achja, und nochwas: ab einer gewissen Projekt-Größe lohnt es sich auf
jeden Fall auf eine modernere Sprache zu setzen. Dann fällt selbst das
Erlernen von C++ nicht mehr ins Gewicht.
Ich möcht nicht wissen wie buggy ein Projekt wie Chrome wäre wenn es
in C programmiert wäre - der Code wäre sicher mindestens fünfmal so
groß und es wären sicher mindestens 10 x so viele Bugs drin. Eigent-
lich schon fast unmöglich, sowas in C hinzukriegen.
jeden Fall auf eine modernere Sprache zu setzen. Dann fällt selbst das
Erlernen von C++ nicht mehr ins Gewicht.
Ich möcht nicht wissen wie buggy ein Projekt wie Chrome wäre wenn es
in C programmiert wäre - der Code wäre sicher mindestens fünfmal so
groß und es wären sicher mindestens 10 x so viele Bugs drin. Eigent-
lich schon fast unmöglich, sowas in C hinzukriegen.
Laurenz Trossel
Oct 11, 2021, 1:10:27 PM10/11/21
to
On 2021-10-11, Juergen Ilse <ne...@usenet-verwaltung.de> wrote:
>> Ein Stichwort lautet »AlterNIC«, der Vorfall war im Juli 1997.
>> Ein Stichwort lautet »AlterNIC«, der Vorfall war im Juli 1997.
> Meines Wissens nach hat es eine damit wirklich vergleichbare "DNS Katastrophe"
> seither nicht wieder gegeben (wohl aber andere Angriffe und teils auch spuer-
> bare Beeintraechtigungen des DNS Dienstes, nur icht so umfassend wwie damals.
Besonders umfassend war auch dieser Vorfall nicht. Kashpureff hat damals in
> seither nicht wieder gegeben (wohl aber andere Angriffe und teils auch spuer-
> bare Beeintraechtigungen des DNS Dienstes, nur icht so umfassend wwie damals.
einer Reihe von Caches (nicht Root-NS) die Adresse internic.net auf
AlterNIC umgeleitet.
Vergleichbare Katastrophen hat es seither immer wieder gegeben. Stichwort
»Kaminsky Attack«. Ich erinnere mich zum Beispiel, daß der öffentliche
djbdns Cache des CCC vergiftet wurde.
https://www.ccc.de/de/updates/2014/cache-poisoning-attack
https://www.heise.de/security/meldung/DNS-Server-des-CCC-Anfaellig-wegen-veralteter-Software-2112171.html
Kompetente Angreifer verwenden inzwischen BGP-Redirects, um die Adresse der
Nameserver zu übernehmen. In diesem Fall AWS Route 53:
https://www.theregister.com/2018/04/24/myetherwallet_dns_hijack/
In anderen Angriffen wurden Domains mittels gefälschter Dokumente
übertragen, trotz fehlendem Authcode.
0 new messages