Symbol wieloznaczny DNS z BIND

Próbuję skonfigurować BIND, aby przechwytywał wszystkie żądania do niego kierowane i wskazywał na określony zestaw serwerów NS i określony rekord A.

Mam około 500 domen i dodaję nowe w tempie 10-15 dziennie, więc nie chcę jawnie dodawać strefy dla każdej domeny.

Moja obecna konfiguracja to: w moim named.conf mam widok (nazwany zewnętrzny) z następującą strefą:

zone "." {
        type master;
        file "ext.zone";
};

To pasuje do wszystkich żądań.

ext.zone to:

3600 USD
@ IN SOA. root.nsdomain.com. (
                              1; Seryjny
                         3600; Odświeżać
                          300; Spróbować ponownie
                         3600; Wygasać
                         300); Ujemne buforowanie TTL


        IN NS ns1.przyklad.com
        IN NS ns2.example.com

ns1 IN A 192.0.2.4
ns2 IN A 192.0.2.5

*. IN A 192.0.2.6

więc celem jest: dla wszystkich żądań NS, zwróć ns1.example.comi ns2.example.com dla wszystkich żądań A, z wyjątkiem miejsca, w którym znajduje się ns1.example.comlub ns2.example.com, zwróć 192.0.2.6. Do ns1.example.comzwrotu 192.0.2.4, do ns2.example.comzwrotu 192.0.2.5.

To prawie działa, jedynym problemem jest to, że kiedy robię kopanie, otrzymuję:

dig @localhost somedomain.example

; > DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_5.3> @ localhost somedomain.example
; (Znaleziono 1 serwer)
;; opcje globalne: printcmd
;; Mam odpowiedź:
;; kod operacji: QUERY, status: NOERROR, id: 37733
;; flagi: qr aa rd; ZAPYTANIE: 1, ODPOWIEDŹ: 1, ORGAN: 2, DODATKOWE: 2

;; SEKCJA PYTANIA:
; somedomain.example. W

;; SEKCJA ODPOWIEDZI:
somedomain.example. 3600 IN A 192.0.2.6 // zgodnie z oczekiwaniami

;; SEKCJA ORGANU:
. 3600 IN NS ns1.przyklad.com. // oczekiwany, nie wiem czy „.” na początku jest źle.
. 3600 IN NS ns2.example.com. // patrz wyżej.

;; SEKCJA DODATKOWA:
ns1.przyklad.com. 3600 W A 192.0.2.6 // nie należy się spodziewać, powinno to być 192.0.2.4
ns2.example.com. 3600 W A 192.0.2.6 // nie należy się spodziewać, powinno to być 192.0.2.5

Jak to naprawić? Czy robię coś okropnego? Czy jest na to lepszy sposób?

Twoje pochodzenie dla strefy zależy .od konfiguracji. Tworzysz rekordy dla ns1.i ns2.zamiast ns1.example.com.oraz ns2.example.com. Ponieważ ns1.example.comi ns2.example.comnie są zdefiniowane, są one zastępowane znakiem wieloznacznym.

EDYCJA: oto edycja twojej konfiguracji i strefy:

zone "example.com." {
        type master;
        file "ext.zone";
};

strefa zewnętrzna:

$TTL    3600
@       IN      SOA     ns1 root (
                              1         ; Serial
                         3600         ; Refresh
                          300         ; Retry
                         3600         ; Expire
                         300 )        ; Negative Cache TTL


        IN      NS      ns1
        IN      NS      ns2
        IN      A       192.0.2.6


ns1     IN      A       192.0.2.4
ns2     IN      A       192.0.2.5

*      IN      A       192.0.2.6

Wszystko w strefie jest względne względem nazwy strefy w nazwanej konfiguracji, więc dodanie drugiej strefy wskazuje tylko na ten sam plik:

zone "example.net." {
    type master;
    file "ext.zone";
};

Aby ustawić symbol wieloznaczny poddomeny bind, należy użyć następującego formatu:

name.tld.   IN  A   IP    # main domain ip
*.name.tld. IN  A   IP    # wildcard subdomains ip

Przykład:

mydomain.com.   IN  A   1.1.1.1
*.mydomain.com. IN  A   1.1.1.1 

W zależności od konfiguracji ns1.example.comjest 192.0.2.4i ns2.example.comjest 192.0.2.5. Musisz skonfigurować rozpoznawanie nazw serwera NS w example.comstrefie, aby uzyskać prawidłowe adresy IP.

Mam nadzieję, że wyrażę się jasno. Wróć do mnie, jeśli potrzebujesz więcej informacji.

Symbole wieloznaczne DNS mogą powodować problemy!

więc nie chcę jawnie dodawać strefy dla każdej domeny.

Jest wiele sposobów - od skryptów SHELL po serwery DNS oparte na SQL.

UPD. (2019-11) : Tak jak powiedziałem 8 lat temu , skrypty SHELL są dobrym rozwiązaniem i zostało to udowodnione za pomocą proponowanego rozwiązania przyjętej odpowiedzi „dodawania wpisu strefy” - najwyraźniej nie w oparciu o użycie symboli wieloznacznych. ;-)

W 2019 r. Jeszcze łatwiej jest znaleźć zasoby wyjaśniające wady symboli wieloznacznych DNS i chociaż większość z nich została napisana „u zarania Internetu”, nadal mają pewną wartość. Na przykład RFC1912 wymienia kilka rzeczy związanych z używaniem symboli wieloznacznych DNS. Główny problem jest jasno wyjaśniony jako „…

Symbole wieloznaczne MX mogą być złe, ponieważ powodują, że niektóre operacje kończą się powodzeniem, gdy zamiast tego powinny zakończyć się niepowodzeniem . … ”

Ma jednak również kilka przykładów z życia, które są trochę staromodne.