Řešení 1:
hehe, přehlasoval jsem předchozí odpověď, než jsem se trochu pobavil.
Správně, pokud tedy upravíte named.conf
a přidejte následující:
zone "newdomain.com" {
type forward;
forward only;
forwarders { 22.22.22.22; };
};
nyní nebudete moci snadno provádět zpětné vyhledávání, budete muset upravit následující prohlášení o zóně, aby dávalo smysl pro IP adresu (adresy) domény (toto bylo původně obrácené pro 192.168.80.0/24).
zone "80.168.192.in-addr.arpa" {
type forward;
forward only;
forwarders { 22.22.22.22; };
};
Po provedení změn byste měli
-
Zkontrolujte, zda jste nezměnili konfigurační soubory:
named-checkconf
-
Řekněte bindu, aby znovu načetl svou konfiguraci:
rndc reload
(mnohem raději než/etc/init.d/bind reload
)
Mějte na paměti, že to vrátí neautoritativní odpovědi pro doménu. Řešením (a nabídnout lepší místní ukládání do mezipaměti, pokud by byl vzdálený DNS problém) by bylo fungovat jako otrok zóny.
upraveno přidáním forward only;
tvrzení. to způsobí, že dotaz selže po vyzkoušení serverů zadaných v serverech pro předávání, namísto selhání a následného pokusu o standardní vyhledávání. Také upraveno pro změnu /etc/init.d/bind reload na rndc reload
po radě v komentářích.
Řešení 2:
Pokud se pokoušíte optimalizovat a 22.22.22.22 je pro tuto zónu autorizováno, můžete také použít stub zónu:
zone "newdomain.com" {
type stub;
masters { 22.22.22.22 };
};
To dělá něco trochu jinak než přeposílání. Dotáže se serveru 22.22.22.22 na záznamy NS a bude je neustále uchovávat v mezipaměti. To udělá téměř totéž, ale pokud by byl uveden také jiný hostitel NS (řekněme 33.33.33.33), váš server by se o něm dozvěděl a také by ho použil.
Domnívám se, že zde je zakázaná zóna lepší volbou než podmíněné předávání.
Řešení 3:
Můžete fungovat jako otrok pro newdomain.com? tj. provést úplný převod?