Не добавляйте точку в конце имени RR. Используйте это так:
сервер мой.dns.сервер
зона example.com
ключ example.com некоторые-ключ-данные
обновить удалить example.com 604800 A
обновить добавить example.com 604800 A 192.0.2.1
Отправить
Я только что протестировал его с записью A и MX; у меня сработало, сервер PowerDNS, клиент ISC nsupdate from bind-tools, аутентификация через TSIG, имя ключа для простоты совпадает с именем зоны.
У меня сложилось впечатление, что вы не совсем понимаете, как $ORIGIN и @ работы, поэтому вот небольшое объяснение. Полное объяснение см. RFC1035.
На проводе они никогда не появляются. Это просто удобный "синтаксический сахар", сокращающий ввод и чтение файлов зоны. Следующие три примера определяют идентичные зоны (мне лень заполнять записи SOA, их точные значения не имеют значения для нашей темы):
$ORIGIN пример.com.
@ 604800 В SOA ns1 ....
604800 В НС ns1
ns1 3600 В А 192.0.2.1
@ 3600 В А 192.0.2.5
$ПРОИСХОЖДЕНИЕ .
example.com 604800 В SOA ns1.example.com ....
$ORIGIN ком.
пример 604800 IN NS ns1.example
$ORIGIN ns1.example.com.
@ 3600 В А 192.0.2.1
пример.com. 3600 В А 192.0.2.5
пример.com. 604800 В SOA ns1.example.com. ....
пример.com. 604800 В NS ns1.example.com.
ns1.example.com. 3600 В А 192.0.2.1
пример.com. 3600 В А 192.0.2.5
В первом примере я не указал имя RR в третьей строке (NS RR после СОА RR), поэтому парсер возьмет ее из предыдущей строки. Такое поведение является точной причиной @ наличие синтаксиса: вы не можете оставить поле имени RR пустым, так как оно примет предыдущее имя записи. Если бы я пропустил @ на последней записи я бы определил второй А запись для ns1. Таким образом, чтобы определить запись с именем, равным текущему установленному источнику (это будет «вершина», если источник установлен на имя зоны), вы не можете использовать «пустое имя», потому что это вызовет это «взять предыдущее» поведение.Вы должны либо указать полное имя записи явно с конечной точкой, чтобы оно не добавляло источник (как это написано в других примерах), либо изменить источник, либо использовать специальный символ. @ который говорит синтаксическому анализатору: «не повторяйте предыдущее имя, здесь идет обнаженное происхождение», поэтому последняя строка в первом примере определяет пример.com..
Второй пример — просто красивая демонстрация того, как $ORIGIN и @ работать вместе.
В третьем примере сахар не используется. Это реальные абсолютные данные, хранящиеся в зоне в каждом из этих трех примеров.
Таким образом, ваша запись может быть представлена в файле зоны как пример.com после $ПРОИСХОЖДЕНИЕ ., или же пример.com. где угодно, или @ после $ORIGIN пример.com., или даже пример после $ORIGIN ком., это не имеет значения. Все эти случаи равны. Вероятно, вы ожидаете увидеть вариант "@", но BIND может решить записать его как любой из этих вариантов, так что будьте готовы распознать их все. И вы не можете заставить его использовать какой-то конкретный вариант, извините.
Еще одним предостережением может быть то, что вы читаете файл зоны после обновления, не замораживая его. Обратите внимание на файл «jnl» рядом с файлом зоны; это журнал, в котором впервые сохраняются ваши обновленные данные. Только когда вы делаете rndc заморозить example.com данные записываются в файл зоны (но зона потом блокируется для обновлений, для разблокировки нужно сделать оттепель операции или перезагрузите сервер). Правильный способ проверить, обновлена зона или нет, - выполнить фактический DNS-запрос с копать землю или же хозяин или же нслукап, как вам нравится:
хост -v example.com
