Telefonica DNS: Lotterie/Uns- oder Schwachsinn/Protektionismus?

[Eisenfaust]

Hallo.

Seit Juni versuche ich verzweifelt einen VoIP Server (PBX) an das Telefonica/O2 Netz anzubinden. O2 ist - selbst auf schriftliche Anfragen hin - ausweichend, wenn nicht sogar abweisend, wenn es um Zugangsdaten bezüglich VoIP geht. Seit Juni werden im Großraum berlin O2/Telefonica Anschlüsse auf BSA umgestellt.

War mit Hansenet (Alice) noch alles in Butter, begannen mit der Übernahme durch Telefonica/O2 die Probleme. Dabei sind es mehr Probleme im Bereich der Dienstleistungen, bestellte und nie erschienene Techniker und Informationen zur Telephonie.

Im nun akuten, konkreten Fall geht es nach einer Umstellung auf VoIP via VDSL/BSA (Bitstream-Access, Anschlußleitung der Deutschen Telekekom) um die telephonie. Es hat sich infolge unzähliger Debugging Sitzungen herausgestellt, daß der DNS Resolverdienst sehr oft ins Leere greift, weil die Server für die VoIP Registrierung unerreichbar weil nicht auflösbar sind. Schlagwort: nomadische VoIP Anschluß-Nutzung. Die sogenannten "Gurus" des O2 Forums kennen offenbar nichts anderes zur Fehlererklärung und es ist der wohl am häufigsten gebrauchte Begriff.

Egal, konkret liegt folgendes Problem vor.

In unserer Umgebung werden DNS Server (BIND 9.11) verwendet. Gewisse Konstrukte lassen es nicht zu, daß der durch den DHCP offerierte DNS als "Forwarder" genutzt wird. Deshalb bin ich gezwungen, über eine "Split horizon" Konfiguration Forwarder anzugeben - oder besser: ich weiß im Moment nicht, wie ich es dynamisch lösen kann, weil es einige Sicherheitsanforderungen gibt.

Ich habe bei Telefonica durch Recherchen folgende DNS ausgemacht:

/**
* DNS Telefonica/O2
*

ns1.hansenet.de: 213.191.73.65
ns2.hansenet.de: 213.191.74.20
ns3.hansenet.de: 62.109.123.198

ns1.telefonica.de: 62.52.156.92
ns2.telefonica.de: 213.191.76.196
ns3.telefonica.de: 62.52.156.84

**/

Diese Server sind erreichbar, aber: es ist witzigerweise so, daß sie manchmal, manchmal nicht, den SIP Server

sip.alice-voip.de

auflösen könen, dann mal wieder nicht. Es ist wie russisches Roulette, gerade wenn man VoIP Telephone ins Netz bringen muß.

Ich konnte bislang nicht mehr in Erfahrung bringen als die o.a. Server. Es scheint, als würde O2 per Zufall DNS Server wählen oder generieren und diese IP dann per DHCP an den Klienten am Anschluß weiterreichen. Oder es wird ein anderer Mechanismus der Verwirrung und Undurchsichtigkeiten verwendet, ich bin in Sachen DNS verschleierung nicht ganz firm. Vielleicht sind es auch Sicherheitsmechanismen, die ich übersehen habe, so daß diese DNS zwar manchmal Hostadressen auflösen bzw. deren IP Records liefern, aber generell eine sichere Verbindung vorausgesetzt wird. Ich weiß es nicht.

Konkrete schriftliche Anfragen zu diesem Thema hat O2 mit einer nichtssagenden Textbausteinekorrespondenz zu beantworten versucht! Die Hotline, die man mir zu konsultieren empfahl, ist kaum erreichbar und ich bin nicht willens, 30, 40 oder gar 90 Minuten in einer Warteschleife zu verbringen.

Wer Substantielles in dieser Sache beizutragen hat, der möge bitte antworten, ich wäre ihm oder ihr sehr verbunden.

Dank im voraus.

 

[ciesla]

