Dns lookup failed kerio

I’ve removed advertising from most of this site and will eventually clean up the few pages where it remains.

While not terribly expensive to maintain, this does cost me something. If I don’t get enough donations to cover that expense, I will be shutting the site down in early 2020.

If you found something useful today, please consider a small donation.

Some material is very old and may be incorrect today

© May 2019 Anthony Lawrence

Let’s start with the basics: during your initial setup Kerio Control, you’ll probably either plug in your ISP’s DNS server or some public DNS like Goggle’s 8.8.8.8 and 8.8.4.4. That’s the simplest possible case and will let you resolve Internet host names so that you can type "facebook.com" into your browser rather than memorizing an IP address.

DNS also serves to resolve in the other direction: should some outside person access something inside our network, DNS will be called upon with a "reverse lookup" so that we have something more than an IP address to go by if we want to know who they are.

You may need more than that. You may want to also resolve internal machines and you may or may not already have a DNS server (perhaps a Microsoft or Apple Domain Controller) that provides that function. If you do have another DNS server, you’ll need to figure out how Control and that server can work together.

To show you that, let’s take a look at a fictional setup. It’s a real Kerio Control firewall, but it’s not actually connected to anything: it’s just running in VMWare on my Mac. The first thing I did was set the Internet interface to use Google’s servers for DNS.

By the way, when you put more than one DNS server here, you are NOT specifying preference by the order you put them in. That’s easy to forget – I forget that myself frequently. Control will pick one or the other, but not necessarily in the order you put them in. This can cause great confusion if you don’t know that.

I can now resolve Internet host names:

The "@192.168.11.93" tells dig to ask that Control firewall rather than my real firewall. If I wanted to, I could send things through this "fake" firewall by telling my browser to use it as a proxy. I might do that to test certain rules, but for what we are doing today, "dig @" is enough.

Google’s servers know nothing about my local machines, of course. If I want the firewall and therefore the people who use it to be able to resolve internal machine names, I could just add them to Control’s Hosts file.

Notice that "foobar.example.com" is at 10.14.3.2. Obviously that’s not on the same LAN as the firewall (it’s on 192.168.11.0) – perhaps it is a machine on the other side of a VPN tunnel? Whatever you need, you can put it in here and Control will look here first, before it tries the Internet name servers.

Читайте также:  Как измеряется диагональ монитора

But we may very well have a machine that does know about other local machines. It may or may not know about that "foobar.example.com", but it does know about other local example.com machines. We can tell Control to ask it when appropriate:

I don’t have any such server on my network (there are only two of us here, so we don’t need it). To simulate a local DNS server I used this DNS server Perl code. With that, I can ask Control about "foo.example.com" (not "foobar", but "foo") and get an answer that actually comes from that Perl code.

That code only knows about "foo.example.com", by the way. You also need to understand that the hosts table gets looked at first. If I add "foo.example.com" there, that’s the IP I’ll get.

OK, that’s all good. What happens when we ask about a machine nobody knows about?

In this case, we get an instant response. After checking Hosts, the query was forwarded to my fake local DNS server, but that simply returned nothing – it doesn’t know. Control won’t ask the Internet servers because it has been told that my fake DNS server will handle example.com.

If we wanted that query to go to the Internet, we could exclude "foowho" from forwarding.

Because there is no "foowho.example.com" that Google’s servers know of, our query fails.

There actually is a "www.example.com", though. If I leave things as shown here, that lookup would fail, because my fake dns server know nothing about that. However, if I add that to be excluded from forwarding just like "foowho", Google’s servers will resolve it:

There’s one more thing I should do, though. If that bit of Perl code were actually a DNS server, I’d want to specify the reverse loookup, too:

With that, everything should now work perfectly. If you want to experiment with these sorts of things, remember to hit the "Clear Cache" button after each change; reqursts will be filled from cache before anything else.

If you found something useful today, please consider a small donation.

На прокси сервере установлен WinXP Pro SP2 + Kerio WRF 6.5.2 build 5172

в результате на всех клиентских машинах, при попытке зайти на любой сайт пишется вот это

