Назад | Перейти на главную страницу

Настройте bind9 для пересылки запросов как есть и ответа на ответы как есть, или в поисках идеального сервера пересылки

я использую bind9 сервер (A.A.A.A) только в качестве сервера пересылки: запросы перенаправляются на другой DNS-сервер (B.B.B.B). Я вручную спрашиваю B.B.B.B для разрешения домена и получил правильный результат:

$ dig a downloadcenter.intel.com @B.B.B.B
;; ANSWER SECTION:
downloadcenter.intel.com. 182   IN      CNAME   downloadcenter.intel.com.edgekey.net.
downloadcenter.intel.com.edgekey.net. 17879 IN CNAME e11.b.akamaiedge.net.
e11.b.akamaiedge.net.   19      IN      A       172.231.112.37

Я ожидаю этого bind9 сервер A.A.A.A сделает один и тот же запрос к серверу B.B.B.B и вернем адрес 172.231.112.37. Но на самом деле он выполняет два запроса: сначала он запрашивает A downloadcenter.intel.com, во-вторых, он просит A e11.b.akamaiedge.net. Есть ли способ доверять первому ответу и выполнить только один запрос, чтобы B.B.B.B?

Мне это нужно, потому что у меня должен быть один и тот же разрешенный IP-адрес как для A.A.A.A, так и для B.B.B.B. Но если выполняется два запроса, иногда серверы могут кэшировать разные IP-адреса. Это очень часто случается с записями с низким TTL, как эта.

Я покопался в документации, и самый близкий раздел посвящен Фильтрация содержимого, но я не могу найти прямого ответа. Я также пробовал Несвязанный, но у него та же проблема; вот связанная часть исходного кода.

Журнал сервера B.B.B.B это объясняет проблему:

Mon Feb  1 06:56:34 2016 daemon.info dnsmasq[9664]: query[A] downloadcenter.intel.com from 192.168.0.175 ← first query
Mon Feb  1 06:56:34 2016 daemon.info dnsmasq[9664]: forwarded downloadcenter.intel.com to 8.8.8.8
Mon Feb  1 06:56:34 2016 daemon.info dnsmasq[9664]: reply downloadcenter.intel.com is <CNAME>
Mon Feb  1 06:56:34 2016 daemon.info dnsmasq[9664]: reply downloadcenter.intel.com.edgekey.net is <CNAME>
Mon Feb  1 06:56:34 2016 daemon.info dnsmasq[9664]: reply e11.b.akamaiedge.net is 172.231.112.37
Mon Feb  1 06:56:34 2016 daemon.info dnsmasq[9664]: query[A] e11.b.akamaiedge.net from 192.168.0.175 ← extra query
Mon Feb  1 06:56:34 2016 daemon.info dnsmasq[9664]: forwarded e11.b.akamaiedge.net to 8.8.8.8
Mon Feb  1 06:56:34 2016 daemon.info dnsmasq[9664]: reply e11.b.akamaiedge.net is 2.21.192.37

Другая проблема заключается в том, что если клиент спрашивает A.A.A.A Решить downloadcenter.intel.com очередной раз, CNAME еще не истек, но A истек, поэтому bind9 спрашивает B.B.B.B только для A:

Mon Feb  1 07:08:02 2016 daemon.info dnsmasq[9664]: query[A] e11.b.akamaiedge.net from 192.168.0.175
Mon Feb  1 07:08:02 2016 daemon.info dnsmasq[9664]: forwarded e11.b.akamaiedge.net to 8.8.8.8
Mon Feb  1 07:08:02 2016 daemon.info dnsmasq[9664]: reply e11.b.akamaiedge.net is 23.53.35.18

Мне нужен способ пересылки запроса в точности так, как его просили. Bind9 здесь слишком интеллектуален. Есть ли способ отключить bind9 кеш?

Это требуется в моей настройке, потому что я хочу, чтобы сервер B.B.B.B видел исходный запрос клиента. downloadcenter.intel.com каждый раз.

Заменить bind9 с чем-то более тупым? dnsmasq отличный ответ, за исключением того, что A.A.A.A является хостом Windows, поэтому альтернативы ограничены.

Конфиг Bind9 (A.A.A.A):

options {
    dnssec-validation no;
    auth-nxdomain no;    # conform to RFC1035
    listen-on-v6 { any; };
    forwarders {
        B.B.B.B;
    };
    forward only;
};

Сервер B.B.B.B является dnsmasq.

Ваше исходное предположение неверно:

Я ожидаю, что сервер A.A.A.A выполнит тот же единственный запрос к серверу B.B.B.B и вернет адрес 172.231.112.37.

Давайте разберемся с этим.

  • Клиент запрашивает запись типа A названный downloadcenter.intel.com..
  • Такого нет A запись.
  • Рекурсивный сервер не может солгать и сказать, что A Значение записи этой записи является IP-адресом. Вместо этого он должен сообщить об обнаруженном псевдониме.

Остальное просто рекурсия. С точки зрения непрофессионала, если рекурсивный сервер получает рекурсивный запрос (RD установлен флаг), он должен предполагать, что клиент совершенно глупый и что он не сможет выполнять какие-либо собственные рекурсивные поиски. Здесь нет места для секущихся волос, потому что в большинстве случаев это 100% точность. Это заставляет рекурсивный сервер искать псевдонимы до тех пор, пока он не получит ответ терминала, если он существует. В этом отношении стандарт четко сформулирован.