Nomadische Nutzung ist bei O2/Telefonica (direkt) nicht möglich.
Bei easybell (mit Vorleister Telefonica !; und allen anderen aber auch) dagegen sehr wohl. Und bei 1&1 ebenfalls (egal welcher Vorleister).

 

[Eisenfaust]

Es geht nicht um nomadisches Nutzen der Telefonica Dienste - bitte vorher lesen und nicht gleich nach Auffinden von Schlüsselwörtern reflexartig (und in diesem Falle sinnlos) antworten.

Ich BIN(!) O2/Telefonica Kunde und ich MUß(!) innerhalb des Telefonica Netzes einens DNS kontaktieren können, um den symbolischen Namen meines registrierenden SIP Servers sowie des delegierenden Proxies auflösen zu können. Zwar ist es im Moment möglich, eine feste IP zu verwenden , garantiert ist das aber für die Zukunft nicht. Bereits mehrfach hat die IP am Ende des Oktettes gewechselt.

Der Telefonica DNS wird ja wohl via ACL feststellen können, aus welchem Netz ich komme ... und erkennen können, daß ich aus dem O2/Telefonica Netzwerk komme.

 

[sparkie]

in hatte bei einem von mir betreuten Anschluss auch mal massive DNS Probleme. Ich habe sie einfach dadurch 'geloest', indem ich

1. einen eigenen DNS Server im internen Netz verwende, der aufgrund seines Cache nicht alles an die Provider forwarden muss.
und
2. bisweilen oeffentliche DNS Server (wie resolver1.opendns.com oder google-public-dns-a.google.com) statt der Provider-DNS nutze

das hat zumindest Probleme mit schwachsinnigem provider-gegebenen DNS und UDP Paketverlusten dorthin schon mal deutlich reduziert. Die Endanwender merken dann oft gar nichts mehr davon...

Gewisse Konstrukte lassen es nicht zu, daß der durch den DHCP offerierte DNS als "Forwarder" genutzt wird.

Warum das denn?
Um welche Konstrukte handelt es sich?
Ist nicht das die eigentliche Ursache des Problems (speziell wenn O2 interne Server aufgeloest werden sollen)?
Hast du nicht mal (testweise) versucht ob das Problem verschwindet wenn eben doch die durch den DHCP offerierten DNS als "Forwarder" genutzt werden?

 

[ciesla]

@ Eisenfaust:
Wenn Du solche "wichtigen" Sachen brauchst, dann mußt Du halt einen Tarif mit fester IP bestellen.
Oder dafür sorgen, daß Deine jeweils aktuelle IP sekundengenau dahin übermittelt wird, wo sie gebraucht wird. Dafür gibt es doch Lösungen.

Anm.: sparkie war teilweise schneller.

 

[PeterPawn]

@Eisenfaust:
Noch mal für mich, weil mich jetzt Ausflüge zu festen IP-Adressen (Für den eigenen Anschluß? Wie löst das jetzt das Problem der unzuverlässigen DNS-Auflösung über die Provider-Server genau? Oder gibt es jetzt auch Tarife, bei denen eine feste Adresse für den SIP-Server beim Provider gebucht werden kann?) eher verunsichern ... eigentlich geht es bei Dir darum, daß einige Clients mit einer VoIP-PBX zu verbinden (es klingt halt komisch, wenn Du von "VoIP Telephone ins Netz bringen" schreibst) und diese wiederum mit dem SIP-Server beim Provider. Dabei klappt aber dann (beim Erneuern von Registrierungen für irgendwelche Nummern oder einen Trunk) sporadisch die DNS-Auflösung über den Provider-DNS nicht und damit steht der Server (die PBX) im Wald.

Soweit alles richtig verstanden meinerseits?

Nur wenn die Antwort "ja" lautet, geht es weiter ...

