Markus: DNS Name wird in .htaccess nicht erkannt?

Hallo,
Ich wollte mal nachfragen, welche Ursache es haben kann, dass mein dynamicdns Name in meiner .htaccess Datei nicht erkannt wird?

Order deny,allow
Deny from all
Allow from test.dnsalias.org

(ist jetzt nich mein richtiger DNS Name, nur ein Beispiel)

Mein DNS Name funktioniert übrigens. Ich kann meinen lokalen Server mit meinem DNS Namen erreichen. Was muss ich in der .htaccess Dateie ändern, damit es funktioniert?

VIele Grüße, Markus.

  1. Ich wollte mal nachfragen, welche Ursache es haben kann, dass mein dynamicdns Name in meiner .htaccess Datei nicht erkannt wird?

    Kurze Antwort: Es können mehrere Namen auf eine Nummer zeigen, aber nicht eine Nummer auf mehrere Namen.

    Lange Antwort: Der Webserver kennt für eine zu ihm hergestellte Verbindung erstmal nur die IP-Nummer der Gegenstelle (à la 123.456.789.012). Damit er prüfen kann, ob der Name (in Deinem Fall test.dynalias.org) stimmt, muß die Nummer rückwärts durch das DNS-System laufen. Sinnvollerweise landet man dann nicht bei irgendeinem Alias-Dienst, sondern bei jenem Netzwerkbetreiber, dem die IP-Nummer gehört. Im Ergebnis wäre das beispielsweise bei Einwahl über die Deutsche Telekom (oder einen ihrer unzähligen Wiederverkäufer) t-dialin.de oder t-ipconnect.de.

    Von daher kann eine Sperre per Domainname nicht mit Alias-Diensten funktionieren.

    Gruß,
      soenk.e

    1. Hallo,
      Danke für die Antwort. Wie kann ich es aber nun schaffen, Benutzer eindeutig zu identifizieren? Es geht hier um ca 200 Besucher, wobei aber mindestens die Hälfte eine dynamische IP haben.
      Ich will auch nicht IP Bereiche freigeben, weil das Schlupflöcher entstehen lässt. Ein Passwortschutz alleine kommt auch nicht in Frage, weil das Passwort weitergegeben werden kann.
      Gibt es keine Möglichkeite Benutzer eindeutig reinzulassen oder rauszusperren?

      Grüße, Markus.

      1. Moin,

        Danke für die Antwort. Wie kann ich es aber nun schaffen, Benutzer eindeutig zu identifizieren? Es geht hier um ca 200 Besucher, wobei aber mindestens die Hälfte eine dynamische IP haben.

        HTTPS mit Client-Zertifikaten.

        Ich will auch nicht IP Bereiche freigeben, weil das Schlupflöcher entstehen lässt. Ein Passwortschutz alleine kommt auch nicht in Frage, weil das Passwort weitergegeben werden kann.

        Japp, du willst eindeutig Client-Zertifikate. Auf Smartcards.

        --
        Henryk Plötz
        Grüße von der Ostsee
        1. Hallo,

          Japp, du willst eindeutig Client-Zertifikate. Auf Smartcards.

          Ich habe leider fast keine Ahnung von Zertifizierungen. Ich habe allerdings die Möglichkeit dazu.
          Ich kann ein SSL Zertifikat bestellen? Ist es das , was du meinst? Und wie bekommen dann meine Besucher Zugang?

          Grüße, Markus

        2. Ich will auch nicht IP Bereiche freigeben, weil das Schlupflöcher entstehen lässt. Ein Passwortschutz alleine kommt auch nicht in Frage, weil das Passwort weitergegeben werden kann.

          Da behaupte ich mal ganz blöd, daß ein HTTP-Passwortschutz deutlich sinnvoller ist als eine Prüfung des DNS-Alias. Auch der Alias ist schließlich über ein Passwort gesichert. Und IP-Adressen lassen sich auch fälschen.

          Japp, du willst eindeutig Client-Zertifikate. Auf Smartcards.

          Aha. Und Smartcards lassen sich nicht weitergeben?

          Eine absolute Identifikation ist sowieso nicht gewährleistet, solange man den Personalausweis nicht persönlich prüfen kann. Und schlimmer: Die Umstände für die Nutzer steigen bei weitem nicht in gleichem Maße wie der technologische Aufwand für die Identifikation.
          Die Weitergabe von Zugangsdaten, egal ob Passwort oder Smartcard, kann davon abgesehen unterbunden werden, wenn mit dem Passwort entweder eine Identität oder der Geldbeutel des Nutzers verbunden ist.

          Warum soll denn diese große Sicherheit geboten sein?

          Gruß,
            soenk.e

          1. Moin,

            Japp, du willst eindeutig Client-Zertifikate. Auf Smartcards.

            Aha. Und Smartcards lassen sich nicht weitergeben?

            Jein. Jedenfalls nicht in dem Sinne, dass auf einmal zwei Kopien der Zugangsberechtigung existieren. Wenn die Benutzer durch die Weitergabe sich selbst den Zugang entziehen, wären sie ja in vielen Fällen schön blöd.

            Warum soll denn diese große Sicherheit geboten sein?

            Das würde ich jetzt aber auch gerne mal wissen.

            --
            Henryk Plötz
            Grüße von der Ostsee
        3. Moin!

          Danke für die Antwort. Wie kann ich es aber nun schaffen, Benutzer eindeutig zu identifizieren? Es geht hier um ca 200 Besucher, wobei aber mindestens die Hälfte eine dynamische IP haben.

          HTTPS mit Client-Zertifikaten.

          HTTPS funktioniert nur mit IPs, Virtuelle Hosts klappen damit nicht. Und dynamische IP-Adressen sicherlich dann auch nicht, weil das Zertifikat auf die IP ausgestellt wird, wenn ich richtig informiert bin (was ich hier aber durchaus selbst anzweifeln möchte).

          - Sven Rautenberg

          --
          Signatur oder nicht Signatur - das ist hier die Frage!
          1. Moin,

            HTTPS funktioniert nur mit IPs, Virtuelle Hosts klappen damit nicht.

            Das ist mir auch klar. Soweit ich sehen kann ging es aber um einen festen Server und mehrere (bzw. sogar ziemlich viele) Clients mit dynamischen IP-Addressen, denen der Zugriff möglichst so gewährt werden soll, dass sie ihre Authentifizierungsdaten nicht weiter geben können. Allerdings könnte meine Glaskugel hier auch überinterpretiert haben. Nur Markus könnte das klarstellen.

            Und dynamische IP-Adressen sicherlich dann auch nicht, weil das Zertifikat auf die IP ausgestellt wird, wenn ich richtig informiert bin (was ich hier aber durchaus selbst anzweifeln möchte).

            Ein Client-Zertifikat wird auf einen Client ausgestellt. Wer auch immer das Zertifikat und die gegebenenfalls dazugehörige Passphrase hat kann sich damit dem Server gegenüber authentifizieren.

            --
            Henryk Plötz
            Grüße von der Ostsee
            1. Ein Client-Zertifikat wird auf einen Client ausgestellt. Wer auch immer das Zertifikat und die gegebenenfalls dazugehörige Passphrase hat kann sich damit dem Server gegenüber authentifizieren.

              Siehe da, das Zertifikat wird mit einem Passwort gesichert, und beides lässt sich wunderbar weiterreichen, egal auf welchem Medium sie gespeichert sind. Das einzige, was man nicht weitergeben kann, sind Finger, Augen und DNS-Material (erste beide zumindest nicht unbedingt;), aber da ist die Technologie momentan wohl eher noch eine Spielerei als ein ernstzunehmendes Sicherheitsmerkmal - vom bereits angesprochenen grausigen Kosten/Nutzen-Verhältnis für den Nutzer mal ganz zu schweigen.

              Das gleichzeitige Einloggen von mehreren Maschinen aus lässt sich im übrigen auch mit dem einfachen Passwortmechanismus in Verbindung mit IP, Cookies und/oder Browserkennung verhindern.

              Kurz: Das wird alles nichts. Eine 99,5%-ige Identitätsprüfung ist nur erreichbar, wenn man dem Nutzer Aug in Aug gegenüber steht.

              Gruß,
                soenk.e

              1. Moin,

                Siehe da, das Zertifikat wird mit einem Passwort gesichert, und beides lässt sich wunderbar weiterreichen

                Eben nicht auf einer Smartcard, solange die nicht deutlich kaputt ist.

                --
                Henryk Plötz
                Grüße von der Ostsee
      2. Moin!

        Danke für die Antwort. Wie kann ich es aber nun schaffen, Benutzer eindeutig zu identifizieren? Es geht hier um ca 200 Besucher, wobei aber mindestens die Hälfte eine dynamische IP haben.

        Jedenfalls gehts nicht über die IP.

        Ich will auch nicht IP Bereiche freigeben, weil das Schlupflöcher entstehen lässt. Ein Passwortschutz alleine kommt auch nicht in Frage, weil das Passwort weitergegeben werden kann.

        Wenn du deinen Benutzern nicht vertraust, gib ihnen keinen Zugriff!

        Selbstverständlich kriegt jeder Benutzer sein eigenes Passwort (und auch einen Usernamen, ist ja klar). Und wenn ein User offensichtlich (wie und was offensichtlich ist, wirst du durch Prüfung der Login-Vorgänge und Aktionen des Users selbst herausfinden müssen) sein Passwort weitergegeben hat, dann sperre den Zugang. Schon ist der User (und der, der das Passwort auch noch hat) draußen.

        - Sven Rautenberg

        --
        Signatur oder nicht Signatur - das ist hier die Frage!
    2. Moin,

      Kurze Antwort: Es können mehrere Namen auf eine Nummer zeigen, aber nicht eine Nummer auf mehrere Namen.

      Dafür will ich einen Beweis sehen. IIRC habe ich kürzlich im Usenet eine Gegenaussage von durchaus kompetenter Seite gesehen.

      --
      Henryk Plötz
      Grüße von der Ostsee
      1. Moin!

        Moin,

        Kurze Antwort: Es können mehrere Namen auf eine Nummer zeigen, aber nicht eine Nummer auf mehrere Namen.

        Dafür will ich einen Beweis sehen. IIRC habe ich kürzlich im Usenet eine Gegenaussage von durchaus kompetenter Seite gesehen.

        DNS ist im Prinzip ein Zeigersystem: Irgendein Element zeigt genau auf ein anderes Element. So sind alle Einträge der DNS-Server aufgebaut.

        Also kann man einen Namen angeben, und diesen Namen auf:
        a) eine IP-Adresse zeigen lassen.
        b) einen anderen Namen zeigen lassen.
        Hierbei ist es auch möglich, einen Namen auf mehrere IP-Adressen zeigen zu lassen - das ermöglicht Load-Balancing.

        IP-Adressen sind beim DNS nichts anderes als Namen der Domain in-addr.arpa, also kann auch eine IP-Adresse auf einen DNS-Namen zeigen.

        Eine IP-Adresse auf eine andere IP-Adresse zeigen lassen, ist unsinnig. Aber was passiert aber, wenn man eine IP-Adresse auf einen Namen zeigen läßt, und in einem zweiten Eintrag dieselbe Adresse auf einen anderen Namen zeigen läßt. Im Prinzip sind IP-Adressen ja auch nur Namen, und man kann einem Namen mehrere IP-Ziele zuweisen - warum nicht auch umgekehrt?

        Allerdings habe ich noch niemals davon gehört, dass eine IP in mehrere Namen aufgelöst werden kann. Und selbst wenn, wäre es immer Aufgabe des Reverse-Zonenverwalters, diesen Eintrag in sein Zonefile zu setzen.

        Und da (um zur Ausgangsfrage zurückzukommen) für die Auflösung der ISP zuständig ist, der zudem den Namen noch dynamisch verändern müßte (genau deswegen benutzt man ja DynDNS, damit ein Name einer wechselnden IP zugeordnet werden kann - will man zur wechselnden IP immer den gleichen Namen auflösen, muß der im DNS-Zonefile mitwechseln - ziemlich aufwendig). Sowas ist kaum zu erwarten, also wird's nicht funktionieren, selbst wenn es tatsächlich gehen würde.

        - Sven Rautenberg

        --
        Signatur oder nicht Signatur - das ist hier die Frage!
        1. Moin,

          DNS ist im Prinzip ein Zeigersystem: Irgendein Element zeigt genau auf ein anderes Element. So sind alle Einträge der DNS-Server aufgebaut.

          Ja, so hatte ich meinen ersten Beitrag in dem Thread hier gemeint.

          Allerdings habe ich noch niemals davon gehört, dass eine IP in mehrere Namen aufgelöst werden kann.

          Sie kann. Grade habe ich den Usenet-Artikel, den ich meinte, wiedergefunden: Message-ID b130hf$vmq$1@valiant.koehntopp.de von Kristian Koehntopp am 27.01.03 in de.comp.lang.php.netzprotokolle. Google-Groups scheint diese Gruppe nicht zu führen, daher hier der Anfang dieses Postings für alle die das nicht mehr auf ihrem Newsserver haben:

          | "Philipp Köppe" philipp.koeppe@stud.tu-ilmenau.de writes:
          | >in einem moment bildet eine ip immer genau auf einen namen ab.
          |
          | Aeh, nein.
          |
          | $ dig -x 195.244.233.50
          |
          | ; <<>> DiG 8.3 <<>> -x
          | ;; res options: init recurs defnam dnsrch
          | ;; got answer:
          | ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4
          | ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 3
          | ;; QUERY SECTION:
          | ;; 50.233.244.195.in-addr.arpa, type = ANY, class = IN
          |
          | ;; ANSWER SECTION:
          | 50.233.244.195.in-addr.arpa.  23h26m10s IN PTR  chicago.koehntopp.de.
          | 50.233.244.195.in-addr.arpa.  23h26m10s IN PTR  white.koehntopp.de.
          [Rest gesnippt]

          Sowas ist kaum zu erwarten, also wird's nicht funktionieren, selbst wenn es tatsächlich gehen würde.

          Ja, das meinte ich. Es ging mir hier nur erstmal um die prinzipielle Möglichkeit einer Nummer die auf mehrere Namen zeigt. Bei dem Ausgangsproblem hilft das natürlich nicht.

          --
          Henryk Plötz
          Grüße von der Ostsee
  2. Moin,

    Mein DNS Name funktioniert übrigens. Ich kann meinen lokalen Server mit meinem DNS Namen erreichen. Was muss ich in der .htaccess Dateie ändern, damit es funktioniert?

    Gar nichts, das geht so nicht.

    Wenn dein Rechner beim Server anfragt, erfährt der Server 'nur' die IP-Addresse deines Rechners. Deswegen kannst du in der Serverkonfiguration schonmal nach IP-Addressen unterscheiden.

    Als Bequemlichkeitsmerkmal bietet dir die Konfiguration anscheinend auch DNS-Namen, aber der Server hat doch nur die IP-Addresse? Dann muß der Server diese IP-Addresse in einen DNS-Namen umwandeln, also einen reverse dns lookup durchführen. Dazu verwurschtelt er die IP-Addresse und versucht den resultierenden Namen ganz normal per DNS aufzulösen. Beim 'Verwurschteln' wird aus 1.2.3.4 der Name 4.3.2.1.in-addr.arpa.

    DynDNS kann dir prinzipbedingt nur Vorwärts-DNS bieten, da sie die Nameserver für (zum Beispiel) dyndns.org kontrollieren. Wenn du Reverse DNS ordentlich eingerichtet haben willst, musst du dich an den Verwalter von 3.2.1.in-addr.arpa (beispielhaft) wenden, und das bei jeder neuen IP-Addresse wieder neu.

    Wenn du dich über einen normalen ISP ins Internet einwählst, bekommst du übrigens in den allermeisten Fällen einen Namen für deine Addresse per Reverse Lookup aufgelöst, aber das ist dann sowas wie pD953D095.dip.t-dialin.net.

    Vorschlag: Nimm doch HTTPS mit Client-Zertifikaten. Ist genauso bequem und deutlich sicherer. Alternativ bräuchtest du ein Tool das nach jedem Addresswechsel die IP-Addresse in der .htaccess ändert (und nach Möglichkeit vor dem Offlinegehen, oder alternativ nach einiger Zeit der Inaktivität wieder zurück).

    --
    Henryk Plötz
    Grüße von der Ostsee