DNS кешът е временна база данни, която съхранява информация за предишни DNS търсения. С други думи, всеки път, когато посетите уебсайт, вашата операционна система и уеб браузър ще запазят запис на домейна и съответния IP адрес. Това елиминира необходимостта от повтарящи се заявки към отдалечени DNS сървъри и позволява на вашата операционна система или браузър бързо да разреши URL адресите на уебсайтове.

В някои ситуации обаче, като отстраняване на мрежови проблеми или след смяна на DNS резолвери, трябва да изчистите DNS кеша. Това ще изчисти кешираните DNS записи и ще извърши последващи търсения за разрешаване на домейна въз основа на новоконфигурираните DNS настройки.

Тази статия предоставя инструкции за изчистване на DNS кеша на различни операционни системи и уеб браузъри.

Изчистете/изтрийте DNS кеша в Windows

Процесът за изчистване на DNS кеша е еднакъв за всички версии на Windows. Трябва да отворите команден ред с администраторски права и да стартирате ipconfig /flushdns.

Windows 10 и Windows 8

За да изчистите DNS кеша на Windows 10 и 8, изпълнете следните стъпки:

1. Въведете cmd в лентата за търсене на Windows.

2. ipconfig /flushdns

   Windows 7

   За да изчистите DNS кеша в Windows 7, изпълнете следните стъпки:

   1. Кликнете върху бутона Старт.
   2. Въведете cmd в текстовото поле за търсене в менюто "Старт".
   3. Щракнете с десния бутон върху командния ред и изберете Изпълни като администратор. Това ще отвори прозорец на командния ред.
   4. В командния ред въведете следния ред и натиснете Enter:

      ipconfig /flushdns

      При успех системата ще върне следното съобщение:

      IP конфигурация на Windows Успешно изчисти кеша на DNS преобразувателя.

   Изчистете/изтрийте DNS кеша в Linux

   Linux няма DNS кеширане на ниво ОС, освен ако кешираща услуга като Systemd-Resolved, DNSMasq или Nscd не е инсталирана и работи. Процесът за изчистване на DNS кеша се различава в зависимост от услугата за разпространение и кеширане, която използвате.

   Systemd Разрешен

   Повечето съвременни дистрибуции на Linux, като , използват активирана от системата услуга за кеширане на DNS записи.

   За да разберете дали услугата работи, изпълнете:

   sudo systemctl е активен systemd-resolved.service

   Ако услугата работи, командата ще отпечата активна, в противен случай ще видите неактивна.

   За да изчистите Systemd Resolved DNS кеша, трябва да въведете следната команда.

   sudo systemd-resolve --flush-caches

   Ако е успешна, командата не връща никакво съобщение.

   Dnsmasq

   Dnsmasq е лек DHCP и DNS сървър за кеширане на имена.

   Ако вашата система използва DNSMasq като кеширащ сървър, за да изчистите DNS кеша, трябва да рестартирате услугата Dnsmasq:

   sudo systemctl рестартирайте dnsmasq.service

   sudo услуга dnsmasq рестартиране

   Nscd

   Nscd е кеширащ демон и е предпочитаната система за кеширане на DNS за повечето базирани на RedHat дистрибуции.

   Ако вашата система използва Nscd, ще трябва да рестартирате услугата Nscd, за да изчистите DNS кеша:

   sudo systemctl рестартирайте nscd.service

   sudo услуга nscd рестартиране

   Изчистете/изтрийте DNS кеша на MacOS

   Командата за изчистване на кеша в MacOS е малко по-различна в зависимост от версията, която използвате. Командата трябва да се изпълнява като потребител с права на системен администратор (sudo потребител).

   За да изчистите DNS кеша на MacOS, изпълнете следните стъпки:

   1. Отворете Finder.
   2. Отидете на Приложения > Помощни програми > Терминал. Това ще отвори терминален прозорец.
   3. В командния ред въведете следния ред и натиснете Enter:

      sudo killall -HUP mDNSResponder

      Въведете вашата sudo парола и натиснете Enter отново. Ако е успешно, системата не връща никакви съобщения.

   За по-ранни версии на MacOS командата за изчистване на кеша е различна.

   MacOS версии 10.11 и 10.9

   sudo dscacheutil -flushcache sudo killall -HUP mDNSResponder

   MacOS версия 10.10

   sudo discoveryutil mdnsflushcache sudo discoveryutil udnsflushcaches

   MacOS версии 10.6 и 10.5

   sudo dscacheutil -flushcache

   Изчистване/изтриване на DNS кеша на браузъра

   Повечето съвременни уеб браузъри имат вграден DNS клиент, който предотвратява дублиращи се заявки всеки път, когато посетите уебсайт.

   Google Chrome

   За да изчистите DNS кеша на Google Chrome, изпълнете следните стъпки:

   1. Отворете нов раздел и въведете в адресната лента на Chrome: chrome://net-internals/#dns.
   2. Щракнете върху бутона Изчистване на кеша на хоста.

   Ако това не работи за вас, опитайте да изчистите кеша и бисквитките.

   1. Натиснете CTRL+Shift+Del, за да отворите диалоговия прозорец Изчистване на данните за сърфирането.
   2. Изберете период от време. Изберете „За всички времена“, за да изтриете всичко.
   3. Поставете отметки в квадратчетата „Бисквитки и други данни за сайтове“ и „Кеширани изображения и файлове“.
   4. Кликнете върху бутона "Изчистване на данните".

   Този метод трябва да работи за всички базирани на Chrome браузъри, включително Chromium, Vivaldi и Opera.

   FireFox

   За да изчистите DNS кеша на Firefox, изпълнете следните стъпки:

   1. В горния десен ъгъл щракнете върху иконата на хамбургер ☰, за да отворите менюто на Firefox:
   2. Кликнете върху връзката ⚙ Опции (Предпочитания).
   3. Кликнете върху раздела „Поверителност и сигурност“ или „Поверителност“ вляво.
   4. Превъртете надолу до секцията История и щракнете върху бутона Изчистване на историята....
   5. Изберете период от време за изчистване. Изберете „Всички“, за да изтриете всичко.
   6. Изберете всички полета и щракнете върху Изчисти сега.

   Ако това не работи за вас, опитайте следващия метод и временно деактивирайте DNS кеша.

   1. Отворете нов раздел и въведете about:config в адресната лента на Firefox.
   2. Намерете network.dnsCacheExpiration, временно задайте стойността на 0 и щракнете върху OK. След това променете стойността по подразбиране и щракнете върху OK.
   3. Намерете network.dnsCacheEntries, задайте временно стойността на 0 и щракнете върху OK. След това променете стойността по подразбиране и щракнете върху OK.

   Заключение

   Научихте как да изчистите или изтриете DNS кеша на операционни системи Windows, Linux и MacOS.

   Linux и MacOS могат да използват командата dig за запитване към DNS и отстраняване на проблеми с DNS.

   Ако имате въпроси или отзиви, не се колебайте да оставите коментар.

