iMil schrieb am 20. Oktober 2014 10:08
> übrigens:
> für den clients, also das zahlungsterminal, ist das keine anfrage
> nach "extern"
Nun, es ist auch eine Sache des DNS-Servers die Anfragen zu
kategorisieren und nicht eine Aufgabe des Clients.
> > Genau, dann erzähle mal welche Kommunikation Deiner Meinung nach
> > legitim für Embedded Geräte wie Zahlungsterminals sind? Irgendwelche
> > DNS-Requests für externe Namen sind es nicht -> geblockt -> keine
> > veruntreute Information!
>
> genau um dieses geht es doch:
> es wird bei den konfigurationen eben nicht unetreschieben, ob es eine
> zahlungsterminal oder irgend ein anderer rechner ist.
> und wenn man das nicht macht, wird von internen DNS-server eine
> anfage an eine unbekannte adresse eben zu einem DNS-server im
> internet weitergeleitet
Problem richtig identifiziert - der interne DNS-Server.
> > > was aber schon zu spät ist, da alleine die anfrage am für die
> > > angefragte domäne zuständigen DNS der datentransport ist.
> >
> > Nope, wieso sollte der Proxy die Namensauflösung anstoßen *bevor* die
> > Authorisierung geprüft ist?
> nochmals:
>
> der client macht eine DNS-abfrage.
> wenn die erlaubt ist, wird sie ohne weitere behandlung durch den
> DNS-server weiter "nach oben" geleitet.
Der DNS-Server macht - sofern so konfiguriert - eine Recursion oder
einen Forward des DNS-Requests zu den ihm bekannten Nameservern im
Internet/seines ISPs.
> ud die antwort kommt zurück.
> da die anfrage aber die datenübertragung ist, ist eine vom DNS
> irgendwie bearbeitete antwort vollkommen unwichtig.
Wir reden aneinander vorbei.
1. Die DNS-Requests des Clients werden nicht an das Internet
durchgelassen, sondern allenfalls von einem internen DNS-Server
akzeptiert. Dies ist durch eine einfache Regel auf einer Firewall
oder einem Router (DROP & LOG source Clients destination any TCP/UDP
53) realisierbar.
2. Der DNS-Server beantwortet den Clients nur die Anfragen für die
interne Zone und gibt Anfragen für externe Zonen gar nicht oder nur
für ganz wenige Zonen (zahlungsdienstleister.tld) per definiertem
Forward weiter. In allen anderen Fällen bekommt der Client dabei eine
NXDOMAIN-Antwort.
> > Wenn ein SMTP-Proxy nur für bestimmte Ziel-Domains zustellen soll,
> > dann wird die Ziel-Domain geprüft bevor eine Auflösung über den DNS
> > erfolgt, alles andere ist absolut unsinnig.
>
> und genau da ist doch das problem:
> alleine die anfrage beim DNS ist die datenübertragung.
> es wird zum zielsystem keinerleit verbindung aufgebaut.
Nein, da auch ein SMTP-Proxy nicht eine Namensauflösung durchführt,
*bevor* die Whitelist für das Ziel abgearbeitet ist, zumindest jeder
"normale" SMTP-Server macht das so, denn die Angaben in MAIL FROM,
RCPT TO, ... werden erst mal textuell bearbeitet (address rewriting,
validation, ...) *bevor* im DNS nach einem zu verwendenden Zielserver
gefragt wird.
> die datenübertragung findet via DNS-namensauflösung von client zum
> DNS-server statt.
Das mag der Client vielleicht wollen, aber es geht nicht, wenn die
Server korrekt konfiguriert sind, weil der DNS-Request gar nicht das
interne Netz verläßt.
> nicht zu dem system, dessen IP von DNS-server zurückgeleiefert wird.
Weder noch, solange der DNS-Server nicht blindlings alle Anfragen aus
dem internen Netz zum Internet weiterleitet - wer allerdings so etwas
macht, der frisst auch kleine Kinder!
> > Aber vielleicht erklärst Du mal Dein Szenario genauer bei dem eine
> > DDNS-Anfrage (DynDNS?) zu einem unbekannten Ziel eine Rolle spielt.
> > Es geht hier um Zahlungssysteme die mit einer Zentrale
> > (Firmenzentrale oder Zahlungsdienstleister) kommunizieren müssen und
> > nicht um Deinen OwnCloud Wald und Wiesen-PC!
>
> warum DynDNS?
>
> der client fargt, zur datenübertragug, immer wieder andere
> servernamen per DNS ab.
Internes Netz -> Client bekommt eine korrekte Antwort
Externe Namen -> Client bekommt vom internen DNS-Server die Antwort
NXDOMAIN, da die Anfrage gar nicht weitergeleitet wird. Keine
Erlaubnis für Rekursion über root-Server oder Forward. Ob da dann ein
ServFail, NXDOMAIN, Refused oder NotAuth zurück kommt ist dabei
nebensächlich.
> de für die domäne zuständige DNS-server liefert die namen der
> abgefragten subdomänen zurück.
Eben nicht, da dieser die Anfrage und damit die veruntreute
Information gar nicht bekommt.
> aber alleine der name der sub-domäne ist schon die datenübertragung.
>
> das hat mit dDNS überhaupt NICHTS zu tun.
Ich habe nur gefragt, weil Du DDNS geschrieben hast und viele
darunter DynDNS verstehen. Dann war das auf Deiner Seite vermutlich
nur ein Vertipper. Deswegen wollte ich eine Klärung Deines Szenarios.
Im Übrigen sollten in einem internen DNS auch die Zonen
127.in-addr.arpa.
255.in-addr.arpa.
0.in-addr.arpa.
254.169.in-addr.arpa.
168.192.in-addr.arpa.
10.in-addr.arpa.
16.172.in-addr.arpa.
...
31.172.in-addr.arpa.
local.
definiert sein um schon mal keinen DNS-Traffic ins Internet zu
produzieren der dann in den Reverse-Zonen nur zu einem
prisoner.iana.org. führt.
Hat mir doch glatt ein "Consultant" erzählen wollen, dass der Windows
DNS automatisch weiß, welche DNS-Anfragen er ans Internet
weiterleiten muss und welche nicht. Selbst nach einem Netzwerk-Trace
war er immer noch der Meinung, dass es ausreichen würde eine Zone
172.in-addr.arpa. zu definieren, denn Windows wisse schon was damit
gemeint sei. :P
> übrigens:
> für den clients, also das zahlungsterminal, ist das keine anfrage
> nach "extern"
Nun, es ist auch eine Sache des DNS-Servers die Anfragen zu
kategorisieren und nicht eine Aufgabe des Clients.
> > Genau, dann erzähle mal welche Kommunikation Deiner Meinung nach
> > legitim für Embedded Geräte wie Zahlungsterminals sind? Irgendwelche
> > DNS-Requests für externe Namen sind es nicht -> geblockt -> keine
> > veruntreute Information!
>
> genau um dieses geht es doch:
> es wird bei den konfigurationen eben nicht unetreschieben, ob es eine
> zahlungsterminal oder irgend ein anderer rechner ist.
> und wenn man das nicht macht, wird von internen DNS-server eine
> anfage an eine unbekannte adresse eben zu einem DNS-server im
> internet weitergeleitet
Problem richtig identifiziert - der interne DNS-Server.
> > > was aber schon zu spät ist, da alleine die anfrage am für die
> > > angefragte domäne zuständigen DNS der datentransport ist.
> >
> > Nope, wieso sollte der Proxy die Namensauflösung anstoßen *bevor* die
> > Authorisierung geprüft ist?
> nochmals:
>
> der client macht eine DNS-abfrage.
> wenn die erlaubt ist, wird sie ohne weitere behandlung durch den
> DNS-server weiter "nach oben" geleitet.
Der DNS-Server macht - sofern so konfiguriert - eine Recursion oder
einen Forward des DNS-Requests zu den ihm bekannten Nameservern im
Internet/seines ISPs.
> ud die antwort kommt zurück.
> da die anfrage aber die datenübertragung ist, ist eine vom DNS
> irgendwie bearbeitete antwort vollkommen unwichtig.
Wir reden aneinander vorbei.
1. Die DNS-Requests des Clients werden nicht an das Internet
durchgelassen, sondern allenfalls von einem internen DNS-Server
akzeptiert. Dies ist durch eine einfache Regel auf einer Firewall
oder einem Router (DROP & LOG source Clients destination any TCP/UDP
53) realisierbar.
2. Der DNS-Server beantwortet den Clients nur die Anfragen für die
interne Zone und gibt Anfragen für externe Zonen gar nicht oder nur
für ganz wenige Zonen (zahlungsdienstleister.tld) per definiertem
Forward weiter. In allen anderen Fällen bekommt der Client dabei eine
NXDOMAIN-Antwort.
> > Wenn ein SMTP-Proxy nur für bestimmte Ziel-Domains zustellen soll,
> > dann wird die Ziel-Domain geprüft bevor eine Auflösung über den DNS
> > erfolgt, alles andere ist absolut unsinnig.
>
> und genau da ist doch das problem:
> alleine die anfrage beim DNS ist die datenübertragung.
> es wird zum zielsystem keinerleit verbindung aufgebaut.
Nein, da auch ein SMTP-Proxy nicht eine Namensauflösung durchführt,
*bevor* die Whitelist für das Ziel abgearbeitet ist, zumindest jeder
"normale" SMTP-Server macht das so, denn die Angaben in MAIL FROM,
RCPT TO, ... werden erst mal textuell bearbeitet (address rewriting,
validation, ...) *bevor* im DNS nach einem zu verwendenden Zielserver
gefragt wird.
> die datenübertragung findet via DNS-namensauflösung von client zum
> DNS-server statt.
Das mag der Client vielleicht wollen, aber es geht nicht, wenn die
Server korrekt konfiguriert sind, weil der DNS-Request gar nicht das
interne Netz verläßt.
> nicht zu dem system, dessen IP von DNS-server zurückgeleiefert wird.
Weder noch, solange der DNS-Server nicht blindlings alle Anfragen aus
dem internen Netz zum Internet weiterleitet - wer allerdings so etwas
macht, der frisst auch kleine Kinder!
> > Aber vielleicht erklärst Du mal Dein Szenario genauer bei dem eine
> > DDNS-Anfrage (DynDNS?) zu einem unbekannten Ziel eine Rolle spielt.
> > Es geht hier um Zahlungssysteme die mit einer Zentrale
> > (Firmenzentrale oder Zahlungsdienstleister) kommunizieren müssen und
> > nicht um Deinen OwnCloud Wald und Wiesen-PC!
>
> warum DynDNS?
>
> der client fargt, zur datenübertragug, immer wieder andere
> servernamen per DNS ab.
Internes Netz -> Client bekommt eine korrekte Antwort
Externe Namen -> Client bekommt vom internen DNS-Server die Antwort
NXDOMAIN, da die Anfrage gar nicht weitergeleitet wird. Keine
Erlaubnis für Rekursion über root-Server oder Forward. Ob da dann ein
ServFail, NXDOMAIN, Refused oder NotAuth zurück kommt ist dabei
nebensächlich.
> de für die domäne zuständige DNS-server liefert die namen der
> abgefragten subdomänen zurück.
Eben nicht, da dieser die Anfrage und damit die veruntreute
Information gar nicht bekommt.
> aber alleine der name der sub-domäne ist schon die datenübertragung.
>
> das hat mit dDNS überhaupt NICHTS zu tun.
Ich habe nur gefragt, weil Du DDNS geschrieben hast und viele
darunter DynDNS verstehen. Dann war das auf Deiner Seite vermutlich
nur ein Vertipper. Deswegen wollte ich eine Klärung Deines Szenarios.
Im Übrigen sollten in einem internen DNS auch die Zonen
127.in-addr.arpa.
255.in-addr.arpa.
0.in-addr.arpa.
254.169.in-addr.arpa.
168.192.in-addr.arpa.
10.in-addr.arpa.
16.172.in-addr.arpa.
...
31.172.in-addr.arpa.
local.
definiert sein um schon mal keinen DNS-Traffic ins Internet zu
produzieren der dann in den Reverse-Zonen nur zu einem
prisoner.iana.org. führt.
Hat mir doch glatt ein "Consultant" erzählen wollen, dass der Windows
DNS automatisch weiß, welche DNS-Anfragen er ans Internet
weiterleiten muss und welche nicht. Selbst nach einem Netzwerk-Trace
war er immer noch der Meinung, dass es ausreichen würde eine Zone
172.in-addr.arpa. zu definieren, denn Windows wisse schon was damit
gemeint sei. :P