Перезапис деяких записів DNS у BIND для внутрішніх мереж


39

У мене є внутрішня мережа з DNS-сервером під керуванням BIND, підключений до Інтернету через єдиний шлюз. Моїм доменом "example.com" керує зовнішній постачальник DNS. Деякі записи в цьому домені, наприклад, "host1.example.com" та "host2.example.com", а також записи верхнього рівня "example.com", вказують на загальнодоступну IP-адресу шлюзу.

Я хотів би, щоб хости, розташовані у внутрішній мережі, вирішили "host1.example.com", "host2.example.com" та "example.com" на внутрішні IP-адреси замість шлюзу. Інші хости, такі як "otherhost.example.com", все ж повинні вирішуватися зовнішнім постачальником DNS.

Мені це вдалося зробити для записів host1 та host2, визначивши дві зони одного входу в BIND для "host1.example.com" та "host2.example.com". Однак якщо я додаю зону для "example.com", усі запити для цього домену вирішуються моїм локальним сервером DNS, і, наприклад, запит "otherhost.example.com" призводить до помилки.

Чи можливо налаштувати BIND на зміну лише деяким записам домену, а решту рекурентно вирішити?


Аналогічне запитання: serverfault.com/questions/8694/…
MikeyB

1
"Чи можна налаштувати BIND, щоб замінити лише деякі записи домену?" Ні, не з BIND. Використовуйте субдомен.
bortzmeyer

1
Зв'язок, здається, робить саме те, про що я просив, тому я встановлюю відповідь Альнітака як прийняту відповідь. Зрештою, я збираюся дотримуватися порад борцмейєра, а не перекривати введення домену. Дякую за всі відповіді!
Ремі Бланк

1
Bind тепер може це робити в зоні політики відповідей. Дивіться мою відповідь нижче. Інші рішення, такі як Unbound, не можуть замінити CNAME. З політиками в Bind вам не доведеться робити субдомени; ви можете просто замінити окремі записи за бажанням.
Флорін Андрій

Відповіді:


18

Найкращий метод - через зону політики відповідей у ​​Bind 9.8.1 або новішої версії. Це дозволяє переосмислювати поодинокі записи в довільних зонах (і для цього немає необхідності створювати цілий піддомен; лише один запис, який ви хочете змінити), він дозволяє переосмислювати CNAME та ін. Інші рішення, такі як Unbound, не можуть замінити CNAME .

https://www.redpill-linpro.com/sysadvent/2015/12/08/dns-rpz.html


EDIT: Давайте тоді зробимо це правильно. Я задокументую те, що я зробив на основі підручника, зв'язаного вище.

Моя ОС є Raspbian 4.4 для Raspberry Pi, але методика повинна працювати без змін на Debian і Ubuntu, або з мінімальними змінами на інших платформах.

Перейдіть туди, де зберігаються ваші файли конфігурації Bind у вашій системі - ось це /etc/bind. Створіть там файл, викликаний db.rpzіз таким вмістом:

$TTL 60
@            IN    SOA  localhost. root.localhost.  (
                          2015112501   ; serial
                          1h           ; refresh
                          30m          ; retry
                          1w           ; expiry
                          30m)         ; minimum
                   IN     NS    localhost.

localhost       A   127.0.0.1

www.some-website.com    A        127.0.0.1

www.other-website.com   CNAME    fake-hostname.com.

Що це робить?

  • він переосмислює IP-адресу www.some-website.comна фальшиву адресу 127.0.0.1, фактично надсилаючи весь трафік для цього сайту на адресу петлі
  • він передає трафік www.other-website.comна інший сайт, який називаєтьсяfake-hostname.com

Все, що може входити у файл Bind zone, ви можете використовувати тут.

Щоб активувати ці зміни, виконайте ще кілька кроків:

Відредагуйте named.conf.localта додайте цей розділ:

zone "rpz" {
  type master;
  file "/etc/bind/db.rpz";
};