Всяка година скоростта на интернет - както последната миля, така и основните канали - става все по-висока. Само едно нещо е постоянно - латентността вече е достигнала физически граници: скоростта на светлината в оптичното влакно е около 200 хиляди километра в секунда и съответно, по-бързо от ~150ms, отговор от сървър отвъд Атлантическия океан не може да бъде получен в обозримо бъдеще (въпреки че разбира се има изкушения, като оптично влакно с въздушно ядро ​​или радиорелейна комуникация, но това едва ли е достъпно за обикновените смъртни).

Когато се опитаме например от Русия да отворим уебсайт, намиращ се в САЩ (нейните NS сървъри вероятно са там), и домейнът не бъде намерен в DNS кеша на вашия доставчик, ще трябва да чакаме дълго дори на гигабитов интернет, може би дори цяла секунда: докато отвъд океана ще получаваме имената на NS сървърите на домейна, докато разрешаваме IP-то им, докато изпращаме и получаваме самата DNS заявка...

Преди няколко години Google пусна своите публични DNS сървъри и за да насърчи прехода към тях, те разработиха помощна програма, наречена NameBench, която изпълнява DNS тестове на вашата история на сърфиране и показва колко по-бърз е Google DNS от DNS сървъра на вашия доставчик.

Но успях да направя свой собствен DNS сървър, който работи по-бързо от Google Public DNS и в тази кратка бележка искам да споделя резултатите.

ПДНСД

pdnsd- кеширане на DNS прокси. В допълнение към баналното кеширане на DNS заявки (с възможност за стриктно задаване на минималния TTL - това може да е необходимо при много слаб интернет), той може да изпрати заявка едновременно до няколко „родителски“ DNS сървъра и да даде на клиента първия върнат отговор.

Именно включването на паралелно анкетиране ни дава основното предимство в скоростта, защото когато се намери резултат в кеша на някой от доставчиците, ние получаваме резултата много бързо и не чакаме пълно и бавно разрешаване, ако първият доставчик няма отговор в кеша.

Инсталиран в Ubuntu с помощта на банален apt-get.

Няколко точки в конфигурацията