Die erste Frage wäre dann, wie lange und wie schnell hintereinander denn die PBX (sicherlich ja irgendetwas Asterisk-basiertes) ihrerseits versucht, diese DNS-Auflösung doch noch auf die Reihe zu kriegen und was sie bei einer negativen Antwort oder auch bei einer komplett ausbleibenden dann macht (sind ja zwei unterschiedliche Zusände).

Wenn es bereits ausreicht, eine oder zwei Minuten im 5 Sekunden-Takt neue Abfragen zu generieren (aber wirkliche Abfragen, die auch nicht von einem Resolver-Cache - weder lokal noch auf einem DNS-Server im Netz - geblockt und aus dem Cache beantwortet werden, zumindest nicht bei negativen Ergebnissen, denn bei positiver Antwort kann es Dir ja egal sein), dann kann man ja auch da die eintreffenden Antworten etwas länger "lagern" (DNS-Pakete müßten sich schon mit "iptables" passend ändern lassen, wenn man nur die TTL erhöhen will und ansonsten ungesichertes DNS verwendet wird), was die Frequenz der Anfragen und damit die Chance auf negative Antworten von dort deutlich verkürzen kann.

Es wird ja sicherlich nicht passieren, daß bei O2 auch innerhalb einer (BSA-)Session plötzlich den DNS-Server wechseln will (wäre nicht einmal bei einem DHCP-Renew unbedingt protokollkonform) oder den SIP-Account eines Kunden nun plötzlich nur noch auf einem anderen Server behandeln möchte (abgesehen davon, daß dann alle SIP-Clients beim Kunden (ohne PBX, also mit direkter Anmeldung beim Provider-Registrar) ja auch alle gleichzeitig auf diesen neuen Server "umziehen" müßten). Oder ist das tatsächlich so? Ich bin kein O2-Kunde ...

Wenn es Restriktionen gibt, was irgendwelche DNS-Server (speziell in Firmen) als Resolver einsetzen dürfen (gut nachvollziehbar, schließlich "lernt" der Resolver ja anhand der abgefragten Namen auch, wofür sich der Kunde eigentlich interessiert), dann müßte man eben auf dem DNS-Server dafür sorgen (mit passenden ACLs, notfalls mit einer "fake zone" für "alice-voip.de", bei der man sich selbst als "authoritative" deklariert), daß zu jeder Zeit zumindest die letzte, erfolgreich aufgelöste Adresse für "sip.alice-voip.de" zur Verfügung steht und dann muß die PBX eben versuchen, sich über diese Adresse zu registrieren.

Dann kann man mit einem zweiten, unabhängigen Prozess (der ja durchaus auch von der TTL der jeweils ermittelten Antwort vom Provider abhängig sein kann in Bezug auf Häufigkeit und Startzeit) die Aktualisierung der eigenen Fake-Zone mit den Ergebnissen vom Provider-DNS so lange und so oft versuchen, bis man eine aktuelle Antwort erhalten hat und dann ist erst mal wieder Ruhe, bis deren TTL zu - sagen wir mal - 2/3 abgelaufen ist.

Wenn ich das richtig verstanden habe, ist hier ja das eigentliche Problem, daß die Provider-(DNS-)Server nur unzuverlässig antworten und dann der PBX irgendwann die Idee fehlt, an welcher IP-Adresse sie nun eigentlich ihr SIP-REGISTER wiederholen sollte.

Oder ich habe die Fragestellung dann doch komplett falsch verstanden ... alles ist möglich.

 

[Eisenfaust]

@Eisenfaust:
Noch mal für mich, weil mich jetzt Ausflüge zu festen IP-Adressen (Für den eigenen Anschluß? Wie löst das jetzt das Problem der unzuverlässigen DNS-Auflösung über die Provider-Server genau? Oder gibt es jetzt auch Tarife, bei denen eine feste Adresse für den SIP-Server beim Provider gebucht werden kann?) eher verunsichern ... eigentlich geht es bei Dir darum, daß einige Clients mit einer VoIP-PBX zu verbinden (es klingt halt komisch, wenn Du von "VoIP Telephone ins Netz bringen" schreibst) und diese wiederum mit dem SIP-Server beim Provider. Dabei klappt aber dann (beim Erneuern von Registrierungen für irgendwelche Nummern oder einen Trunk) sporadisch die DNS-Auflösung über den Provider-DNS nicht und damit steht der Server (die PBX) im Wald.

