Администратор сервера не позволяет мне настраивать DNS

Я обнаружил и исправил аналогичную проблему на нашем сервере MacOS X 10.5.

Оказалось, что это символы скобок «(» и «)» в текстовом поле в одном из файлов зоны DNS. Я использовал текстовый редактор в командной строке, чтобы удалить скобки, и теперь Server Admin снова работает нормально.

В версии 10.5 файлы зоны расположены по адресу /var/named/zones.

Используйте команду grep для поиска в файлах зоны символа ")":

sudo grep -R --include "*" \) .

Прокрутите вывод и найдите что-нибудь необычное. (Все файлы зон будут иметь открывающую и закрывающую круглые скобки вверху; вы ищете запись в файле.) Если вы ничего не найдете, вы также можете найти открывающую скобку с помощью grep.

Обнаружив подозрительный файл, откройте его для редактирования:

sudo nano db.mydomain.zone.apple

Найдите строку, вызывающую нарушение, и удалите символы круглых скобок. Сохранить и закрыть. Перезапустите Server Admin.

Могут быть и другие оскорбительные символы, но в моем случае это всегда были круглые скобки.

Я предполагаю, что в файле зоны есть что-то в формате, немного отличающемся от того, что ожидает администратор сервера (ну, технически servermgrd) - я видел, как его смущает такая простая вещь, как "неправильное" количество пробелов между полями.

Чтобы решить эту проблему, я бы предложил удалить все из файла зоны (тот, который находится в / var / named / zone) под записью SOA, за исключением записей NS (вы сказали, что у вас есть резервная копия, верно?). Это должно выглядеть примерно так:

 ;GUID=34FEA604-B204-A7D7-95A5-B6D812B46454

$TTL 10800
example.com. IN SOA server.example.com. admin.example.com (
    2010042600  ;Serial
    86400       ;Refresh
    3600        ;Retry
    604800      ;Expire
    345600      ;Negative caching TTL
 ) 

example.com. IN  NS server.example.com.

примечание: я не уверен, но думаю, что в конце файла должна быть пустая строка. Если вам нужно сохранить нормальную службу DNS во время устранения неполадок, вы можете переместить другие записи в другой файл зоны - тот, который находится в / var / named - где named будет читать их нормально, но servermgrd не будет смотреть.

В любом случае, когда файл зоны обрезан до минимума, выйдите и перезапустите Server Admin и посмотрите, нормально ли он себя ведет (т.е. можете ли вы просматривать журнал, добавлять записи в зону и т. Д.). Если он работает нормально, попробуйте добавить записи обратно в файл / var / named / zone снова понемногу - я подозреваю, что одна или несколько из них немного странные, и если вы оставите их (т.е. воссоздадите их с сервера Admin, а не добавление в файл зоны напрямую) вы, вероятно, сможете вернуть все в норму.

В пятницу я решил снять DNS и восстановить его. (Вздох).

Лучшие инструкции по началу работы я нашел Вот, хотя я обнаружил, что мне нужно сделать немного больше, чем было там сказано.

Во-первых, я сделал резервную копию DNS (как указано в вопросе вверху).

Я отключил DNS. (Ну, я и хотел. Я выключил его на шаг или два позже, но именно тогда я думаю, что его нужно выключить.)

Я редактировал /etc/dns/publicView.conf.apple чтобы удалить имена всех созданных нами зон, оставив нетронутыми те, которые мы не создавали. Вот файл с большим комментарием посередине, где были все зоны. (На самом деле я не помещал комментарий в файл, я просто удалил записи).

acl "com.apple.ServerAdmin.DNS.public" {192.168.1.254;192.168.5.254;192.168.10.254;192.168.15.254;192.168.20.254;192.168.25.254;192.168.30.254;192.168.35.254;192.168.40.254;192.168.45.254;192.168.55.254;192.168.75.254;192.168.70.254;192.168.80.254;localnets;192.168.65.251;192.168.65.185;192.168.80.0;192.168.65.253;};

//
// This is the view that is shown in Server Admin
// This is an automatically generated file.
// PLEASE DO NOT MANUALLY MODIFY THIS FILE!
// Please make your changes in the named.conf file
//