global ( perm_cache=10240; //Максимален размер на кеша в килобайти. //По подразбиране беше 1024, всичките ми записи не пасват. cache_dir="/var/cache/pdnsd"; [...] min_ttl=60m; // Минимално време за съхраняване на запис в кеша. // Дори ако TTL пристигне след по-малко от 60 минути, той ще бъде 60 минути max_ttl=1w; // Максимално време за запазване на запис в кеша neg_ttl=5m; // Време за кеширане на отрицателни отговори (т.е. ако домейнът не е намерен) [..] par_queries=3; //Брой едновременно анкетирани "родителски" DNS сървъри) сървър ( label = "main"; ip = 85.21.192.5 //Там са 4 сървъра, ако първите 3 не отговорят, тогава ще бъде изпратена заявка до 4-тия, 213.234.192.7 //Първите 2 сървъра са сървърът на вашия доставчик и някой съседен, 8.8.4.4 //Това е Google Public DNS - те кешират всичко рядко и се разрешават бързо, 8.8.8.8 ; [.. ] )

По принцип кеширането може да се направи по-малко агресивно (min_ttl=1m например), но в течение на една година работа не са възникнали особени проблеми. В случай на проблеми можете по избор да изтриете един запис от кеша:
sudo pdnsd-ctl запис 3.14.by изтриване или всички наведнъж:
sudo pdnsd-ctl празен кеш

Резултати от тестове в NameBench

Виждаме, че за 50% от заявките получаваме отговор за по-малко от 10ms, за 85% Google Public DNS е по-бърз и след това резултатите естествено съвпадат с Google.

Въз основа на резултатите от теста, NameBench с радост ни съобщава:

8.8.8.8 По-бавна реплика на SYS-192.167.0.98 8.8.4.4 По-бавна реплика на SYS-192.167.0.98

По този начин интелигентно кеширане на DNS прокси с паралелни заявки ви позволява да ускорите дори 100-мегабитов интернет. А за бавни (радио) връзки с висока латентност и загуба на пакети разликата може да е като небето и земята.

Представете си какво би било, ако трябваше да помним IP-адреси на всички уебсайтове, които използваме ежедневно. Дори и да имахме невероятна памет, процесът на навигиране до уебсайт би бил абсурдно бавен и трудоемък.

Какво да кажем, ако трябва да посетим множество уебсайтове или да използваме множество приложения, които се намират на един и същ компютър или виртуален хост? Това ще бъде едно от най-лошите главоболия, които можете да си представите - да не говорим за възможността за промяна IP-адреси, свързани с уебсайта или приложението, без предварително известие.

Само мисълта за това би била достатъчна причина да спрете да използвате интернет или интранет след известно време.

Това е свят без системата за имена на домейни (известна още като DNS). За щастие, тази услуга решава всички проблеми, споменати по-горе, дори ако връзката между IP- промени в адрес и име на домейн.

Поради тази причина в тази статия ще научим как да настроим и използваме прост DNS-сървър, услуга, която ще ви позволи да превеждате имена на домейни в IP-адреси и обратно.

Резолюции на DNS имена

За малки мрежи, които не са обект на чести промени, файлът /etc/hostsможе да се използва като елементарен метод за определяне на име на домейн за разрешаване IP- адреси.

Този файл, използвайки много прост синтаксис, ви позволява да свържете име (и/или псевдоним) с IP- адрес. Това се прави по следния начин:

Например,

192.168.0.1 шлюз gateway.mydomain.com 192.168.0.2 уеб web.mydomain.com

По този начин можете да се свържете с уеб машината или по име web.mydomain.com, или според нея IP- адрес.

За големи мрежи или такива, които са обект на чести промени, използвайте файла /etc/hostsза разрешаване на имена на домейни IP-адресите няма да бъдат приемливо решение. Тук възниква необходимостта от специална услуга.

Да отидем зад кулисите на работата DNS. DNS- сървърът изисква голяма база данни под формата на дърво, което започва от корена ( «.» ) зони.

Следната фигура ще ни помогне да разберем за какво говорим:

Изображението по-горе показва кореновата зона (.) съдържа com, образованиеИ нетодомейни от първо ниво. Всеки от тези домейни се управлява (или може да се управлява) от различни организации, за да се избегне зависимостта от един голям централен. Това ви позволява да разпределите правилно заявките в йерархията.

Да видим какво ще се случи:

1. Когато клиент направи заявка за DNS- сървър за web1.sales.me.com, сървърът изпраща заявка до върха (root) DNS-сървър, който препраща заявката към сървъра за имена в зоната .com.

Това от своя страна изпраща заявка до следващото ниво сървър на имена (в зоната me.com), а след това към sales.me.com. Този процес се повтаря колкото пъти е необходимо до пълното квалифицирано име на домейн (FQDN, web1.sales.me.comв този пример) няма да бъде върнат от сървъра за имена на зоната, в която се намира.

2. В този пример сървърът за имена в sales.me.comотговарящ за адреса web1.sales.me.comи връща желаната асоциация за името на домейна - IPи друга информация (ако е конфигуриран за това).

Цялата тази информация се изпраща на източника DNS-сървър, който след това го връща обратно на клиента, който го е поискал. За да се избегне повтарянето на същите стъпки за бъдещи идентични заявки, резултатите от заявките се съхраняват на DNS- сървър. Това е важният аспект, поради който обикновено се извиква такава настройка настройка на DNS сървър за рекурсивно кеширане.

Инсталиране и конфигуриране на DNS сървър

IN Linuxнай-използван DNS- сървърът е обвързвам(съкратено от Berkeley Internet Name Daemon), който може да бъде инсталиран по следния начин:

# yum инсталирайте bind bind-utils # zypper инсталирайте bind bind-utils # aptitude инсталирайте bind9 bind9utils

След като сме инсталирали обвързвами свързаните помощни програми, направете копие на конфигурационния файл, преди да направите промени:

# cp /etc/named.conf /etc/named.conf.orig # cp /etc/bind/named.conf /etc/bind/named.conf.orig

Тогава да отворим named.confи преминете към блока с параметри, където трябва да посочим следните настройки за сървъра за рекурсивно кеширане с IP 192.168.0.18/24, които могат да бъдат достъпни само от хостове в същата мрежа (като мярка за сигурност).

Опциите за зона за препращане се използват, за да се посочи кои сървъри за имена да бъдат заявени първи (в следващия пример използваме сървъри за имена на Google) за хостове извън нашия домейн:

Опции ( ... порт за слушане 53 ( 127.0.0.1; 192.168.0.18); разрешителна заявка ( локален хост; 192.168.0.0/24; ); рекурсия да; препращащи устройства ( 8.8.8.8; 8.8.4.4; ); . .. )

Извън блока с опции ще определим нашата зона sales.me.com(в Ubuntu това обикновено се прави в отделен файл, наречен named.conf.local), който показва домейна с даденото IP-адресна и обратна зона за съвпадение IP- адреси към съответния район.

Действителната конфигурация на всяка зона обаче ще се извърши в отделни файлове, както е посочено във файловата директива ("master" означава, че ще използваме само един DNS сървър).

Добавете следните редове към файла named.conf:

Зона "sales.me.com." IN (напишете master; файл "/var/named/sales.me.com.zone"; ); зона "0.168.192.in-addr.arpa" IN (тип master; файл "/var/named/0.162.198.in-addr.arpa.zone";);

забележи, че inaddr.arpa(за IPv4 адреси) и ip6.arpa(за IPv6) са конвенции за конфигурации на обратна зона.

След като запазите горните промени в named.confможем да проверим за грешки като това:

# named-checkconf /etc/named.conf

Ако бъдат открити грешки, горната команда извежда информационно съобщение с причината и реда, където са открити. В противен случай няма да върне нищо.

Настройка на DNS зони

Във файлове /var/named/sales.me.com.zoneИ /var/named/0.168.192.in-addr.arpa.zoneще конфигурираме препращащата (домейн → IP адрес) и обратната (IP адрес → домейн) зони.

Нека първо да разгледаме директната конфигурация:

1. В горната част на файла ще намерите ред, започващ с TTL(съкратено от Time To Live), което указва колко дълго трябва да живее кеширан отговор, преди да бъде заменен от резултатите от нова заявка.

В реда по-долу ще направим връзка към нашия домейн и ще посочим имейл адреса, от който да се изпращат известия (моля, имайте предвид, че root.sales.me.comозначава ).

2. Записване SOA(Начало на пълномощия) показва, че тази система е авторитетният сървър за имена за машини в домейна sales.me.com.

Ако имате два сървъра за имена (един главен и един подчинен), следните настройки са необходими за всеки домейн (въпреки че това не е нашият случай, тъй като не се изисква в изпита, те са представени тук за справка):

Сериенизползва се за отделяне на една версия на файла за дефиниране на зона от предишната (където параметрите може да са променени). Ако кешираният отговор сочи към изход с различен Сериен, заявката се изпълнява отново, вместо да се връща на клиента.

В настройка с подчинен (вторичен) сървър за имена Опресняванеуказва времето, през което вторичният сървър трябва да проверява за нов сериен номер от първичния сървър.

Освен това, Опитайте отновоказва на сървъра колко често вторичният трябва да се опитва да се свърже с основния, ако не се получи отговор от първичния, докато Изтичапоказва, когато дефиниция на зона във вторичен режим вече не е валидна, след като вече не е възможно да се получи отговор от основния сървър, и отрицателен TTLе времето, през което несъществуващ домейн не е кеширан ( NX домейн).

3. Н.С.- записът показва, че е авторитетен DNS-сървър за нашия домейн (който е обозначен със знака @ в началото на реда).

4. Записване А(за IPv4 адреси) или АААА(за IPv6 адреси) разрешава имената към IP- адреси.

В примера по-долу:

Dns: 192.168.0.18 (самият DNS сървър) web1: 192.168.0.29 (уеб сървър в зоната sales.me.com) mail1: 192.168.0.28 (мейл сървър в зоната sales.me.com) mail2: 192.168 .0.30 (друг пощенски сървър)

5. Записване MXуказва имената на оторизираните агенти за прехвърляне на поща (MTA) за този домейн. Името на хоста трябва да бъде предшествано от число, указващо приоритета, който трябва да има текущият имейл сървър, ако има два или повече MTAза домейн (колкото по-ниска е стойността, толкова по-висок е приоритетът) в следния пример, поща1е основен, докато поща2е второстепенно MTA).