Soweit alles richtig verstanden meinerseits?

Zum Teil schon. Ich setze eine eigene TK/Router Anlage auf, wobei ich hart am Betriebssystem ohne Schnörkel bleibe. Auf dem Router/der Firewall arbeitet in einer Sandbox ein Asterisk. Soweit richtig. In einem Szenario registrieren sich alle Clients (EC Cash System, diverse Telephone, Steuergeräte, die via SIP Daten austauschen) am PBX und der PBX ist dann selber "Client" gegenüber dem ITSP.

Einschub: wie eine feste IP das Problem eines nicht auflösenden DNS lösen soll, bleibt weiterhin ein Rätsel ... mysterium magnum.

Ich habe grundsätzlich bisher freie und undzensierte DNS und DNS Caches verwendet - man kann sich deren IPs leicht mit Suchmaschinen zusammensuchen. Das verhindert, daß Telefonica bei "faulen" Auflösungen auf Werbeseiten oder nach deren Gutdünken für mich günstige Seiten umlenken kann. Oder, was in letzter Zeit häufiger passiert, daß deren "Commodo" DNS Resolver bestimmte Domänen sperrt, weil jemand glaubt, daß sie mißbräuchlich genutzt werden. Wir leben im Land der Maas-Stasi (links bleibt eben links) und in letzter Zeit melden die O2 Commodo DNS Filter öfter mal Sperrungen - ich vermute mal, daß es die O2 DNS sind, denn es passiert nur dann, wenn ich diese als "Forwarder" verwende.

Zum Forwarder: ich wiederhole nochmals, daß ich einen BIND 9.11 verwende, der via "views" ein Split Horizon Setup hat. Die nach "außen" gerichteten Anfragen laufen in der Regel über externe DNS. Hier hatte ich aus den vorgenannten Gründen eben freie DNS Server und Caches eingetragen. Damit funktioniert aber VoIP garantiert nicht mehr! Ich wurde erst im Juno diesen Jahres "zwangsumgestellt" - eine Weile nach der Umstellung haben die externen DNS Server wohl noch "sip.alice-voip.de" auflössen können, was vielleicht auf eine Verzögerung bei einigen DNS hindeutet. Allerdings kommt recht schnell im Asterisk (PJSIP Log) dann die meldung 50X - Empty Response; die DNS Anfrage wird leer beantwortet. Damit kennen weder mein PBX noch, wenn wahlweise so konfiguriert, die übrigen VoIP/SIP Endgeräte ihren O2 Registrar.

Es kommt eigentlich dann noch besser. Nachdem ich glaubte, das Problem damit gelöst zu haben, indem ich dann zähneknirschend doch die O2/Telefonica DNS Server als primäre Forwareder heranzuziehen, klappte das bis letzte Woche ganz gut. Seit Mitte dieser Woche etwa liefern auch sie leere Antworten, bzw. "drill" liefert den Status "REFUSED". Das heißt, cih als O2 Kunde mit einer O2 Pool-IP kann diese DNS Server nicht ansprechen, sie verweigern die Auflösung. Und ich versuche die eingangs erwähnten DNS zu verwenden.

Und wo ich das hier gerade schreibe - die O2/Telefonica DNS lösen gerade jetzt wieder auf - sip.alice-voip.de hat die IP 195.71.31.3, heute Morgen ware es noch 213.20.127.40. An dieser Stelle wird eben deutlich, wie wichtig eben die ITSP eigenen DNS sind, wenn sie ihre Kunden generell mit "nomadischer VoIP Nutzung" terrorisieren und traktieren wollen.

