Кажется, я не могу понять, почему мой DNS не работает должным образом, если я запускаю dig с сервера имен, он работает правильно:
# dig ungl.org
; <<>> DiG 9.5.1-P2.1 <<>> ungl.org
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24585
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1
;; QUESTION SECTION:
;ungl.org. IN A
;; ANSWER SECTION:
ungl.org. 38400 IN A 188.165.34.72
;; AUTHORITY SECTION:
ungl.org. 38400 IN NS ns.kimsufi.com.
ungl.org. 38400 IN NS r29901.ovh.net.
;; ADDITIONAL SECTION:
ns.kimsufi.com. 85529 IN A 213.186.33.199
;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Mar 13 01:04:06 2010
;; MSG SIZE rcvd: 114
но когда я запускаю его с другого сервера в том же центре обработки данных, я получаю:
# dig @87.98.167.208 ungl.org
; <<>> DiG 9.5.1-P2.1 <<>> @87.98.167.208 ungl.org
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 18787
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;ungl.org. IN A
;; Query time: 1 msec
;; SERVER: 87.98.167.208#53(87.98.167.208)
;; WHEN: Sat Mar 13 01:01:35 2010
;; MSG SIZE rcvd: 26
мой файл зоны для этого домена
$ttl 38400
ungl.org. IN SOA r29901.ovh.net. mikey.aol.com. (
201003121
10800
3600
604800
38400 )
ungl.org. IN NS r29901.ovh.net.
ungl.org. IN NS ns.kimsufi.com.
ungl.org. IN A 188.165.34.72
localhost. IN A 127.0.0.1
www IN A 188.165.34.72
а named.conf.options - по умолчанию:
options {
directory "/var/cache/bind";
// If there is a firewall between you and nameservers you want
// to talk to, you may need to fix the firewall to allow multiple
// ports to talk. See http://www.kb.cert.org/vuls/id/800113
// If your ISP provided one or more IP addresses for stable
// nameservers, you probably want to use them as forwarders.
// Uncomment the following block, and insert the addresses replacing
// the all-0's placeholder.
// forwarders {
// 0.0.0.0;
// };
auth-nxdomain no; # conform to RFC1035
listen-on-v6 { ::1; };
listen-on { 127.0.0.1; };
allow-recursion { 127.0.0.1; };
};
named.conf.local:
//
// Do any local configuration here
//
// Consider adding the 1918 zones here, if they are not used in your
// organization
// include "/etc/bind/zones.rfc1918";
zone "eugl.eu" {
type master;
file "/etc/bind/eugl.eu";
notify no;
};
zone "ungl.org" {
type master;
file "/etc/bind/ungl.org";
notify no;
};
На сервере работает Ubuntu 9.10 и Bind 9, и если кто-нибудь сможет пролить свет на это для меня, я буду очень счастлив!
Спасибо
хотя я могу раскапывать старую ветку, я делаю это потому, что это один из наиболее релевантных результатов при поиске в Google по запросу «статус запроса отклонен».
В моем конкретном случае я обнаружил, что мне нужно включить allow-query { any; }; в каждом определении зоны в named.conf.
С первого взгляда мне кажется, что он не настроен для прослушивания остального мира из-за listen-on { 127.0.0.1; };. Вам нужно будет добавить туда соответствующий IP-адрес.
Я делаю то же самое, но добавляю параметр allow-query в named.conf.options
NOERROR, когда он не сопровождается записью ресурса (RR), означает, что такой записи нет, поэтому, когда вы получаете ответ NOERROR и нет «записи» при установке «version» в «none», значит, он работает должным образом.
Также есть allow-query оператор конфигурации с BIND9, однако я думаю, что по умолчанию разрешены запросы из любого места.
У меня была точно такая же проблема (статус раскопки NOERROR локально, статус раскопки ОТКАЗАН извне), и решение меняло сопоставление клиентов с «localhost» (что по умолчанию для установки привязки) на «любое» (позже я могу узнать точный IP-адрес моего поставщика доменного имени и ограничить его этим конкретным IP-адресом по соображениям безопасности). Кроме того, я изменил имя представления с local_something на значение по умолчанию. Имя действительно не имеет значения.
view default {
match-clients { any; };
match-destinations { any; };
include "/etc/named.rfc1912.zones";
};
В этом и заключалась проблема с бизнесом с отказом от статуса раскопок. Сразу после того, как я изменил параметр match-clients, мои запросы dig @ 12.34.56.78 mydomain.com начали разрешаться со статусом NOERROR, и поставщик доменного имени (godaddy) немедленно кэшировал запись сервера имен. Поскольку файлы моей зоны уже были правильно настроены, доменное имя мгновенно стало видимым в Интернете.
Однако, чтобы решить эту проблему, я довольно долго бился головой о стену.
Мне пришлось ввести явную ссылку на сеть, которую я хотел разрешить рекурсией. Указание «любой» не помогло. По умолчанию (Ubuntu Server 15) для этого не было записи в /etc/bind/named.conf.options файл.
recursion yes; << needed to add this but did not resolve greater prob
allow-recursion { any; }; << this did not work
allow-recursion { 10.1.0.0/16; }; << this did the trick
Вы уверены, что отправляете запросы в нужное место?
Ваш сервер 188.165.34.72 (r29901.ovh.net) работает BIND 9.5.1-P2.1 - он отвечает на запрос для dig @ip version.bind ch txt как и ожидалось с этой строкой ответа.
Однако указанный выше IP-адрес возвращает NOTIMPL ошибка, даже если в вашем цитируемом файле конфигурации нет ничего о *.bind псевдозаписи и BIND требуют явной настройки для их отключения.
Потому что вы разрешаете рекурсию только с вашего локального компьютера.
Если вы хотите разрешить добавление соответствующего IP-адреса, и вам нужно изменить значение прослушивания для любого адаптера с вашего локального компьютера или поместить IP-адрес интерфейса локального компьютера:
listen-on { any;} or x.x.x.x;