6. Записване CNAMEзадава псевдоним (www.web1) за хоста (web1).

ВАЖНО: важно е наличието на точка (.) в края на имената.

$TTL 604800 @ В SOA sales.me.com. root.sales.me.com. (2016051101; Сериен номер 10800; Обновяване 3600; Повторен опит 604800; Изтичане 604800) ; Отрицателен TTL; @ В NS dns.sales.me.com. dns В А 192.168.0.18 web1 В А 192.168.0.29 mail1 В А 192.168.0.28 mail2 В А 192.168.0.30 @ В MX 10 mail1.sales.me.com. @ IN MX 20 mail2.sales.me.com. www.web1 В CNAME web1

Нека да разгледаме конфигурацията на обратната зона (/var/named/0.168.192.in-addr.arpa.zone). Записвайте SOAсъщото като в предишния файл, докато последните три реда с записа PTR(показател) показват последния октет в адреса на хоста IPv4 поща1, уеб1И поща2(съответно 192.168.0.28, 192.168.0.29 и 192.168.0.30).

$TTL 604800 @ В SOA sales.me.com. root.sales.me.com. (2016051101; Сериен номер 10800; Обновяване 3600; Повторен опит 604800; Изтичане 604800) ; Минимален TTL @ IN NS dns.sales.me.com. 28 В PTR mail1.sales.me.com. 29 В PTR web1.sales.me.com. 30 В PTR mail2.sales.me.com.

Можете да проверите зоновите файлове за грешки:

# named-checkzone sales.me.com /var/named/sales.me.com.zone # named-checkzone 0.168.192.in-addr.arpa /var/named/0.168.192.in-addr.arpa.zone

Следната екранна снимка показва какъв е очакваният резултат:

В противен случай ще получите съобщение за грешка и съвет как да я разрешите:

След като сте проверили основния конфигурационен файл и файловете на зоната, рестартирайте посочената услуга, за да приложите промените.

IN CentOSИ openSUSEнаправи:

# systemctl рестартиране на име

И не забравяйте да го включите:

# systemctl enable named

IN Ubuntu:

$ sudo service bind9 рестартиране

И накрая, ще трябва да редактирате конфигурацията на основните мрежови интерфейси:

В /etc/sysconfig/network-scripts/ifcfg-enp0s3 за CentOS и openSUSE ---- DNS1=192.168.0.18 ---- В /etc/network/interfaces за Ubuntu ---- dns-nameservers 192.168.0.18

Сега рестартирайте мрежовата услуга, за да приложите промените.

Тестване на DNS сървър

На този етап сме готови да поискаме нашите DNS-сървър за локални и външни имена и адреси. Следните команди ще се върнат IP-адрес, свързан с хоста уеб1:

