EDNS (DNS-сервер)

GUID

Используется BIND 9.7.0-P1 в локальной сети, шлюз на pfSense 2.1.3.
Периодически в логах bind вылезает:


success resolving 'g1.panthercdn.com/A' (in 'com'?) after reducing the advertised EDNS UDP packet size to 512 octets
success resolving 'dsn7.d.skype.net/A' (in 'skype.net'?) after disabling EDNS

В поисках ответа на извечные вопросы (кто виноват? что делать?) наткнулся на статью, в который в качестве виновника упоминаются и firewall.
В частности мой случай описан под заголовком "No EDNS" и звучит как: "from a DSL router that does not support EDNS".

Очень ламерский вопрос: имеет это отношение к pfSense?
Если да, то как бороться?

werter

http://www.linuxquestions.org/questions/linux-newbie-8/dns-issues-bind-9-7-3-a-933485/

Put the below in the top of the named.conf?

Try adding:
server 0.0.0.0/0 {
       edns no;
};
to named.conf

https://kb.isc.org/article/AA-00708/0/Why-does-BIND-log-messages-about-disabling-EDNS-or-reducing-the-advertised-packet-size.html

The usual reasons for problems communicating using EDNS0 and larger UDP packet sizes are mis-configured or broken firewalls and load balancers.

These messages are logged in a category by themselves, so you can configure logging to discard them:
category edns-disabled { null; };

https://groups.google.com/forum/#!topic/comp.protocols.dns.bind/z6jGPsa9CNY

Solution:

add the following lines in /etc/named.conf or /var/named/chroot/etc/
named.conf:

logging {
category lame-servers {null; };
category edns-disabled { null; };
};

Hope to help …

Antonio Carlos de Lima

Пять секунд поиска в гугле.

GUID

Спасибо за Ваш ответ.

@werter:

Пять секунд поиска в гугле.

Естественно я пытался это сделать и убил значительно больше времени, чем 5 секунд.
Однако, это не способствовало решению проблемы.

@werter:

Try adding:
server 0.0.0.0/0 {
       edns no;
};
to named.conf

Это привело к появлению в логах:


named[13928]: error (FORMERR) resolving 'cdn.api.twitter.com/A/IN': 77.88.8.8#53

Остальные два способа, ссылки на которые Вы дали, направлены на отключения сообщения в логах. В основном именно эти советы попадались мне. Меня удивляет способ борьбы с проблемой - отключением упоминания о ней.

Если я правильно понял, то вся эта история из-за криво настроенных dns-серверах, НО возможно, что проблема и в шлюзе (роутере). Собственно и вопрос был: может это быть из-за pfSense? Мог я что-то в нем настроить не так, чтобы вызвать данные сообщения от локального bind?

bill_open

Не работал с bind, но если использовать роутер(хоть hard, хоть soft)с windows server dns, такие проблемы встречаются, когда не настроены\не доступны forwarding(днс пересылки), копайте туда. И банальный вопрос, Bind имеет доступ в интернет?
В дополнение, судя по этой записи


named[13928]: error (FORMERR) resolving 'cdn.api.twitter.com/A/IN': 77.88.8.8#53

Днс не может зарезолвить cdn.api.twitter.com
на windows команда


nslookup cdn.api.twitter.com

А на linux, она выглядит так


Host cdn.api.twitter.com

А лучше погугли. Тебе нужно посмотреть работает ли на сервере bind резолвинг.

GUID

@GUID:

Собственно и вопрос был: может это быть из-за pfSense?

Похоже, что нет.
Настройки выше указанные в теме практически решают проблему. Остается 3-4 адреса, которые вызывают error.