Підручник, зв'язаний вище, пропонує вам додати більше матеріалів, zone "rpz" { }але це не потрібно в простих налаштуваннях - те, що я показав тут, є мінімумом, щоб він працював на вашому локальному дозволі.

Редагувати named.conf.optionsта десь у options { }розділі додати response-policyопцію:

options {
  // bunch
  // of
  // stuff
  // please
  // ignore

  response-policy { zone "rpz"; };
}

Тепер перезапустіть Bind:

service bind9 restart

Це воно. Сервер імен повинен почати замінювати ці записи вже зараз.

Якщо вам потрібно внести зміни, просто відредагуйте db.rpz, а потім перезапустіть Прив’язати ще раз.

Бонус: якщо ви хочете занести запити DNS до системного журналу, тож ви можете слідкувати за процедурами, редагувати named.conf.localта переконайтесь, що є loggingрозділ, який включає ці заяви:

logging {
    // stuff
    // already
    // there

    channel my_syslog {
        syslog daemon;
        severity info;
    };
    category queries { my_syslog; };
};

Перезавантажте Bind ще раз, і все.

Перевірте його на машині під керуванням Bind:

dig @127.0.0.1 www.other-website.com. any

Якщо ви запускаєте копати на іншій машині, просто використовуйте @ the-ip-address-of-Bind-server замість @ 127.0.0.1

Я використовував цю методику з великим успіхом, щоб замінити CNAME для веб-сайту, над яким я працював, надсилаючи його на новий балансир завантаження AWS, який я тільки тестував. Raspberry Pi був використаний для запуску Bind, а RPi також був налаштований на функцію маршрутизатора WiFi - таким чином, підключивши пристрої до SSID, що працює на RPi, я отримав би перевірки DNS, необхідні для тестування.


1
Зверніть увагу, що BIND RPZ фактично не може (ще) переосмислювати окремі записи на основі QTYPE - це буде заміняти всі записи для конкретного імені власника. Це означає, що якщо ви хочете замінити запис A для домену, але не, наприклад, запис MX, ви не можете. Вам також потрібно поставити запис MX в зону RPZ і тримати його в синхронізації з реальною зоною.
Альнітак

2
Дякуємо, що зламали це, як і ви. Дуже корисний.
sruffell

Чи є якісь застереження? Я намагаюся зробити це на pfsense, але не можу "підробити" жодних результатів, він все ще повідомляє реальну адресу. Я вважаю, що я дотримувався вказівок до листа.
Ленн

@Lenne Це просто повинно працювати. Я відредагував публікацію та додав пропозицію перевірити зміни.
Флорін Андрій

@Lenne пакет pfSense BIND вбудований в GUI вже близько року, тому спілкування з конфігураціями не повинно бути необхідним. ОП: можливо, варто згадати деякі інші речі, які ви можете зробити з RPZ, такі як відповідь NXDOMAIN або просто ухилення відповіді.
miken32

21

Незв'язаний рекурсивний сервер DNS має можливість перевизначити окремі записи ресурсів.

Подивіться на налаштування local-zoneта local-dataконфігурацію в посібнику , наприклад:

local-zone: "example.com." transparent
local-data: "foo.example.com. IN A 192.168.1.1"

transparentУстановка на local-zoneкаже , що робити нормальний рекурсивний перегляд будь-яких імен не поставляється з local-data.


1
Здається, саме те, що я хочу зробити, дякую. Я прочитаю сьогодні на Unbound.
Ремі Бланк

З іншого боку, мудрість її досить сумнівна. Наявність внутрішнього домену.example.com було б зрозуміліше.
борцмейєр

@Bortzmeyer - ти можеш мати рацію, але я не думаю, що Вутер поставив би це просто для розваги ;-)
Alnitak