# хост web1.sales.me.com # хост web1 # хост www.web1

Как можем да разберем за кого се обработват имейли sales.me.com? Лесно е да разберете - просто поискайте записи MXза домейн:

# хост -t mx sales.me.com

По същия начин, нека направим обратната заявка. Това ще ни помогне да разберем името IP-адреси:

# хост 192.168.0.28 # хост 192.168.0.29

Можете да опитате същите операции за външни хостове:

За да гарантираме, че заявките действително преминават през нашия DNS-сървър, нека активираме регистриране:

# rndcquerylog

И проверете файла /var/log/messages(на CentOS и openSUSE):

# хост -t mx linux.com # хост 8.8.8.8

За да деактивирате регистриране DNS, въведете отново:

# rndcquerylog

IN UbuntuЗа да активирате регистриране, ще трябва да добавите следния независим блок (на същото ниво като блока с опции) към /etc/bind/named.conf:

Регистриране (канал query_log ( файл "/var/log/bind9/query.log"; динамична сериозност; категория за печат да; сериозност за печат да; време за печат да;); заявки за категория (query_log;););

Имайте предвид, че лог файлът трябва да съществува и да може да се записва по име.

Резултати

В тази статия обяснихме как да настроите основно рекурсивно кеширане DNS-сървър и как да конфигурирате зони за домейн.

За да осигурите правилната работа на вашия DNS-сървър, не забравяйте да активирате тази услуга във вашата защитна стена (TCP порт 53), както е описано в („Конфигуриране на защитната стена на Iptables за активиране на отдалечен достъп до услуги“).

.

Курсове по Cisco и Linux с работа!

Побързайте да кандидатствате! Има още няколко места. Групите започват 22 юли, и следващият 19 август, 23 септември, 21 октомври, 25 ноември, 16 декември, 20 януари, 24 февруари.

Какво ще получите?

• Ще ви помогнем да станете експерт в мрежовата администрация и да получите международни сертификати Cisco CCNA Routing & Switching или Linux LPI.
• Предлагаме доказана програма и учебник от експерти от Cisco Networking Academy и Linux Professional Institute, сертифицирани инструктори и личен преподавател.
• Ще ви помогнем да намерите работа и да изградите кариера. 100% от нашите завършили работят.

Как протича обучението?

• Провеждаме вечерни онлайн лекции на нашата платформа или учим лично в офиса в Киев.
• Ще ви попитаме за удобно време за практика и ще коригираме: разбираме, че има малко време за учене.
• Ако желаете индивидуален график, ще го обсъдим и реализираме.
• Ще поставим ясни срокове за самоорганизация. Личен супервайзор ще се свърже с вас, за да отговаря на въпроси, да ви съветва и да ви мотивира да спазвате изпитните срокове.

Ние също така ще ви помогнем:

Целта на DNS е да превежда имена на домейни, които са лесни за запомняне от хората, в IP адреси, които компютрите могат да разберат, процес, наречен разделяне на имена. Какво ще ни даде инсталирането на наш собствен кеширащ DNS сървър? Това ще ускори малко отговора на сайтовете + Linux не приема много добре имената на NetBios, но понякога трябва да намерите компютри или принтери в локална мрежа, но искате да го направите по име.

Запомнянето на IP адреси не е удобно и постоянното гледане на дневника на DHCP сървъра също не е нашият метод. Именно за такива случаи ви трябва DNS в локалната мрежа. Инсталирането на самия пакет bind9 не е трудно; проблемите обикновено възникват на етапа на неговата конфигурация, т.к След лесно четими системни конфигурационни файлове, човек се сблъсква с неразбираем синтаксис, който между другото е много подобен на езика за програмиране S. сървърът ще работи в локалната мрежа, няма смисъл да го прехвърляте в chroot среда и цялата настройка отнема много малко време. С това лиричната част може да бъде завършена, нека да преминем към инсталацията и конфигурацията.

Нека инсталираме DNS сървъра Bind9:

# apt - вземете инсталиране на bind9

След завършване, изтегляне и инсталиране трябва да редактираме неговия конфигурационен файл:

#vim /etc/bind/named. конф. настроики

Намираме раздела, той се намира в самото начало на конфигурационния файл, освен него няма нищо друго там...

опции (директория "/var/cache/bind" ; // Ако има защитна стена между вас и сървърите на имена, които искате// за да говорите, може да се наложи да коригирате защитната стена, за да разрешите множество// портове за разговор. Вижте http://www.kb.cert.org/vuls/id/800113// Ако вашият интернет доставчик е предоставил един или повече IP адреси за stable// сървъри на имена, вероятно искате да ги използвате като препращачи.// Разкоментирайте следния блок и вмъкнете заместващите адреси// контейнерът за всички 0. // пренасочващи устройства ( // 0.0.0.0; // ); auth - nxdomain no ; # съответства на RFC1035 слушане - на - v6 (всяко; ); );

Разделът за препращачи е отговорен за това къде ще бъде изпратена DNS заявката за разрешаване на имена, ако не е в собствената му база данни. Напоследък изобщо не съм доволен, работата на тези сървъри с доставчика е защо можете да свържете трети страни, например тези на Google, много е лесно да запомните IP 8.8.8.8, ще използвам неговия пример за конфигурирайте го, но никой не ви притеснява да използвате тези, които ви харесват най-много.

Ние редактираме раздела, първо трябва да премахнете коментарите от него и да добавите DNS на трета страна, ако има нужда да добавите няколко сървъра, например в случай, че сървърът на Google не може да издържи вашите заявки и се повреди :), тогава IP на други сървъри може да бъде написан в колона, тогава можете да постигнете по-голяма толерантност към грешки.

