Czy powinienem używać / etc / bind / zone / lub / var / cache / bind /?

Każdy samouczek wydaje się mieć inne zdanie na ten temat. W przypadku moich stref ISC BIND należy użyć /etc/bind/zones/lub /var/cache/bind/? W ostatniej instalacji użyłem, /var/cache/bind/ale tylko dlatego, że zostałem do tego poprowadzony; jednak właśnie zauważyłem tam plik pid dla tej nowej instalacji Debiana, więc doszedłem do wniosku, że użycie „katalogu roboczego” do przechowywania plików strefy prawdopodobnie nie było najlepszym pomysłem. Wygląda na to, że wielu administratorów używa tego, więc nie muszą wpisywać pełnej ścieżki podczas deklarowania nowej strefy.

Na przykład:

file "/etc/bind/zones/db.foobar.com";

Zamiast:

file "db.foobar.com";

Czy oczywiście łatwiej jest pisać, ale czy jest to dobra czy zła praktyka?

Niektórzy mogą również sugerować ustawienie katalogu roboczego na /etc/bind/zones:

options {
    // directory "/var/cache/bind";
    directory "/etc/bind/zones";
}

... ale coś mi mówi, że to nie jest dobra praktyka, ponieważ zakładam, że plik pid zostałby tam utworzony, chyba że to /var/cache/bindprzypadek.

Rzuciłem okiem na stronę podręcznika, ale zdawało się, że nie mówi, do czego służy opcja katalogu, jakieś pomysły dokładnie do czego była przeznaczona?

W twoich strefach głównych powinny one wejść, /etc/bind/zonesponieważ są konfigurowane. Drugorzędne (podrzędne) strefy powinny znajdować się w /var/cache/bind/secondarypodobnych miejscach, ponieważ są to tylko buforowane dane, które można odzyskać z urządzenia nadrzędnego, jeśli dane zostaną utracone.

Podobnie jak womble , zgadzam się z faktem, że /var/cache/bindjest dobry dla stref wtórnych (slave). Z drugiej strony nie uważam, że strefy główne powinny być poniżej /etc. Są to pliki konfiguracyjne tak samo jak zawartość obsługiwana przez Apache, więc powinny być przechowywane gdzieś pod /var, ale nie pod /var/cache.

Dla przypomnienia, systemy oparte na Red Hat przechowują strefy pod /var/named(z których mogą być kopiowane automatycznie /var/named/chroot/var/named). Plik konfiguracyjny to /etc/named.conf.

/ var / lib / bind / - strefy główne i dynamiczne

/ var / cache / bind / - strefy pomocnicze

/ etc / bind / - strefy, które nie powinny się zmieniać przez cały okres istnienia serwera.

Krótka odpowiedź jest taka, że ​​to nie ma znaczenia i jedno z nich będzie działać.

Kiedyś używałem /var/cache/bind, ale teraz zawsze używam, /etc/bindponieważ /var/cachejest to zwykle wykluczone z tworzenia kopii zapasowych (na FHS /var/cache musi być możliwe automatyczne odtwarzanie).

Wszelkie strefy drugorzędne lub dynamiczne nadal są aktywne /var/cache.

To naprawdę nie jest pytanie Bind - odpowiedź zależy od tego, jak zarządzasz swoimi skrzynkami Linux / Unix.

Pracowałem w miejscach o standardach zarządzania zmianami / bezpieczeństwa, które wymagają specjalnej zgody na modyfikacje drzewa / etc na serwerze produkcyjnym i używam Tripwire lub podobnych narzędzi do monitorowania zmian. W tych miejscach pliki o wysokim tempie zmian (tj. Pliki strefy itp.) Byłyby w / var i podlegałyby innemu przeglądowi zmian.

Jeśli zmiana procesu kontroli nie stanowi problemu, faktyczna lokalizacja nie ma większego znaczenia, ale należy zachować spójność. Osobiście uważam, że należy do drzewa / var, ale to raczej nawyk oldschoolowego unixa, jaki mam.

Myślałbym, że / var / cache byłoby czymś, co można usunąć, więc użyłbym czegoś innego.

To, co to jest, nie jest ani standardem, ani wymogiem. BIND nie przejmuje się tym, dopóki jesteś konsekwentny, nie będziesz ślepo edytować plików konfiguracyjnych.

Nie uważałbym plików strefy za dane konfiguracji dokładnie. named.conf i keys.conf są dla mnie konfiguracją, dane strefy to cóż, dane strefy. Po prostu wybierz miejsce - być może nawet katalog użytkownika dedykowany do tego celu - i uruchom go.

W mojej konkretnej konfiguracji używam / local / named, która może być dowiązaniem symbolicznym w innym miejscu na komputerze. Umieściłem named.conf w / local / named / i ustawiłem opcję katalogu również na / local / named. Następnie podaję nazwy plików, takie jak pri / example.com lub sec / example.com, aby zachować strefy, w których jestem autorytatywny, w odróżnieniu od tych, które pobieram z innych źródeł. To pozwala mi usunąć wszystkie pomocnicze i ponownie pobrać bez obaw, jeśli zajdzie taka potrzeba.