3
@bortzmeyer, іноді вибору немає. Приклад: SBS 2008 повинен мати єдиний IP-адресу локальної мережі, але до нього потрібно звертатися зовні, використовуючи зовнішній IP, який маршрутизатор пересилає. Microsoft не дозволяє дві мережеві карти на SBS, а також дві IP-адреси, налаштовані на одній карті. Якщо локальні сервери вирішують ім'я DNS до зовнішнього IP, то маршрутизатору потрібно робити як DNAT, так і SNAT для ip локальної мережі, і тоді журнали в SBS покажуть, що весь доступ повинен бути з IP-адреси маршрутизатора, і це просто неправильно. Я встановлю unboundна власний роутер, я думаю, що рішення набагато краще.
Cosmin Prund

Це не дає відповіді на запитання, оскільки питання є специфічним для BIND.
bzeaman

4

Ви можете заглянути в "dnsmasq", який дозволяє вам робити досить розумні речі з чітким дозволом.


Дякую, хороша порада. Шкода, що dnsmasq не робить рекурсивну роздільну здатність, тому мені все одно доведеться запускати BIND на іншому порту для цього (сервери DNS мого провайдера є відкладеними).
Ремі Бланк

4

Те, що ви шукаєте, - це розділений DNS, який визначається Webopedia як:

У розділеній інфраструктурі DNS ви створюєте дві зони для одного домену, одну для використання внутрішньою мережею, а іншу, що використовується зовнішньою мережею. Спліт DNS спрямовує внутрішні хости на внутрішній сервер доменних імен для вирішення імен, а зовнішні хости спрямовуються на зовнішній сервер доменних імен для вирішення імен.

По суті, вам потрібно буде зробити копію файлу зовнішньої зони та підключити його на внутрішньому сервері DNS, а потім змінити або додати записи, необхідні спеціально для вашої внутрішньої мережі. Це досить поширена установка, хоча може тривати "зовнішні" записи синхронізовані між двома DNS-серверами. Якщо ви створюєте або змінюєте запис на загальнодоступному сервері, його також потрібно буде створити або змінити на приватному сервері.

Це можна реалізувати незалежно від того, якою реалізацією DNS-сервера ви користуєтесь. У більшості налаштувань у вас буде один DNS-сервер, який обслуговує зовнішню мережу, і інший, який обслуговує внутрішню мережу. З BIND, як, можливо, з іншими реалізаціями, ви можете мати обидві версії зони на одному сервері за допомогою оператора "дозволити запит" у розділі зони файлу named.conf.