препращачи (8.8.8.8; 193.58.251.251; //Руска DNS услуга -SkyDNS};

В този раздел е по-добре да въведете IP на сървъра, който сте посочили във файла /etc/resolv.confили го въведете в секцията сървър за именатова IP. Запазете промените и излезте. Рестартирайте сървъра и проверете. Пишем в командния ред nslookup mail.ru
Трябва да изведе:

Неавторитетен отговор: Име: поща. ru Адреси: 94.100.191.202

Това предполага, че нашият сървър не е основният в обслужването на тази зона (mail.ru), но добавя заявки към кеша!
Сега трябва да създадем DNS зона за нашата мрежа, така че машините да могат да намират различни мрежови услуги - може да има например мрежови принтери, те могат да бъдат независими или споделени на други работни станции.
Нашата зона може да се нарече orgname – т.е. Име на организацията.
Първо, създаваме зона, за това ще редактираме named.conf.local

#vim /etc/bind/named. конф. местен

и добавете следното към него:

зона "orgname" ( тип master ; файл "/etc/bind/db.orgname" ;);

Запази и излез
Сега трябва да създадем конфигурационен файл на зона

# vim / etc / bind / db. orgname

и поставете следното в него:
(Моля, обърнете специално внимание на синтаксиса на конфигурационния файл, дори точките имат значение)

@IN SOA име на организация. корен. orgname. (20101015 4h; време за актуализиране - 4 часа 1h; повтаряне на всеки час 1w; колко дълго да се съхранява информацията - 1 седмица 1d); TTL (време за живот) на запис е 1 ден @ IN NS orgname. ; име на сървър за имена @ IN A 192.168.10.1 ; A - запис - IP адресът на нашия DNS сървър, който обслужва тази зона, @ означава, че това е основната зона. * IN CNAME @ принтер IN A 192.168.10.25; Можете да създадете DNS запис за мрежов принтер, намиращ се на 192.168.10.25

Сега, когато добавяте ново мрежово устройство, трябва да направите 2 неща:
1) Резервирайте IP адрес на DHCP сървър, можете да прочетете как да направите това в статията - Настройка на DHCP сървър
2) Създайте DNS зона за този IP, въведете име на устройство В XXX.XXX.XXX.XXX. Където: devicename е мрежовото име на устройството; XXX.XXX.XXX.XXX е неговият IP адрес, който е запазен на DHCP сървъра.

сега трябва да редактираме файла resolv.conf

# vim / etc / resolv. конф

и въведете там:

сървър за имена 127.0.0.1

всичко, което е имало може да се коментира с #
сървърът се рестартира

# рестартиране

Това беше направено, така че сървърът да търси всичко в собствената си база данни и едва тогава BIND ще пренасочва заявките към сървъра 8.8.8.8 IP, чийто IP е включен в директивата спедитори.
Сега можете да проверите функционалността:
Ако тестването се извършва под Windows:

ping име на устройство. orgname

Ако тестваме от Linux:

ping име на устройство. orgname - c 4

Пинговете трябва да отиват към IP адреса, който сте посочили, вместо XXX.XXX.XXX.XXX

Можете също да проверите скоростта на обработка на заявките с командата копай

# копай @127.0.0.1 tut.by ;<<>> DiG 9.9.5-9+deb8u6-Debian<<>> @127.0.0.1 tut.by ; (намерен е 1 сървър) ;; глобални опции: +cmd ;; Получих отговор: ;; ->>ЗАГЛАВКА<<- opcode: QUERY, status: NOERROR, id: 63893 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 13, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;tut.by. IN A ;; ANSWER SECTION: tut.by. 103 IN A 178.172.160.5 tut.by. 103 IN A 178.172.160.4 tut.by. 103 IN A 178.172.160.2 tut.by. 103 IN A 178.172.160.3 ;; AUTHORITY SECTION: . 6029 IN NS i.root-servers.net. . 6029 IN NS b.root-servers.net. . 6029 IN NS m.root-servers.net. . 6029 IN NS k.root-servers.net. . 6029 IN NS e.root-servers.net. . 6029 IN NS d.root-servers.net. . 6029 IN NS j.root-servers.net. . 6029 IN NS g.root-servers.net. . 6029 IN NS l.root-servers.net. . 6029 IN NS f.root-servers.net. . 6029 IN NS h.root-servers.net. . 6029 IN NS a.root-servers.net. . 6029 IN NS c.root-servers.net. ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Tue Mar 22 16:46:24 MSK 2016 ;; MSG SIZE rcvd: 310

DNS (Domain Name System) е важен и доста труден за конфигуриране компонент, необходим за работата на уебсайтове и сървъри. Много потребители използват DNS сървъри, предоставени от техния хостинг доставчик, но притежаването на собствени DNS сървъри има някои предимства.

В този урок ще научите как да инсталирате Bind9 и да го конфигурирате като кеширащ или препращащ DNS сървър на Ubuntu 14.04 сървър.

Изисквания

• Разбиране на основните типове DNS сървъри. Можете да научите повече подробности на.
• Две машини, поне една от които работи с Ubuntu 14.04. Първата машина ще бъде конфигурирана като клиент (IP адрес 192.0.2.100), а втората като DNS сървър (192.0.2.1).

Ще научите как да конфигурирате клиентска машина да изпраща заявки през DNS сървър.

Кеширане на DNS сървър

Сървърите от този тип също се наричат ​​резолвери, защото обработват рекурсивни заявки и обикновено могат да търсят DNS данни от други сървъри.

