Domain Name Service + SRV-Record

[uenetz]

Hallo Forenmitglieder,

ich habe eine kleine spezielle Frage zur Auflösung, resp. Nutzung von SRV-Eintrage durch beispielsweise Webbrowser, FTP-Clients, SIP-Clients und noch einiges Mehr.

Gegeben ist:

Im DNS ist ein SRV-Eintrag gesetzt, der besagt, dass alle HTTP-Anfragen an einen FQDN auf den Port 81 des gleichen FQDN geleitet werden sollen.

Beim Versuch mich mittels Firefox oder IE mit dem Webserver zu verbinden, greift dieser nicht auf Port 81, sondern auf den Standardport (80) zu.

Werden SRV-Einträge überhaupt von Clients wie Firefox, IE und Konsorten unterstützt?

Bis jetzt vermute ich mal sehr stark, dass es nicht an den SRV-Einträgen auf dem DNS-Server liegt, da diese problemlos (ohne Fehlermeldung) eingetragen werden konnten.

Denn mal im Vorfeld danke für Euere Anworten.

Wünsche allen einen schönen Sonntag.

Gruß,

uenetz

[uenetz]

Hallo allerseits,

ich möchte mich noch mal melden, mit dem immer noch bestehenden Problem.

Immer noch weiss ich nicht, warum der Browser den SRV-Record nicht erkennt, lesen kann, was auch immer.

Bei einer NS-Abfrage bingt er brav das richtige Resulltat.

Beispiel Hostabfrage unter Linux:

root@ldev2:~# host -t SRV _http._tcp.homer.uenetz.de

_http._tcp.homer.uenetz.de has SRV record 0 1 8080 homer.uenetz.de.

Was kann ich vergessen haben, oder woran habe ich nicht gedacht?

[robotto7831a]

Vielleicht liegt es auch einfach daran, dass der Browser sagt http Protokoll ist Port 80.

[uenetz]

Klar, der Browser scheint die Infos des SRV-Records entweder nicht zu nehmen, oder nicht zu interpretieren.

Die große Frage ist nur WARUM nicht.

[robotto7831a]

Stellen wir die Frage anders herum. Warum sollte er? Mit dem Protokoll HTTP ist für den Browser alles klar.

Das HTTP Protokoll auf einem anderen Defaultport umzubiegen ist doch eher ungewöhnlich und kommt im Internet nicht vor.

Man müsste jetzt in die RFC schauen ob dieser Fall überhaupt behandelt wird.

[uenetz]

Das würde ja heisst, dass der SRV-Record in diesem Falle unbrauchbar wäre.

Laut "spärlicher" Dokumentation, sollte es, so wie ich es verstanden habe, funktionieren.

Wie gesagt, sollte

[Crash2001]

Wieso soll er denn überhaupt auf einen anderen Port umgeleitet werden? Ich verstehe den Sinn dahinter nicht.

Standardport ist nunmal Port 80 und der Kompatibilität wegen sollte man den auch nutzen.

Wenn du für dich selber irgendetwas laufen lassen willst, was auf Port 81 läuft, dann schreib einfach ein :81 hinter die URL und fertig. Da brauchst du dann keinen SRV-Eintrag für.

Hast du auf dem Webserver nicht die Möglichkeit, anhand der eingegebenen URL die entsprechende Seite aufzurufen (Stichwort VHosts unter Apache z.B.) oder per entsprechendem redirect das zu regeln, falls mehr als nur eine Seite auf dem Server laufen sollte und du aus dem Grund auf Port 81 ausweichen willst?

(Da ich nicht so ganz verstehe, was du damit bewirken willst, bzw. wieso du das machen willst, kann ich bei alternativen Möglichkeiten auch nur raten bisher.)

Wenn ich das richtig verstehe, kann per DNS anhand des SRV-Eintrag abgefragt werden, welche Dienste auf welchem Port laufen.

Ob der Webbrowser dies dann auch in irgendeiner Art und Weise interpretiert (bzw. abfragt) ist, wenn ich das richtig verstehe, komplett unabhängig davon, da er ja gar nicht beim DNS nach dem Dienst oder Port anfragt, sondern nur nach der Namensauflösung (IP-Adresse) für eine bestimmte URL.