view "com.apple.ServerAdmin.DNS.public" {
//GUID=3EA358EF-5C55-4619-98D0-5004B310D1B0;

    allow-recursion {"com.apple.ServerAdmin.DNS.public";};

    // ------------------------------------------------ ------------- // В ФАЙЛЕ, КОТОРЫМ МЫ СОЗДАЛИ, БЫЛО НЕСКОЛЬКО ЗОН // Я УДАЛЕНИЕ ИХ. // СЛЕДУЮЩИЕ ЗОНЫ НЕ СМОТРЕЛИ НА СОЗДАННЫЕ МЫ, ПОЭТОМУ Я УБЕЖАЛ // ИХ НА ТАКТЕ // --------------------------- ----------------------------------

    zone "." {
        type hint;
        file "named.ca";
    };
    zone "localhost" IN {
        type master;
        file "localhost.zone";
        allow-update { none; };
    };

    zone "0.0.127.in-addr.arpa" IN {
        type master;
        file "named.local";
        allow-update { none; };
    };

};

Сделав это и перезапустив DNS, администратор сервера все еще был недоволен. Снова выключив DNS, я зашел в /var/named и /var/named/zones папки и удалил все созданные нами файлы. Список до (и после) /var/named выглядит так:

db.100.168.192.in-addr.arpa.
db.15.168.192.in-addr.arpa.
db.20.168.192.in-addr.arpa.
db.203.244.66.in-addr.arpa.
db.34.168.192.in-addr.arpa.
db.40.168.192.in-addr.arpa.
db.5.168.192.in-addr.arpa.
db.55.168.192.in-addr.arpa.
db.65.168.192.in-addr.arpa.
db.75.168.192.in-addr.arpa.
db.somedomain.ab.ca.
db.anotherdomain.net.
localhost.zone
named.ca
named.local
zones/

Я оставил localhost.zone, named.ca, named.local и zones папку, а все остальное удалил. (sudo rm db*).

В /var/named/zones папка выглядела очень похожей, но (похоже) не содержит файлов, которые не были созданы администратором сервера, поэтому sudo rm db* все удалил.

На этом этапе я перезапустил DNS (и, вероятно, перезагрузился) и снова смог работать с администратором сервера.

Теперь мне пришлось заново заполнить все наши записи DNS. К счастью, резервные копии /var/named/db.{$DOMAIN}. (по одному файлу для каждого домена) действительно ясно показывает, что нужно сделать для воссоздания доменов, представляя собой просто список имени хоста, типа записи и IP-адреса, например:

...
silo IN  A 192.168.100.254 
old IN  A 192.168.100.116 
psmain IN  A 192.168.100.121 
mail IN  CNAME ghs.google.com. 
...

Я прошел две трети пути воссоздания обоих наших доменов, когда внезапно Server Admin обнаружил ту же проблему, с которой я начал, а именно, что никто больше не мог использовать его для отображения или редактирования зон. О чувак!

Последняя запись о хозяине, которую я ввел, была ftp. Я решил посмотреть, есть ли это в каком-либо из файлов:

$ cd / private / var / named / зоны
$ grep -R --include "*" ftp.
./db.somedomain.ab.ca.zone.apple:ftp IN  A 192.168.100.254 
./db.somedomain.ab.ca.zone.apple:ftp IN TXT "Was pointing to webserver (192.168.100.116), now pointing to silo (192.168.100.254)."

Я удалил эти две строчки, и администратор сервера снова был счастлив. (Слава Богу).

Проблема, по всей видимости, связана с комментарием для ftp-сервера. (Мы используем очень мало комментариев; их было всего два, и я не видел причин не создавать их. Думаю, в будущем я буду проявлять больше осторожности.) Возможно, это потому, что комментарий содержал IP-адреса.

(Существует также внешняя вероятность, что ftp-сервер, являющийся записью A для машины, на которой уже была запись A, вызвал проблему, но это кажется мне довольно маловероятным.)

Я воссоздал запись ftp как CNAME и не стал комментировать.

Если подумать об этом позже, то изменение записи ftp-сервера, скорее всего, было последним изменением, которое мы внесли в DNS несколько недель назад.

Я закончил переустановку всех хостов и проверил свою работу:

mkdir DNSDiff && cd DNSDiff
# repeat for each domain
cat /path/to/backup/var/named/zones/db.somedomain.ab.ca.zone.apple | sort > old.somedomain.txt
cat /var/named/zones/db.somedomain.ab.ca.zone.apple | sort new.somedomain.txt

diff --side-by-side {old,new}.somedomain.txt
# or, with TextWrangler,
twdiff *.somedomain*
# (or, use the diff tool of your choice.)

Кажется, теперь DNS работает нормально.