Когато кеширащ DNS сървър наблюдава отговора на клиентска заявка, той връща отговора на клиента и също го съхранява в кеша за периода от време, разрешен от TTL стойността на съответните DNS записи. След това кешът може да се използва като източник на отговори на последващи заявки, за да се ускори общото време за обработка на заявките.

Почти всички DNS сървъри във вашата мрежова конфигурация ще бъдат кеширащи сървъри. Кеширащият DNS сървър е добър избор за много ситуации. Ако не искате да разчитате на DNS сървърите на вашия хостинг доставчик или други публични DNS сървъри, настройте свой собствен кеширащ DNS сървър. Колкото по-малко е разстоянието от DNS сървъра до клиентските машини, толкова по-кратко е времето, необходимо за обслужване на DNS заявки.

Пренасочващ DNS сървър

От гледна точка на клиента препращащият DNS сървър ще изглежда почти идентичен с кеширащия сървър, но механизмите и натоварването са напълно различни.

Пренасочващият DNS сървър има същите предимства като кеширащия сървър. Въпреки това, той всъщност не изпълнява никакви рекурсивни заявки. Вместо това препраща всички заявки към външен сървър за резолюция и след това кешира резултатите за следващи заявки.

Това позволява на сървъра за пренасочване да обслужва заявки от своя кеш, без да се налага да обработва рекурсивни заявки. По този начин този сървър обработва само единични заявки (пренасочени клиентски заявки), а не цялата процедура на рекурсия. Това може да бъде предимство в среди с ограничена външна честотна лента, където кеширащите сървъри трябва да се променят често и в ситуации, в които локалните заявки трябва да се насочват към един сървър, а външните заявки към друг.

1: Инсталирайте Bind на DNS сървъра

Пакетът Bind може да бъде намерен в официалното хранилище на Ubuntu. Актуализирайте индекса на вашия пакет и инсталирайте Bind с помощта на apt мениджъра. Също така трябва да инсталирате няколко зависимости.

sudo apt-get актуализация
sudo apt-get инсталирате bind9 bind9utils bind9-doc

След това можете да започнете да настройвате сървъра. Конфигурацията на кеширащия сървър може да се използва като шаблон за конфигуриране на препращащия сървър, така че първо трябва да конфигурирате кеширащия DNS сървър.

2: Настройка на кеширащ DNS сървър

Първо трябва да конфигурирате Bind като кеширащ DNS сървър. Тази конфигурация ще принуди сървъра рекурсивно да търси отговори на клиентски заявки на други DNS сървъри. Той последователно ще запитва всички съответстващи DNS сървъри, докато намери отговор.

Конфигурационните файлове на Bind се съхраняват в директорията /etc/bind.

Повечето файлове не трябва да се редактират. Основният конфигурационен файл се нарича named.conf (named и bind са две имена за едно и също приложение). Този файл препраща към файловете named.conf.options, named.conf.local и named.conf.default-zones.

За да конфигурирате кеширащ DNS сървър, трябва само да редактирате named.conf.options.

sudo nano named.conf.options

Този файл изглежда така (коментарите са пропуснати за простота):

настроики (
директория "/var/cache/bind";
dnssec-валидиране автоматично;

слушане-на-v6 (всеки;);
};

За да настроите сървър за кеширане, трябва да създадете списък за контрол на достъпа или ACL.

Трябва да защитите DNS сървъра, който обработва рекурсивни заявки от нападатели. Атаките с усилване на DNS са особено опасни, защото могат да въвлекат сървъра в разпределени атаки за отказ на услуга.

Атаките с усилване на DNS са един от начините за сваляне на сървъри и уебсайтове. За да направят това, нападателите се опитват да намерят публични DNS сървъри, които обработват рекурсивни заявки. Те подправят IP адреса на жертвата и изпращат заявка, която ще върне много голям отговор на DNS сървъра. В този случай DNS сървърът връща твърде много данни на сървъра на жертвата в отговор на малка заявка, увеличавайки наличната честотна лента на нападателя.

Хостингът на публичен рекурсивен DNS сървър изисква внимателно конфигуриране и администриране. За да предотвратите хакване на вашия сървър, конфигурирайте списък с IP адреси или мрежови диапазони, на които сървърът може да се довери.

Преди блока с опции добавете acl блок. Създайте етикет за ACL групата (в този урок групата се нарича goodclients).