Und wie ich bereits anzudeuten versuchte: die Telefonica DNS (siehe oben) lösen von einem Moment zum nächsten nicht mehr auf und damit läuft nach 1800 oder 3600 Sekunden, je nach Timeout, die Neuregistrierung ins Leere.

Nur wenn die Antwort "ja" lautet, geht es weiter ...

Die erste Frage wäre dann, wie lange und wie schnell hintereinander denn die PBX (sicherlich ja irgendetwas Asterisk-basiertes) ihrerseits versucht, diese DNS-Auflösung doch noch auf die Reihe zu kriegen und was sie bei einer negativen Antwort oder auch bei einer komplett ausbleibenden dann macht (sind ja zwei unterschiedliche Zusände).

Wenn es bereits ausreicht, eine oder zwei Minuten im 5 Sekunden-Takt neue Abfragen zu generieren (aber wirkliche Abfragen, die auch nicht von einem Resolver-Cache - weder lokal noch auf einem DNS-Server im Netz - geblockt und aus dem Cache beantwortet werden, zumindest nicht bei negativen Ergebnissen, denn bei positiver Antwort kann es Dir ja egal sein), dann kann man ja auch da die eintreffenden Antworten etwas länger "lagern" (DNS-Pakete müßten sich schon mit "iptables" passend ändern lassen, wenn man nur die TTL erhöhen will und ansonsten ungesichertes DNS verwendet wird), was die Frequenz der Anfragen und damit die Chance auf negative Antworten von dort deutlich verkürzen kann.

Es wird ja sicherlich nicht passieren, daß bei O2 auch innerhalb einer (BSA-)Session plötzlich den DNS-Server wechseln will (wäre nicht einmal bei einem DHCP-Renew unbedingt protokollkonform) oder den SIP-Account eines Kunden nun plötzlich nur noch auf einem anderen Server behandeln möchte (abgesehen davon, daß dann alle SIP-Clients beim Kunden (ohne PBX, also mit direkter Anmeldung beim Provider-Registrar) ja auch alle gleichzeitig auf diesen neuen Server "umziehen" müßten). Oder ist das tatsächlich so? Ich bin kein O2-Kunde ...

Wenn es Restriktionen gibt, was irgendwelche DNS-Server (speziell in Firmen) als Resolver einsetzen dürfen (gut nachvollziehbar, schließlich "lernt" der Resolver ja anhand der abgefragten Namen auch, wofür sich der Kunde eigentlich interessiert), dann müßte man eben auf dem DNS-Server dafür sorgen (mit passenden ACLs, notfalls mit einer "fake zone" für "alice-voip.de", bei der man sich selbst als "authoritative" deklariert), daß zu jeder Zeit zumindest die letzte, erfolgreich aufgelöste Adresse für "sip.alice-voip.de" zur Verfügung steht und dann muß die PBX eben versuchen, sich über diese Adresse zu registrieren.

Dann kann man mit einem zweiten, unabhängigen Prozess (der ja durchaus auch von der TTL der jeweils ermittelten Antwort vom Provider abhängig sein kann in Bezug auf Häufigkeit und Startzeit) die Aktualisierung der eigenen Fake-Zone mit den Ergebnissen vom Provider-DNS so lange und so oft versuchen, bis man eine aktuelle Antwort erhalten hat und dann ist erst mal wieder Ruhe, bis deren TTL zu - sagen wir mal - 2/3 abgelaufen ist.

Wenn ich das richtig verstanden habe, ist hier ja das eigentliche Problem, daß die Provider-(DNS-)Server nur unzuverlässig antworten und dann der PBX irgendwann die Idee fehlt, an welcher IP-Adresse sie nun eigentlich ihr SIP-REGISTER wiederholen sollte.

Oder ich habe die Fragestellung dann doch komplett falsch verstanden ... alles ist möglich.