DNS lookup failed.

как победить?
DNSы у провайдера работают. Сеть с доменом. Прокси в домене.

По роду своей работы в сфере IT мне достаточно часто приходится сталкиваться с проблемами не всегда стандартными для IT сферы. Так же заметки со ссылками на статьи которые очень часто на практике выручали, держать на своем компе стало не удобно. По этой причине создан этот блог – записная книжка статей и заметок. Авторов статей прошу не обижаться если местами забыл сделать на них обратную ссылку. Пишите в комментариях все обязательно поправлю..

Читайте также:  Безлимитный интернет это сколько

Поиск по моему блогу

Правильные настройки DNS – Kerio Winroute

Рассматриваем три самых распространеных общих случая:

1. Одноранговая сеть, без домена , точнее без DNS-сервера, в качестве шлюза в Интернет используется отдельная машина с установленным Winroute;
2. Сеть с доменом, DNS-сервер находится на DC (контроллере домена), в качестве шлюза в Интернет используется отдельная машина с установленным Winroute;
3. Сеть с доменом, DNS-сервер находится на DC, Winroute также установлен на этот DC.

Третий вариант категорически не рекомендуется по соображениям безопасности и здравого смысла, но к сожалению применяется довольно часто в небольших сетях, где домен уже есть, а денег уже нет 🙂

Имеется в любом случае компьютер с двумя сетевыми картами (одна внутренняя – смотрит в локальную сеть, другая внешняя – в Интернет соответственно), через который мы и будем выходить в Интернет, и на который естественно 🙂 будет установлен Kerio Winroute Firewall.
Не забывайте, что адреса на этих сетевых картах должны быть из разных подсетей, т.е. например так:
NIC1: 192.168.0.1 mask 255.255.255.0
NIC2: 172.30.0.1 mask 255.255.255.0
почему-то новички очень часто на этом попадаются, если у них например ADSL-модем стоит.
1. Настройка DNS в одноранговой сети.
Настройки внутренней сетевой карты сервера Kerio:

192.168.0.1 – IP-адрес компьютера с Kerio Winroute
255.255.255.0 – маска
192.168.0.1 – в качестве DNS-сервера указываем IP-адрес этой же сетевой
Шлюз НЕ указываем!

Дальше, берем настройки, данные нам провайдером, допустим такие:

ip 80.237.0.99 – реальный IP
mask 255.255.255.240 – маска
gate 80.237.0.97 – шлюз
dns 80.237.0.97 – DNS провайдера

Но! Не забиваем их втупую во внешнюю сетевую, а делаем немного по-своему:

ip 80.237.0.99
mask 255.255.255.240
gate 80.237.0.97
dns 192.168.0.1 – в качестве основного DNS-сервера указываем IP-адрес внутренней сетевой
80.237.0.97 – в качестве альтернативного DNS-сервера указываем DNS-сервер провайдера

Жмем Advanced. В закладке DNS убираем галочку на Register this connectionТs addresses in DNS, в закладке WINS убираем Enable LMHOSTS lookup и ставим Disable NetBIOS over TCP/IP. Также, галочек НЕ ДОЛЖНО БЫТЬ на Client for Microsoft Networks, Network Load Balancing, Fail and Printer Sharing Microsoft Networks.
Кстати, удобно переименовать внешний интерфейс, назвать не Local Area Connection (Подключение по локальной сети), а например Internet.
Дальше, заходим в Панель управления, Cетевые подключения, в этом окне (окно проводника) меню Дополнительно -> Дополнительные параметры. Во вкладке "Адаптеры и привязки" передвигаем "Local Area Connection" ("Подключение по локальной сети") на самую верхнюю позицию.

На клиентском компьютере настройки сетевой карты будут примерно такие:

ip 192.168.0.2
mask 255.255.255.0
gate 192.168.0.1 – в качестве шлюза указываем IP-адрес компа с Winroute
dns 192.168.0.1 – в качестве основного DNS-сервера указываем IP-адрес компа с Winroute

В Winroute, Configuration -> DNS Forwarder ставим галку "Enable DNS Forwarding", указываем DNS-серверы провайдера.