Wenn der Browser HTTP in der Adresszeile sieht, interpretiert er das als das HTTP-Protokoll, und nicht explizit ein anderer Port angegeben ist, dann fragt er den Webserver auf Port 80 an. Danach werden die Ports ja eh dynamisch ausgehandelt.

Siehe hier

[uenetz]

Was ich damit bewirken will, ist ganz einfach!

Hauptgrund: Beim Aufruf einer Url im Browser soll autom. vom DNS der Zielport mitgegeben werden.

Andere Möglichkeit: Lastenverteilung, VoIP (SIP), ...

[Crash2001]

Das wird aber nicht so funktionieren, wenn ich das richtig verstehe, da diese Abfrage einfach nicht vorgesehen ist im HTTP-Protokoll.

Lastverteilung kannst du per DNS z.B. anhand Round-Robin-Verfahren (mehrere IPs, die immer abwechselnd zurückgegeben werden) machen.

Das hilft aber nur, wenn mehrere Anfragen kommen, da der gleiche User die Antwort noch im DNS-Cache vorliegen hat und bei einer neuen Auflösung der URL kurz nach der letzten keine DNS-Abfrage mehr macht, da er das Ziel ja bereits kennt und es somit nicht neu aufgelöst werden muss.

Dafür müsste entweder der DNS-Cache auf dem Client manuell geleert werden, oder aber der Eintrag aus dem Cache schon ausgetimed sein.

Lastverteilung per DNS

Für HTTP wäre also somit wohl ein Redirect am sinnvollsten.

Was jedoch eine Lastverteilung nun mit einem anderen Port zu tun hat, erschliesst sich mir dennoch nicht so ganz. Der Port wird nur für den Aufbau der Verbindung genutzt und danach werden dynamisch Ports ausgehandelt zwischen Server und Client.

Oder willst du auf einen Router weiterleiten, auf dem die Ports entsprechend auf verschiedene Systeme weitergeleitet werden? Da würde es dann noch andere Möglichkeiten geben.

Beschreib doch mal den Aufbau von dem, was du vor hast, damit man dir eventuell besser helfen kann.

P.S..

Bei anderen Diensten KANN es durchaus mit einem SRV-Eintrag funktionieren, falls der Client für das entsprechende Protokoll die vom DNS-Server zur Verfügung gestellten Werte denn auswertet / verarbeitet.

Es kann jedoch genauso sein, dass die Datenmenge zu gross ist und sie abgeschnitten wird. Darüber wird der Client zwar informiert, aber bei HTTP z.B. reicht ihm die IP-Adresse als Antwort vollkommen aus, so dass die Abfrage nicht noch einmal per EDNS aufgelöst wird.

Unter Wikipedia werden die folgenden Dienste genannt, die dies wohl unterstützen:

• XMPP (Jabber)
  
• SIP
  
• LDAP
  
• Kerberos
  
• Teamspeak3 (seit Client-Version 3.0.8)
  
• Minecraft (seit Vollversion 1.3.1)

[uenetz]

Beschreib doch mal den Aufbau von dem, was du vor hast, damit man dir eventuell besser helfen kann.

Zuerst mal danke für den ausführlichen Beitrag

Mein Vorhaben ist folgendes:

Ich möchte an einem Internetanschluss folgende Geräte auch WAN-Seitig erreichbar machen.

- 2 NAS ( FTP, HTTP)

- 2 RPi mit jeweils zumindest HTTP, SSH

- VPN

- 1 Server (SSH, FTP)

- geplant Betrieb von 2 IP-CAM's

Der Zugriff auf die Geräte / Dienste soll über den FQDN erfolgen, der dann mittels dem SRV-Record autom. auf den dazu selbst vorgegebenen Port verbindet.

[Crash2001]

Also da würde ich mir ehrlich gesagt gar keinen großen Aufwand machen, sondern einfach Port-Weiterleitungen am NAT-Router machen und dann den entsprechenden Port mit Doppelpunkt getrennt hinter die URL schreiben.

Zur Not halt eine kleine Linksammlung machen, in der die Links mit angegebenem Port drin stehen.

Oder aber du "missbrauchst" die Standardports / Protokolle einfach dafür.