Mir ist nicht daran gelegen, eine eigene C Implementierung eines zusätzlichen DNS Resolver Caches zu erstellen, um dem Irr- oder Schwachsinn, den O2 hier fabriziert entgegenzuwirken. Eine eigene Zone, die stets die letzte bekannte und aufgelöste IP des Registrars in einem - dynamischen????? - Cache bereithält, ist nur solange gut, wie eben diese IP auch aus meinem derzeitigen IP Kreis erreichbar ist. Im Moment erreiche ich den Registrar unter der alten IP, siehe oben, nämlich nicht mehr. Das hat ja dann auch Konsequenzen.

Ich weiß nicht, was O2 hier treibt - Security by obscurity? - ein Schlagwort aus alten Zeiten, als in Banken noch die letzte Charge Versager programmieren konnte und so Sicherheit eher nur durch Verwirrung von Russen, Amis und Hausfrauen umsetzbar war.

 

[PeterPawn]

Nun wissen wir genau, was Du alles nicht willst ... aber Du willst ja etwas "Substantielles".

Was erwartest Du jetzt eigentlich genau? Daß hier jemand einen Zaubertrick kennt oder ein "geheimes Flag" bei DNS-Abfragen, mit dem man die Provider-Server zur fehlerfreien und beliebig oft wiederholbaren Namensauflösung überreden kann?

Ich bin etwas ratlos, was Du uns jetzt eigentlich sagen willst bzw. was Du erwartest. Eine (denkbare) Lösungbzw. Ideen für eine solche Lösung sind es ja offensichtlich nicht ... wenn Du eigentlich nur Dampf ablassen willst, dann schreibe doch bitte nicht auch noch auf, daß man Dir antworten möge.

Und ich wüßte nicht einmal, wo ich von einer C-Implementierung eines eigenen Resolver-Caches geschrieben hätte - so eine "fake zone", in der sich ein DNS-Server selbst zur SOA erklärt und die eben nicht über Zone-Transfers von irgendwoher aktualisiert wird (weil fast kein vernünfrig konfigurierter NS mehr einem fremden Server die Übertragung eine kompletten Zone gestattet, schon weil das viel zu leicht als Traffic-Multiplikator benutzt werden kann), sondern durch eigene DNS-Abfragen, ist ja nun eher "das kleine Besteck" und dafür braucht kein Aas eine einzige Zeile in C.

Vermutlich habe ich auch nicht genug Ahnung von DNS, um zu verstehen, warum Du nun schon zum zweiten Mal betonst, daß Du einen Server mit "split DNS" betreibst ... solange Deine PBX sich nicht mal innerhalb und mal außerhalb Deines Netzes befindet (oder wo auch immer Du das wie oft geteilt hast, das kann man ja mit ACLs in beliebig kleine Segmente machen und ich kann mich ganz schwach erinnern, daß ich auch irgendetwas zu den ACLs geschrieben hatte, als es darum ging, diese gefakete Auflösung nur für die PBX und ggf. tatsächlich direkt beim Provider anzumeldende Clients zu machen) bei einer Abfrage Deines Servers, ist das in meinen Augen vollkommen egal, was der "bind" (Welche Version war es noch mal genau? 9.11? Oder doch 9.11.2?) da ansonsten noch so macht.

Entscheidend wäre nur, daß er ganz gezielt für die DNS-Abfragen nach den SIP-Servern von O2 dann auch deren Server verwendet - da spielt ja offensichtlich auch der Datenschutz nur noch eine untergeordnete Rolle, denn nach einer (erfolgreichen) Auflösung des Namens für den SIP-Server (wo man Dich aber zweifellos anhand der IP-Adresse furchtbar tracken könnte) willst Du ja - zumindest gewinnt man den Eindruck beim Lesen - dann auch direkt noch eine Anmeldung bei demselben Provider vornehmen lassen und in aller Regel braucht es dafür erst recht Credentials, anhand derer Du ziemlich eindeutig zu identifizieren bist.