2. Сеть с доменом, DNS-сервер находится на DC (контроллере домена), в качестве шлюза в Интернет используется отдельная машина с установленным Winroute.
Настройки не очень отличаются от предыдущего варианта, в принципе все тоже самое, только:
2.1 В зонах прямого просмотра DNS следует убрать зону ".", если она там есть. После этого перезапустить службу "DNS-сервер".
2.2 На контроллере домена в свойствах DNS нужно разрешить пересылку на IP-адрес компьютера с Winroute (если используется DNS-форвардер в самом керио): НО! лучше пересылку настроить НА ДНС ПРОВАЙДЕРА

2.3 Настройки внутренней сетевой

Читайте также:  Ga p55a ud4 bios

192.168.0.1 – IP-адрес компьютера с Winroute
255.255.255.0 – маска.
192.168.0.100 – в качестве основного DNS-сервера указываем IP-адрес локального DNS-сервера (DC)
Шлюз НЕ указываем!
2.3.1 Настройки внешней сетевой:

ip 80.237.0.99
mask 255.255.255.240
gate 80.237.0.97 – в качестве шлюза указываем IP-адрес шлюза, данный провайдером
dns 192.168.0.100 – в качестве основного DNS-сервера указываем IP-адрес локального DNS-сервера (DC)

2.4 В Winroute, Configuration -> DNS Forwarder ставим галку "Enable DNS Forwarding", указываем DNS-серверы провайдера.
2.5 Настройки клиента:

ip 192.168.0.2
mask 255.255.255.0
gate 192.168.0.1 – в качестве шлюза указываем IP-адрес компа с Winroute
dns 192.168.0.100 – в качестве основного DNS-сервера указываем IP-адрес локального DNS-сервера (DC)

3. Сеть с доменом, DNS-сервер находится на DC, Winroute также установлен на этот DC.
Все настройки идентичны первому случаю, за исключением некоторых очень важных моментов:
3.1 В сети, которая подключена к Интернету через шлюз, являющийся контроллером домена с запущенной службой DNS-сервер, на этом контроллере в конфигурации внутреннего и внешнего интерфейса DNS-сервер должен быть настроен сам на себя.
В зонах прямого просмотра DNS следует убрать зону ".", если она там есть. После этого перезапустить службу "DNS-сервер".
В свойствах DNS-сервера на закладке "Пересылка" (Forwarding) следует разрешить пересылку на DNS-сервер провайдера. Перезапустить службу "DNS-сервер"
3.2 Необходимо создать зону обратного просмотра (у правильных админов она наверняка создана еще при поднятии DNS 🙂 ), так как без нее DNS-сервер не может определить свое имя. В качестве кода сети указываем первые 3 группы цифр своего IP-адреса.
Для проверки заходим в свойства зоны и убеждаемся там в наличии нашего DNS-сервера (или серверов, если их несколько) на закладке "Серверы имен". Если серверов не хватает, добавляем их туда. Желательно делать это с помощью "Обзора". Всё. Осталось разрешить динамическое обновление, чтобы клиентские машины регистрировались в этой зоне, хотя можно обойтись и без этого.
3.3 На контроллере домена в свойствах DNS нужно разрешить пересылку на IP-адрес DNS-сервера провайдера, в данном случае 80.237.0.97;
3.4 DNS Forwarder в Winroute выключаем (убираем галку "Enable DNS Forwarding")
3.5 Настройки внешнего интерфейса на сервере:

ip 80.237.0.99
mask 255.255.255.240
gate 80.237.0.97
dns 192.168.0.1 – в качестве основного DNS-сервера указываем IP-адрес внутренней сетевой

Альтернативный DNS-сервер не указываем! Он у нас имеется в пересылке.
3.6 Настройки клиента:

ip 192.168.0.2
mask 255.255.255.0
gate 192.168.0.1 – в качестве шлюза указываем IP-адрес DC с KWF
dns 192.168.0.1 – в качестве основного DNS-сервера указываем IP-адрес DC с KWF

Для проверки на клиенте следует выполнить команды: