EDNS (DNS-сервер)



  • Используется 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?
    Если да, то как бороться?



  • 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

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



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

    @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?



  • Не работал с 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:

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

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


Log in to reply