Іншою можливістю BIND (і я ніколи цього не пробував) було б встановити ваш домен example.com на внутрішньому DNS-сервері, використовуючи лише записи, які ви використовуєте всередині країни. Потім встановіть висловлювання "вперед" з аргументом "перший" (спільно з "форвардерами"). Теоретично, це вимагатиме запитання зовнішнього сервера DNS (як встановлено у "форвардерах" для відповіді, який би не мав ваших внутрішніх записів і не повертав відповідь про помилку. Тоді внутрішній сервер шукав би собі відповідь. Ні. впевнений, якби це спрацювало, але це думка.


Синхронізація двох зонних файлів буде складною, оскільки зовнішній оновлюється через динамічний клієнт DNS. Я все ж прочитаю на заяві вперед. Дякую за пораду.
Ремі Бланк

Ні, пересилання BIND не буде працювати, це буде лише для невідомих доменів, але внутрішній сервер імен буде знати про example.com, це буде авторитетним для нього.
борцмейєр

1
Якщо я читаю документацію правильно, висловлювання "вперед спочатку" в розділі зони повинно вказати BIND вийти і шукати відповідь у експедитора навіть для авторитетного локального домену, а потім використовувати локальну інформацію, лише якщо вона може " не отримаєте відповідь від експедитора.
Джастін Скотт

Якщо ви поставите глобальний "вперед спочатку", "він надішле запити експедитору, і якщо не буде отриманий відповідь, спробує відповісти на запит" (від документа), але якщо він отримає відповідь, він не намагатиметься вирішити себе. Було б чудово, якби ви могли змусити вирішити, якщо відповідь не є авторитетною або навіть якщо це NXDOMAIN, але прив'язка не буде намагатися, якщо вона отримає відповідь від експедитора.
Пабло Мартінес

3

У BIND я дістаюсь до цих результатів, визначаючи зону, використовуючи бажане ім'я хоста. Підхід чудовий, якщо ви хочете лише перемогти кілька хостів.

Моя декларація про зону виглядає приблизно так:

zone "override.example.com" {
        type master;
        notify no;
        file "zone-config/override.example.com";
};

Моє визначення зони виглядає так:

$TTL 4H
@       IN      SOA     ns.override.example.com.    root.override.example.com. (
                        2009072215      ; Serial
                        3600            ; Refresh
                        600             ; Retry
                        604800          ; Expire
                        3600    )       ; Minimum
;
                NS      ns
        IN      NS      ns.override.example.com.
        IN      A       192.168.1.100
ns      IN      A       192.168.1.100

Отже, якщо я запитую example.com на внутрішню мережу DNS та ISP DNS, я отримую однаковий IP-адрес, але якщо я запитую override.example.com, я отримую різні результати, якщо доступ до інтранет-DNS (первинний) є доступним.


2

Ви вже на правильному шляху.

На внутрішніх серверах DNS вам потрібно буде визначити зону для кожного хоста винятків безпосередньо під "example.com". Щоб мінімізувати ці винятки, прийнято називати всі внутрішні машини "hosta.internal.example.com", DNS-сервер надсилає більшість запитів на зовнішні DNS-сервери, але є авторитетним для зони "Internal.example.com". (Після того, як ви пройдете невеликі операції, зазвичай є пара DNS-серверів, до яких спрямовані клієнти, і окремий авторитетний DNS, на який ці сервери спрямовані для "Internal.example.com".)

Зазвичай винятки, які ви описуєте, створюються лише тоді, коли хост повинен бути доступний як зовні, так і всередині. Вже тоді ви можете використовувати "host1.example.com" ззовні та "host1.internal.example.com" зсередини. Внутрішні хости налаштовуються на пошук імен у "Internal.example.com". Бувають ситуації, коли те, що ви вже робите, є доречним, наприклад, якщо сертифікат для сервера ідентифікує сервер як "host1.example.com", і в цьому випадку ви хочете, щоб це було ім'я, до якого підключаються клієнти.


Так, для хостів "host1.example.com" це вже добре працює. Хитра частина - таким же чином обробляти "example.com" верхнього рівня ...
Ремі Бланк

2

Використовувати dnsmasq - це дуже просто. http://www.thekelleys.org.uk/dnsmasq/doc.html Виступає як dns-сервер, але отримує відповіді від локального dns-сервера. Приємна річ, що ви можете переосмислювати записи одного домену, не псуючи з файлами зони


2

Власне кажучи, існує ще один, навіть якщо дещо інший спосіб зробити це. У мене така ж ситуація, у мене є домен, який використовується зовні і всередині, і у мене є зовнішні статичні та динамічні хости. Єдині насправді болючі - це зовнішні динамічні. Рішення, можливо, не найелегантніше, але реалізоване з невеликим сценарієм. Здебільшого я роблю свій власний динамічний сценарій DNS з API свого динамічного постачальника DNS, я запускаю цей сценарій за кроном, кожні 5 хвилин:

1) отримати мій зовнішній IP. це змінилося? ні, вихід.

2) змінили IP-адресу, API виклику постачальника dyndns, з новою IP-адресою,

3) sed db.mydomain.com із зовнішнім IP-адресою

4) перезапуск прив’язки.

Працює дуже надійно для моєї домашньої мережі


Той самий процес, який я робив. будь ласка, знайдіть деталі на нашому вікі- сервері Stealth Name . Але не в змозі вирішити проблему dyn.dev.shahed.bizз World Wide! Чи можете ви допомогти нам вирішити цю проблему?
Md Shahed Hossain
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.