Genau so eine Abfrage der DNS-Server beim Provider nur für eine einzelen Domain kann man eben (notfalls auch auf einem Server mit konfiguriertem Forwarder, wobei ich nicht verstehe, warum man hier überhaupt irgendwelche Forwarder verwenden sollte, solange man nicht ein eigenes AS dahinter hat, wo pausenlos DNS-Abfragen stattfinden und so ein Server als Cache eine Entlastung bringen kann) mit so einer "fake zone" erzeugen (wenn man denn mit dem "bind" umgehen kann - aber es finden sich bestimmt auch passende Anleitungen im Internet) ... dafür braucht man eben nur eine Zonendatei, in der man selbst als SOA eingetragen ist und die für diese Zone als NS-Eintrag genau die Server beim Provider ausliefert.

Schon das würde bei einer "split DNS"-Konfiguration ausreichen, um nur die Abfragen für diese "fake zone" (nennen wir sie "alice-voip.de") an die O2-DNS-Server zu senden und der Rest geht dann ganz normal (rekursiv von den Root-Servern aus) an die jeweiligen zuständigen NS (im Prinzip wäre das sogar so etwas wie eine "private Zensur" des DNS, denn für diese Domain legt man dann selbst fest, wer nun die NS sind und damit indirekt auch, was da noch aufgelöst werden kann). Das löst zwar noch nicht das Problem der fehlenden oder fehlerhaften Antworten von den O2-Servern, aber dafür hätte ja auch der zweite Teil des Vorschlags herhalten sollen. Nun gut ... wer nicht will, der hat schon.

=====================

BTW ... wer schon (nach eigenem Bekunden) einen eigenen DNS-Server benutzt, der kann sich dann ja aussuchen, wie er ihn betreiben will .. er muß auch gar keinen Forwarder mehr verwenden, weil der "bind" problemlos selbst rekursive Abfragen machen kann. Damit geht man schon mal per se dem Problem aus dem Weg, daß irgendein (einzelner) DNS-Betreiber anhand der angefragten DNS-Namen irgendein Profil erstellt. Da sieht dann nämlich nur der Zonen-Eigner selbst, welcher Service innerhalb seiner Zone abgefragt wurde ... die Root-Server sehen nur noch die TLD und die TLD-Server gerade noch die generelle Domain, aber nicht, welchen Service man eigentlich sucht.

Insofern verstehe ich angesichts des "Geblubbers" oben zur DNS-Zensur (Was ist ein "freier DNS-Server" genau? Darf der tagsüber raus und im Sand scharren? Oder meintest Du eher einen "open resolver"?) und faulen Auflösungen durch falsche Antworten auf Anfragen nach unbekannten Namen (das macht ja auch nicht nur O2 so, das gibt es auch bei der Telekom wohl noch heute ... ich muß das auch jedesmal erst bei Kunden deaktivieren, wenn die einen neuen Telekom-Anschluß haben und z.B. VPN mit DynDNS machen wollen) am Ende auch nicht, warum man dann überhaupt einen Forwarder verwenden sollte (und damit irgendeinem Dritten den gesamten DNS-Verkehr "offenbaren" sollte).

Ein "bind"-Server kann selbst jede Rekursion, beginnend bei den Root-Servern, behandeln ... und die Adressen der Root-Server muß man sich auch nicht mit einer Suchmaschine heraussuchen, die findet man "ganz normal" auf der Webseite der IANA: https://www.iana.org/domains/root/servers - solange jetzt die Root- bzw. die TLD-Server nicht direkt eine existierende Domain "verheimlichen" (dann findet die aber auch kein anderer "freier und undzensierter DNS"), ist man damit automatisch auch jedes denkbare Problem einer "Internet-Zensur" über das DNS los, die ansonsten über Provider stattfinden könnte (und tatsächlich immer wieder mal als "Pflicht" der Provider ins Gespräch gebracht wird, z.B. bei Auflösungen für Urheberrechtsverletzungen - in A ist das m.W. sogar inzwischen ausgeurteilt).

 

[Eisenfaust]

Ich gebe Dir Recht.

 

[sparkie]

