☰

Es können keine NS-Abfragen gegen Bind mit Catchall-Konfiguration durchgeführt werden

tag-icon • tag-icon bind nameserver dig
Es können keine NS-Abfragen gegen Bind mit Catchall-Konfiguration durchgeführt werden

Ich habe Bind so konfiguriert, dass alle Domänen erfasst werden und für sie dieselbe IP (A-Eintrag) zurückgegeben wird. Dies ist für einen Domänenparkdienst gedacht, bei dem möglicherweise Tausende von Domänen beteiligt sind.

Nachdem ich die Nameserver für example.com auf meine Nameserver gerichtet habe, wird mir korrekt die Parkhosting-Seite angezeigt.

Das einzige Problem ist, dass die Nameserver-Suche nicht funktioniert. Wenn ich es dig NS example.comtue, bekomme ich nur die SOA-Details zurück, statt der NS-Namen. Allerdings dig example.comwird der korrekte A-Eintrag zurückgegeben.

Ich habe Stunden damit verbracht, verschiedene Dinge auszuprobieren und wäre hierbei sehr dankbar für Hilfe.

Die Konfiguration dafür:

named.conf.local:

zone "." {
    type master;
    file "/etc/bind/zones/db.catchall";
};

db.catchall:

$TTL    604800
@   IN  SOA ns1.mynameserver.com. hostmaster.mynameserver.com. (
             26     ; Serial
         604800     ; Refresh
          86400     ; Retry
        2419200     ; Expire
         604800 )   ; Negative Cache TTL

    IN  NS  ip.addr.for.ns1
    IN  NS  ip.addr.for.ns2 

*   IN  A   ip.addr.for.hosting

Antwort1

Das beobachtete Verhalten entspricht dem erwarteten und korrekten Verhalten für Ihre Konfiguration.
Sie haben also einen Nameserver, der behauptet, für die Root-Zone maßgebend zu sein, und der einen Platzhaltereintrag hat A, der mit allem darunter übereinstimmt. Er hat keine NSanderen Einträge als für die Root-Zone.

Was Sie konfiguriert haben, ist jedoch nicht wirklich korrekt für einen Server, der für viele verschiedene Zonen maßgebend sein soll. Wenn example.coman Ihren Nameserver delegiert wird, sollte Ihr Nameserver diese bestimmte Zone haben (mit mindestens SOAund NSan der Spitze der Zone), nicht nur eine übergeordnete Zone (wie .).
Dinge, die bei dieser Konfiguration falsch sind, sind Antworten auf Anfragen für NS(d. h. es wird behauptet, dass es keine Nameserver für gibt example.com) sowie alle negativen Antworten (negative Antworten haben SOAfür die falsche Zone).

Wenn Sie dies mit einem möglichst korrekten Verhalten tun möchten, jedoch ohne alle Zonen anzugeben (was im Hinblick auf die Richtigkeit am besten wäre), sollten Sie sich meiner Meinung nach eine Nameserver-Software mit hohem Skripting-Faktor ansehen, die so antworten kann, als ob die relevanten Zonen bestimmten Mustern entsprechen (vielleicht basierend auf der öffentlichen Suffixliste?).

verwandte Informationen