acl goodclients (
};
настроики (
. . .

В този блок избройте IP адресите или мрежите, които ще имат достъп до този DNS сървър. Тъй като сървърът и клиентът работят в подмрежата /24, можете да ограничите достъпа до тази подмрежа. Също така трябва да деблокирате localhost и localnets, които се свързват автоматично.

acl goodclients (
192.0.2.0/24;
локален хост;
локални мрежи;
};
настроики (
. . .

Вече имате сигурен клиентски ACL. Можете да започнете да настройвате резолюцията на заявката в блока с опции. Добавете към него следните редове:

настроики (
директория "/var/cache/bind";
рекурсия да;

. . .

Блокът с опции изрично разрешава рекурсия и след това конфигурира опцията за разрешаване на заявка за използване на ACL. Можете също да използвате друг параметър, като например разрешаване на рекурсия, за да се обърнете към ACL групата. Когато рекурсията е активирана, разрешаването на рекурсия ще дефинира списък с клиенти, които могат да използват рекурсивни услуги.

Ако обаче разрешителната рекурсия не е зададена, Bind се връща обратно към списъка с разрешени заявки за кеширане, след това към списъка с разрешени заявки и накрая към списъците по подразбиране за локални мрежи и локални хостове. Тъй като настройваме само кеширащ сървър (той няма собствени зони и не препраща заявки), списъкът с разрешени заявки ще се прилага само за рекурсия. Това е най-често срещаният начин за дефиниране на ACL.

Запазете и затворете файла.

Това са всички настройки, които трябва да се добавят към конфигурационния файл на кеширащия DNS сървър.

Забележка: Ако искате да използвате само този тип DNS, продължете да проверявате конфигурациите, рестартирайте услугата и конфигурирайте вашия клиент.

3: Настройка на препращащ DNS сървър

Ако вашата инфраструктура е по-подходяща за препращащ DNS сървър, можете да коригирате малко настройката.

В момента файлът named.conf.options изглежда така:

acl goodclients (
192.0.2.0/24;
локален хост;
локални мрежи;
};
настроики (
директория "/var/cache/bind";
рекурсия да;
разреши заявка (добри клиенти;);
dnssec-валидиране автоматично;
auth-nxдомейн №; # отговарят на RFC1035
слушане-на-v6 (всеки;);
};

Можете да използвате същия ACL, за да ограничите DNS сървъра до определен списък от клиенти. Това обаче изисква лека промяна на конфигурацията, така че сървърът вече да не се опитва да изпълнява рекурсивни заявки.

Не променяйте рекурсията на не. Пренасочващият сървър все още поддържа рекурсивни услуги. За да настроите сървър за пренасочване, трябва да създадете списък с кеширащи сървъри, към които ще пренасочва заявките.

Това се прави в блока options(). Първо, трябва да създадете нов блок за пренасочване в него, където ще се съхраняват IP адресите на сървърите за рекурсивни имена, към които искате да пренасочвате заявките. В този случай това ще бъдат DNS сървърите на Google (8.8.8.8 и 8.8.4.4):

. . .
настроики (
директория "/var/cache/bind";
рекурсия да;
разреши заявка (добри клиенти;);
спедитори (

8.8.8.8;

8.8.4.4;

};
. . .

Получената конфигурация изглежда така:

acl goodclients (
192.0.2.0/24;
локален хост;
локални мрежи;
};
настроики (
директория "/var/cache/bind";
рекурсия да;
разреши заявка (добри клиенти;);
спедитори (
8.8.8.8;
8.8.4.4;
};
само напред;
dnssec-валидиране автоматично;
auth-nxдомейн №; # отговарят на RFC1035
слушане-на-v6 (всеки;);
};

Последната промяна засяга параметъра dnssec. При текущата конфигурация и в зависимост от настройките на DNS сървърите, към които се пренасочват заявките, в регистрационните файлове може да се появят следните грешки:

25 юни 15:03:29 кеш с име: грешка (преследване на DS сървъри) разрешаване на "in-addr.arpa/DS/IN": 8.8.8.8#53
25 юни 15:03:29 кеш с име: грешка (няма валиден DS) разрешаване на "111.111.111.111.in-addr.arpa/PTR/IN": 8.8.4.4#53

За да ги избегнете, трябва да промените параметъра dnssec-validation на yes и изрично да активирате dnssec.

. . .
само напред;
dnssec-разрешаване да;
dnssec-валидиране да;
auth-nxдомейн №; # отговарят на RFC1035
. . .

Запазете и затворете файла. Настройката на пренасочващия DNS сървър е завършена.

4: Проверете настройките и рестартирайте Bind

Сега трябва да се уверите, че настройките работят според очакванията.

За да проверите синтаксиса на конфигурационните файлове, въведете:

sudo named-checkconf

Ако няма грешки във файловете, командният ред няма да покаже никакъв резултат.

Ако получите съобщение за грешка, коригирайте го и тествайте отново.

След това можете да рестартирате демона Bind, за да актуализирате настройките.

sudo service bind9 рестартиране

След това трябва да проверите регистрационните файлове на сървъра. Изпълнете командата на сървъра:

sudo tail -f /var/log/syslog

Сега отворете нов терминал и започнете да настройвате клиентската машина.

5: Настройка на клиента

Влезте в клиентската машина. Проверете дали клиентът е посочен в ACL групата на конфигурирания DNS сървър. В противен случай DNS сървърът ще откаже да обслужва заявки от този клиент.

Редактирайте файла /etc/resolv.conf, за да насочите сървъра към сървър за имена.

Промените, направени тук, ще се запазят само до рестартиране, което е чудесно за тестване. Ако сте доволни от резултатите от тестовите настройки, можете да направите тези настройки постоянни.

Отворете файла със sudo в текстов редактор:

sudo nano /etc/resolv.conf

Файлът трябва да изброява DNS сървърите, които ще се използват за разрешаване на заявки. За да направите това, използвайте директивата за сървър на имена. Коментирайте всички текущи записи и добавете линия за сървър на имена, сочеща към вашия DNS сървър:

сървър за имена 192.0.2.1
# сървър за имена 8.8.4.4
# сървър за имена 8.8.8.8
# сървър за имена 209.244.0.3

Запазете и затворете файла.

Вече можете да изпратите тестова заявка, за да се уверите, че се разрешава правилно.

Можете да използвате ping за това:

ping -c 1 google.com
PING google.com (173.194.33.1) 56(84) байта данни.
64 байта от sea09s01-in-f1.1e100.net (173.194.33.1): icmp_seq=1 ttl=55 време=63,8 ms
--- статистика за ping на google.com ---
1 предадени пакети, 1 получени, 0% загуба на пакети, време 0ms
rtt min/ag/max/mdev = 63,807/63,807/63,807/0,000 ms