☰

So leiten Sie DNS-Anfragen für die lokale Zone an einen externen DNS weiter, wenn keine lokale Übereinstimmung vorliegt (BIND9)

tag-icon • tag-icon domain-name-system bind
So leiten Sie DNS-Anfragen für die lokale Zone an einen externen DNS weiter, wenn keine lokale Übereinstimmung vorliegt (BIND9)

Ich habe eine Domäne example.comund verwende Azure DNS, um alle Hostnamen aufzulösen, die vom Internet aus sichtbar sein sollen. Ich habe den mail.example.comVerweis darauf definiert 198.51.100.123und er kann von externen Clients problemlos aufgelöst werden.

Das example.comwird auch in meinem LAN verwendet und löst mit bind alle lokalen IP-Adressen auf, was für die lokalen Hostnamen gut funktioniert. Mein DHCP-Server weiß auch damit umzugehen und aktualisiert die Zonendateien ordnungsgemäß. Alle DNS-Anfragen für andere Zonen werden an Cloudflare DNS weitergeleitet.

Ich möchte, dass mein Server den lokalen Nameserver verwendet und wenn er keinen Eintrag in der lokalen Zonendatei findet, soll er den Azure-Server kontaktieren und diesen prüfen. Wenn ich meiner Zonendatei die folgenden Einträge hinzufüge, funktioniert es für diese Hostnamen:

external-dns            A       1.1.1.1
vpn                     NS      external-dns
www                     NS      external-dns
ftp                     NS      external-dns

Platzhalter funktionieren in Bind9 nicht mehr, daher kann ich nicht verwenden * NS external-dns. Gibt es eine andere Möglichkeit, dies zu erreichen?

Antwort1

Verwenden Sie eine response-policyZone anstelle einer Masterzone fürexample.com

Beim Versuch, einen Hostnamen aufzulösen, sucht Bind response-policyzuerst in der Zonendatei und setzt die Suche fort, wenn es keine Antwort findet.

Hier ist ein Beispiel-Setup:

options {
    # Your normal options
    response-policy { zone "local_example_com"; };
};
zone "local_example_com" {
    type master;
    file "master/local_example.zone";
    allow-query {none;};
};

Fügen Sie dann eine Zonendatei mit dem Namen hinzu, master/local_example.zonedie Folgendes enthält:

$TTL 24H
@    SOA LOCALHOST. named-mgr.example.com (1 1d 1h 30d 2h)
     NS  LOCALHOST.

host1.example.com     A   192.168.1.1
host2.example.com     A   192.168.1.2
host3.example.com     A   192.168.1.3
host4.example.com     A   192.168.1.4

Beim Versuch der Auflösung host1.example.comwird die Antwort aus der Zone abgerufen response-policyund beim Versuch der Auflösung mail.example.comwird die Auflösung mithilfe example.comvon Nameservern durchgeführt.

Antwort2

Da ein Platzhalter nicht möglich ist, habe ich mich für einen anderen Ansatz entschieden:

  1. Alle externen Sites werden auf der Domäne gehostet example.com.
  2. Alle internen Sites werden auf der Domäne gehostet int.example.com.

Es example.comwurde nichts geändert und es ist weiterhin in Azure DNS verfügbar (wie immer). Der interne Bind-Server hostet jetzt die int.example.comDomäne und der DHCP-Server wird ebenfalls aktualisiert, um int.example.comals lokale Domäne zu pushen.

Ich möchte, dass meine internen Websites über HTTPS verfügbar sind. Daher muss ich in der Lage sein, mit LetsEncrypt Zertifikate für die int.example.comDomäne zu erstellen. LetsEncrypt kann meine internen Dienste nicht erreichen, daher muss ich auf die DNS-Verifizierung zurückgreifen.

Ich habe die int.example.comZone als untergeordnete Zone example.comin Azure DNS hinzugefügt. Diese Zone wird keine DNS-Einträge haben, da wir dafür den lokalen Server verwenden. Wir möchten keine internen Informationen an externe DNS-Server weitergeben. Ihr einziger Zweck ist die DNS-Verifizierung für LetsEncrypt, daher sollte AcmeSh über die richtigen Anmeldeinformationen verfügen, um TXT-Einträge zu erstellen/entfernen. Ich bin den Anweisungen gefolgtdieser Leitfadenum die richtigen Anmeldeinformationen zu erstellen. Mein Setup verwendet Azure DNS, aber es sollte mit jedem DNS funktionieren, das Subzonen unterstützt.

verwandte Informationen