Wenn du schon die Telefonie von Telefonica nutzt, dann solltest du halt wenigstens dafuer deren DNS verwenden. Laesst sich ja schnell so einrichten.

Falls du Probleme mit nomadischer Nutzung der Telefonica Telefonie hast, dann einfach ueber ein Tunnel loesen. Ein vServer dafuer ist ebenfalls schnell eingerichtet - und fertig.

Telefonica wird deinen Setup (auch wenn er dir nicht gefaellt) nicht fixen. Du musst schon selbst aktiv werden.

Wo ist also das Problem?

 

[Eisenfaust]

Wenn du schon die Telefonie von Telefonica nutzt, dann solltest du halt wenigstens dafuer deren DNS verwenden. Laesst sich ja schnell so einrichten.

Ich verstehe nicht ganz. Nichts anderes will ich in diesem Falle machen und nichts anderes passiert auch - mit den beschriebenen Folgen, siehe oben.

Falls du Probleme mit nomadischer Nutzung der Telefonica Telefonie hast, dann einfach ueber ein Tunnel loesen. Ein vServer dafuer ist ebenfalls schnell eingerichtet - und fertig.

Telefonica wird deinen Setup (auch wenn er dir nicht gefaellt) nicht fixen. Du musst schon selbst aktiv werden.

Wo ist also das Problem?

Was soll dieser Unfug?

 

[PeterPawn]

Wo kommt das Thema "nomadische Nutzung" hier überhaupt her?

Normalerweise ist das die Nutzung von SIP-Telefonie eines Anbieters durch den berechtigten Kunden, aber von außerhalb des Anbieter-Netzes ... der Kunde ist dabei der Umherziehende (eben der Nomade).

Wenn ein Anbieter einen Kunden innerhalb seines Netzes per DNS-Abfragen auf einen anderen Server umziehen lassen will, hat das mit dem, was man gemeinhin unter "nomadische Nutzung" versteht, nichts zu tun.

 

[Olivia19]

Wo kommt das Thema "nomadische Nutzung" hier überhaupt her?

Normalerweise ist das die Nutzung von SIP-Telefonie eines Anbieters durch den berechtigten Kunden, aber von außerhalb des Anbieter-Netzes ... der Kunde ist dabei der Umherziehende (eben der Nomade).

Wenn ein Anbieter einen Kunden innerhalb seines Netzes per DNS-Abfragen auf einen anderen Server umziehen lassen will, hat das mit dem, was man gemeinhin unter "nomadische Nutzung" versteht, nichts zu tun.

Danke für den Hinweis.

 

[Eisenfaust]

Danke für den Hinweis.

Hier ist der Ursprung:

Nomadische Nutzung ist bei O2/Telefonica (direkt) nicht möglich.
Bei easybell (mit Vorleister Telefonica !; und allen anderen aber auch) dagegen sehr wohl. Und bei 1&1 ebenfalls (egal welcher Vorleister).

 

[sparkie]

wer solche Extrawuerste braten will sollte es auch koennen. Statt auf die Provider zu schimpfen.

 

[Eisenfaust]

Um diesen Faden nicht ganz in der Luft hängen zu lassen und um eine eventuelle Hilfe für andere Suchende zu bieten, hier die IP Adressen der Telefonica DNS.

DNS, die auch "sip.alice-voip.de" zuverlässig auflösen:


dns3.telefonica.de: IPv4: 62.109.121.1 oder IPv6: 2a01:c30::530
dns4.telefonica.de: IPv4: 62.109.121.2 oder IPv6: 2a01:c30::531

Nur IPV4 und keine Auflösung der Telephonie-Server:

dns1.telefonica.de: 193.189.250.100
dns2.telefonica.de: 193.189.250.101
dns3-optout.telefonica.de: 62.109.121.3
dns4-optout.telefonica.de: 62.109.121.4

Irgendwo standen diese Angaben im Netz, allerdings konnte ich sie nicht direkt mit den Suchbegriffen "DNS" und/oder "Telefonica/O2" finden.

Der Vollständigkeit halber.