Wenn du mit einem Webbrowser ftp://URL eingibst, dann wird für diese URL der Port 21 genommen statt dem Port 80. das kann man sich durchaus zunutze machen.

Ein anderes Beispiel wäre Port 443 als Standardport für das Protokoll HTTPS (https://).

Wenn du per FTP nicht auf dem Standardport zugreifen willst, hast du somit schon mal 3 "URLs", die du so nutzen kannst.

Für mehr muss man halt den Port mit angeben, oder aber einen kleinen Apache aufsetzen, der als Weiterleitungssystem mit VHosts dient (für den HTTP-Zugriff).

Eine andere Möglichkeit wäre halt, wenn du auf IPv6 gehen würdest, da damit das System jeweils direkt angesprochen werden könnte. Ich denke aber mal nicht, dass alle deine Systeme überhaupt schon IPv6 unterstützen.

[uenetz]

Das wäre natürlich auch eine Möglichkeit, mit einer Linkliste zu arbeiten.

Allerdings ist dann die Frage warum es per SRV-Record nicht funktioniert immer noch offen.

In den RFC's ist, was ich gelesen habe, die Nutzung von http, ftp, etc. nicht ausgeschlossen.

Einfach mal am Ball bleiben, vielleicht kommt irgendwann mal eine Klärung des Problems.

Vielen Dank an Dich Crash2001!

[Crash2001]

[...]Allerdings ist dann die Frage warum es per SRV-Record nicht funktioniert immer noch offen.[...]

Du könntest ja einfach mal per Wireshark / Ethereal o.ä. schauen, was für Pakete gesendet werden.

Vielleicht sendet der DNS-Server (denke doch mal, dass der bei dir lokal steht, oder?) die entsprechenden Informationen gar nicht, wenn nicht danach gefragt wird. Also vielleicht müsste gefragt werden, welche Dienste zur Verfügung gestellt werden, damit die entsprechenden Informationen mitgesendet werden, statt dass einfach nur eine DNS-Auflösung angefragt wird.

Klar ist es für FTP, HTTP, HTTPS, u.s.w. nicht ausgeschlossen, aber dafür muss der Client diese Informationen auch anfragen und auswerten.

Ich denke einmal, bei den genannten Programmen / Protokollen wird an den DNS nicht nur eine ganz normale Anfrage zur DNS-Auflösung gestellt, sondern es wird angefragt, auf welchem Port der entsprechende Dienst läuft.

Wenn man es manuell per nslookup überprüfen will, muss man ja auch set type=all eingeben, damit die Infos überhaupt angezeigt werden.

siehe hier (Punkt Nslookup)

Ich gehe also davon aus, dass bei einer Standardanfrage (Auflösung eines Namens) diese Werte gar nicht abgefragt bzw. nicht geliefert werden und somit auch nicht ausgewertet werden können.

[uenetz]

Hier das Resultat der dig-Abfrage.

Daraus ist zu entnehmen, dass der NS die Daten fehlerhaft zurückliefert.

Daher vermute ich, dass das Problem nicht am Nameserver liegt.

Leider ist der NS an einem externen Standort. D.h. die serverseitige Diagnose (protokollierung der Pakete) ist nicht möglich.

root@ldev2:~# dig _http._tcp.homer.uenetz.de ANY

; <<>> DiG 9.8.1-P1 <<>> _http._tcp.homer.uenetz.de ANY

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47795

;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:

;_http._tcp.homer.uenetz.de. IN ANY

;; ANSWER SECTION:

_http._tcp.homer.uenetz.de. 86400 IN SRV 0 1 8080 homer.uenetz.de.

;; ADDITIONAL SECTION:

homer.uenetz.de. 60 IN A 88.134.191.12

;; Query time: 25 msec

;; SERVER: 192.168.178.1#53(192.168.178.1)

;; WHEN: Tue Oct 15 08:27:59 2013

;; MSG SIZE rcvd: 95

[Crash2001]

Was genau ist denn da fehlerhaft dran? :confused:

Wenn ich das richtig lese, soll es auf Port 8080 gehen.

[uenetz]

Ohhhh, vertippt

Es sollte NICHT fehlerhaft heisst, entschuldigung!

Genau, er soll auf Port 8080 gehen.