Error formerr resolving

bind — DNS format error .

в логах постоянно на каждый запрос:

DNS format error from 194.85.61.20#53 resolving graphics8.nytimes.com/A for client 192.168.0.104#60010: invalid response May 22 16:33:17 srv named[1461]: error (FORMERR) resolving ‘graphics8.nytimes.com/A/IN’: 194.85.61.20#53

bind 9.8 suse12.1

В конфиге named’а в разделе logging<> добавить директиву «category resolver < null; >;» . Ошбки это не убирёт, но сообщения о них должны исчезнуть.

Хотя эти сообщения об ошибках не должны быть уж совсем на каждый запрос.

а в чем причина вобще этих сообщений? т.е. моему серверу не нравится формат ответа от форвардера,, разные версии bind ?

Нет, формат ответа не зависит от версии bind, формат описан в rfc. Обычно дело в кривых настройках серверов, когда на вышестоящем (по доменному имени) сервере указана NX-запись на сервер, который не считает себя ответственным (авторитетным) за эту зону.

В вашем случае с graphics8.nytimes.com, ИМХО, дело обстоит так. graphics8.nytimes.com через CNAME преобразуется в a1116.x.akamai.net. Сервер n0x.akamai.net, отвечающий за зону x.akamai.net на запрос a1116.x.akamai.net даёт ответ, но не авторитетный.

спасибо, вижу ты в форме), напомнишь может быть. как сделать cname вместо обратной записи. поясню, есть случаи когда на ptr запрос получаешь не имя а алиас, вот я и хочу вспомнить как это делается, (нам провайдер дает ип который не имеет ptr)

и ошибки кстати немного остались:

error (FORMERR) resolving ‘ns3.facebook.com/A/IN’: 194.85.61.20#53

error (FORMERR) resolving ‘ns3.facebook.com/AAAA/IN’: 194.85.61.20#53

error (FORMERR) resolving ‘static.ak.fbcdn.net/A/IN’: 194.85.61.20#53

«DNS format error from» — изчез «error (FORMERR) resolving» — остался, и непонятно блин /AAAA/ , если в конфе — listen-on-v6 < none; >;

sorry ,, это у меня с форвардерами проблемка, — вобщем логи щас чистые, спасибо

Запись для ip-адреса (диапазона ip-адресов) в любом разе должен делать провайдер. Просто он может писать PTR-запись, а может CNAME, ведущую на DNS-сервер клиента. Но, совсем без участия DNS-сервера провайдера в обратном преобразовании ip-адреса не обойтись 🙁

Источник

Bind FORMERR errors in syslog

I’ve recently switched out a failed router. and, a while later, I discovered a lot (at least an order or magnitude more than the number of queries) of errors reported in /var/log/syslog — of the form:

It might be relevant that I’ve got the following in bind.conf:

Is this likely an issue with the new router corrupting UDP datagrams, or something else? The new router is an (inexpensive) Netgear WNR854T — it has the latest firmware applied.

Can anyone suggest how best to diagnose this fault if it’s not obvious from the above?

— Additional details — This is a typical response from dig for an address I’m sure should resolve.

3 Answers 3

If you suspect a network element (such as your router) is truncating or corrupting UDP DNS traffic you can try the following:

1. Perform the same query, again, with dig and see if you are also getting FORMERR as the response code. Dig (with the right options) will perform similarly to your recursing server but give you more visibility into the process.
2. If you are getting FORMERRs with dig, try dig +tcp and see if the error persists (to rule out UDP issues)
3. Use Wireshark or another sniffer to capture what is actually being received by your server when it recurses to satisfy a query.

Are all of the FORMERR errors in your log complaining about non-improving referrals? What does dig say is in the «additional» section of the queries that generate these error messages?

Finally, do you have stub zones or forward-first or forward-only zones set up that you haven’t mentioned?

Your DNS traffic may be transparently intercepted, and routed to a caching DNS server and you request answers that cannot be completely answered with brief answers and the caching DNS server gives truncated, rather than minimal answers («minimal-responses yes;»). For example, www.nvidia.com.edgekey.net is resolved via CNAMES and a long list of nameservers, and it complete answer does not fit in a 500

ish byte response. Here are the steps:

1. Your BIND makes a non-recursive request to a root server, and expects only authoritative answers (in this case referrals to NS servers responsible for the zone).
2. The caching DNS server which answers the intercepted request responds with a non-authoritative but incomplete answer, eg, the exact A record being sought, but with a truncated authority section which does not include the authoritative server for that record. Example (note there is no NS referal for akamaiedge.net):

1. Your BIND sees the non-authoritative answer arriving from a supposedly authoritative server (the answer itself includes the NS referrals, so BIND knows the responding server is not authoritative for the A record), and discards the entire response with FORMERR:

The OP question includes an equivalent description of the problem (non-improving NS record == unrelated record in authority section):

1. Your BIND then attempts the same non-recursive query to the next root server, and the cycle repeats until there are no more root servers to try, and BIND responds with SERVFAIL to the original recursive query.

Arguably the problem is one or several bugs in BIND itself:

• It checks the consistency of the AUTHORITY section in answers to non-recursive questions, eg, when forwarding a query to an upstream cache. It should not reject inconsistent answers, as they may be caused by valid truncation of long AUTHORITY sections
• When caching, it truncates answers naively. It should truncate more smartly and give AUTHORITY sections that are more useful when truncated, or give minimal answers (no AUTHORITY section) if the truncated AUTHORITY section would not be useful.
• It should default to «minimal-responses yes;» in caching mode.
• It should LOG/report if its authoritative queries are answered by non authoritative server (ie, RD flag unset in sent query, but set in received response), ie, detect and report intercepted DNS traffic.

I should note that queries that can be answered completely in a small packet do not trigger these bugs, and therefore, most DNS queries are resolved correctly.

Possible solutions:

• ask your ISP to add «minimal-responses yes;» to their cache configuration.
• get the ISP to not intercept your DNS, maybe by switching ISPs
• run a different BIND version without the bugs (I don’t know if such a version exists) or a different software.
• route BIND’s upstream queries through a VPN, and around the DNS intercept

Источник

bind9 часть сайтов не видит

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

причем иногда ипы выдаются, потом опять пропадает, что это вообще может быть как проверить?

отключил сыпящиеся в логи ошибки

при этом вот отдельное что то получаю

пришлось в resolve.conf добавить еще один nameserver провайдера (раньше был только 127.0.0.1), через этот костыль ентернет работает, но почему бинд не хочет находить и кешировать запросы то.

статистика по рекурсиву адекватная нет?

tcpdump на 53ем порту много всяких IP proxy.domain > .63747: 32620 ServFail 0/0/0 (34)

если и есть криминал какой то то я его не вижу (

Пров с DNS не хулиганит? Коннекты на 53 порт не перехватывает?

у прова как обычно все замечательно, кроме меня проблем ни у кого нет (

нужны пруфы, как их найти!?

Это наверное надо каким-нибудь сниффером смотреть.

смотрел дампом на порту, много мусора, но после рестарта бинда вот такая вот куча запросов, но по факту ответа не приходит

Вот с логами не подскажу. Я этим не занимался.

Если грешишь на провайдера, пропиши в конфиге бинда в качестве форвардов гугловские днс и потестируй. Если будет та же беда — проблема в конфиге или зонах бинда, если нет, нужно копать дальше.

прописал форвардинг днс на 8.8.4.4 и 8.8.8.8 — проблемы нет

самое для меня удивительное, что адрес какой то может не резолвиться, а через какое то время появиться, например http://www.avito.ru не резолвится, а avito.ru норм, бывает что и наоборот и что оба «не отвечают», проверяю после рестарта и флуша

а может просто udp пакеты теряются? хотя пробовал делать диг на один из корневых — ответило нормально.

итак, что установлено достоверно точно, без форвардинга активно валятся ошибки по resolver и lame-servers, на текущее время без форвардинга работает уже больше сайтов чем было, но все еще не все

т.е. без форвардинга на днс провайдера ошибок по resolver и lame-servers почти нет

логи включил на все каналы уже что есть в бинде

Источник

BIND DNS format error: Possible DDoS attack?

micski

I was notified, that a BIND DNS server, which is authorative for a number of domains, is open to abuse for DDoS attacks, targeting other networks. When testing on MX Tool, there is no problems according to the report.

Looking into the logs, there actually is tons of messages about a format error on different unknown IP adresses. I have not been unable to find out, what that error message is about.

The DNS server is authoritative for a number of domains, so I assume, it should be open for queries, but otherwise restricted. Is it possible, that the configuration below can lead to abuse? Keep in mind, that the DNS server is authoritative for a number of domains, and, that it has other primary DNS servers (GratisDNS).

One of the domains:

SirDice

Administrator

micski

SirDice

Administrator

As far as I can tell they’re not successful, but those modified queries are causing errors to be logged. Because BIND does find there’s something wrong with those queries, and it’s warning you about it.

But the best way would be to capture that traffic and analyze it yourself. Then you can try to figure out what they’re actually trying to do.

Reactions: micski

covacat

SirDice

Administrator

covacat

Reactions: micski

What’s the difference between allow-query-cache and allow-recursion?

Reactions: micski

What that notification was talking about were probably DNS reflection/amplification attacks. Those could be carried out on *any* open resolver, as those attacks are using nothing but the desired behaviour of a nameserver: They send hundreds of thousands of (non-resolvable) request from a spoofed source address (=target) via botnets to as many nameservers as possible, so that target gets DDoSed by the millions of error replies frem the nameservers that think this host asked for some non-existent DNS record.

For nameservers that are authorative for a/some zone(s), you usually don’t want them to serve as ‘generic’ nameservers (i.e. recursive resolvers for clients), but *only* serve the zones they are responsible for. This way you can close down that nameserver very tightly and also identify and mitigate attacks relatively easily by blacklisting hosts/IPs that repeatedly send request for zones that the server isn’t responsible for. As a first line of defense you should also always configure rate-limits.
To serve the clients in your networks you usually use separate, internal (caching) resolvers, not the authorative nameservers for your zones.

If you *have* to run an open resolver, you should absolutely have finely tuned rate-limits [1] in place. IIRC from BIND 9.10 onwards rate-limit can be set globally and per view, so you could set higher thresholds for your own networks than for the rest of the world. Usually you don’t need to run an open resolver even if you run big networks and/or public prefixes — so double- and triple-check if you think you *really* need a fully open resolver, because in most cases you were wrong.

Источник

Recently I was configuring Bind 9 on Centos 6.2. The setup was pretty straight forward: caching name server with one authoritative local domain. But the problem was that it was resolving my local authoritative domain but getting SERVFAIL for all external queries! I tried using forwardars, forward only, forward first but nothing helped. «dig @127.0.0.1 yahoo.com» was giving a SERVFAIL and «dig @192.168.1.1 yahoo.com» was working fine.

This problem almost made me crazy and was about to give up on bind until I found the problem. I tried every thing: I was configuring bind on a KVM VM, I thought may be its the Bridge or the KVM’s internal network bug. I tried bind on a physical machine, but the problem was same! I tried it on Fedora 14, same problem! Next I tried it on different versions of bind, but the error was the exact same!

Here are the errors I was getting in the named.run logs:

DNS format error from 128.63.2.53#53 resolving yahoo.com/A for client 127.0.0.1#39224: reply has no answer
error (FORMERR) resolving ‘yahoo.com/A/IN’: 128.63.2.53#53
DNS format error from 202.12.27.33#53 resolving yahoo.com/A for client 127.0.0.1#39224: reply has no answer
error (FORMERR) resolving ‘yahoo.com/A/IN’: 202.12.27.33#53
DNS format error from 192.5.5.241#53 resolving yahoo.com/A for client 127.0.0.1#39224: reply has no answer
error (FORMERR) resolving ‘yahoo.com/A/IN’: 192.5.5.241#53
DNS format error from 192.36.148.17#53 resolving yahoo.com/A for client 127.0.0.1#39224: reply has no answer
error (FORMERR) resolving ‘yahoo.com/A/IN’: 192.36.148.17#53
DNS format error from 128.8.10.90#53 resolving yahoo.com/A for client 127.0.0.1#39224: reply has no answer
error (FORMERR) resolving ‘yahoo.com/A/IN’: 128.8.10.90#53
DNS format error from 193.0.14.129#53 resolving yahoo.com/A for client 127.0.0.1#39224: reply has no answer
error (FORMERR) resolving ‘yahoo.com/A/IN’: 193.0.14.129#53
DNS format error from 192.112.36.4#53 resolving yahoo.com/A for client 127.0.0.1#39224: reply has no answer
error (FORMERR) resolving ‘yahoo.com/A/IN’: 192.112.36.4#53
DNS format error from 199.7.83.42#53 resolving yahoo.com/A for client 127.0.0.1#39224: reply has no answer
error (FORMERR) resolving ‘yahoo.com/A/IN’: 199.7.83.42#53
DNS format error from 192.33.4.12#53 resolving yahoo.com/A for client 127.0.0.1#39224: reply has no answer
error (FORMERR) resolving ‘yahoo.com/A/IN’: 192.33.4.12#53
DNS format error from 192.203.230.10#53 resolving yahoo.com/A for client 127.0.0.1#39224: reply has no answer
error (FORMERR) resolving ‘yahoo.com/A/IN’: 192.203.230.10#53
DNS format error from 198.41.0.4#53 resolving yahoo.com/A for client 127.0.0.1#39224: reply has no answer
error (FORMERR) resolving ‘yahoo.com/A/IN’: 198.41.0.4#53
DNS format error from 192.228.79.201#53 resolving yahoo.com/A for client 127.0.0.1#39224: reply has no answer
error (FORMERR) resolving ‘yahoo.com/A/IN’: 192.228.79.201#53
DNS format error from 192.58.128.30#53 resolving yahoo.com/A for client 127.0.0.1#39224: reply has no answer
error (FORMERR) resolving ‘yahoo.com/A/IN’: 192.58.128.30#53

So basically bind was getting a malformed response from all the root level servers it was trying in the hint file named.ca

The Solution:

After enabling the debug mode and monitoring traffic with tcpdump, I found the problem. The culprit was my DSL router (AzTech 605EW). And apparently most home dsl routers will behave abnormally with large udp packets. The large udp packets are because bind uses EDNS when querying other DNS servers.

Adding the following configuration in named.conf disabled edns and solved the problem!

server ::/0 { edns no; };
server 0.0.0.0/0 { edns no; };

Your DNS traffic may be transparently intercepted, and routed to a caching DNS server and you request answers that cannot be completely answered with brief answers and the caching DNS server gives truncated, rather than minimal answers («minimal-responses yes;»). For example, www.nvidia.com.edgekey.net is resolved via CNAMES and a long list of nameservers, and it complete answer does not fit in a 500~ish byte response. Here are the steps:

1. Your BIND makes a non-recursive request to a root server, and expects only authoritative answers (in this case referrals to NS servers responsible for the zone).
2. The caching DNS server which answers the intercepted request responds with a non-authoritative but incomplete answer, eg, the exact A record being sought, but with a truncated authority section which does not include the authoritative server for that record. Example (note there is no NS referal for akamaiedge.net):

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id:  59893
;; flags: qr rd ra; QUESTION: 1, ANSWER: 2, AUTHORITY: 13, ADDITIONAL: 2
;; QUESTION SECTION:
;www.nvidia.com.edgekey.net.    IN      A

;; ANSWER SECTION:
www.nvidia.com.edgekey.net. 21559 IN    CNAME   e14462.a.akamaiedge.net.
e14462.a.akamaiedge.net. 19     IN      A       184.85.26.247

;; AUTHORITY SECTION:
edgekey.net.            13382   IN      NS      a18-65.akam.net.
edgekey.net.            13382   IN      NS      ns5-66.akam.net.
edgekey.net.            13382   IN      NS      a6-65.akam.net.
edgekey.net.            13382   IN      NS      ns7-65.akam.net.
edgekey.net.            13382   IN      NS      a5-65.akam.net.
edgekey.net.            13382   IN      NS      a13-65.akam.net.
edgekey.net.            13382   IN      NS      ns1-66.akam.net.
edgekey.net.            13382   IN      NS      ns4-66.akam.net.
edgekey.net.            13382   IN      NS      a28-65.akam.net.
edgekey.net.            13382   IN      NS      adns1.akam.net.
edgekey.net.            13382   IN      NS      a12-65.akam.net.
edgekey.net.            13382   IN      NS      usw6.akam.net.
edgekey.net.            13382   IN      NS      a16-65.akam.net.

;; ADDITIONAL SECTION:
a13-65.akam.net.        11507   IN      A       2.22.230.65
adns1.akam.net.         13382   IN      A       96.7.50.66

1. Your BIND sees the non-authoritative answer arriving from a supposedly authoritative server (the answer itself includes the NS referrals, so BIND knows the responding server is not authoritative for the A record), and discards the entire response with FORMERR:

DNS format error from 192.58.128.30#53 resolving www.nvidia.com.edgekey.net/A for client 127.0.0.1#53636: unrelated A e14462.a.akamaiedge.net in edgekey.net authority section

The OP question includes an equivalent description of the problem (non-improving NS record == unrelated record in authority section):

Mar 18 19:53:20 kenneth named[4022]: DNS format error from 192.112.36.4#53 resolving ./NS: non-improving referral

1. Your BIND then attempts the same non-recursive query to the next root server, and the cycle repeats until there are no more root servers to try, and BIND responds with SERVFAIL to the original recursive query.

Arguably the problem is one or several bugs in BIND itself:

• It checks the consistency of the AUTHORITY section in answers to non-recursive questions, eg, when forwarding a query to an upstream cache. It should not reject inconsistent answers, as they may be caused by valid truncation of long AUTHORITY sections
• When caching, it truncates answers naively. It should truncate more smartly and give AUTHORITY sections that are more useful when truncated, or give minimal answers (no AUTHORITY section) if the truncated AUTHORITY section would not be useful.
• It should default to «minimal-responses yes;» in caching mode.
• It should LOG/report if its authoritative queries are answered by non authoritative server (ie, RD flag unset in sent query, but set in received response), ie, detect and report intercepted DNS traffic.

I should note that queries that can be answered completely in a small packet do not trigger these bugs, and therefore, most DNS queries are resolved correctly.

Possible solutions:

• ask your ISP to add «minimal-responses yes;» to their cache configuration.
• get the ISP to not intercept your DNS, maybe by switching ISPs
• run a different BIND version without the bugs (I don’t know if such a version exists) or a different software.
• route BIND’s upstream queries through a VPN, and around the DNS intercept

Здравствуйте!
Недавно решил поднять кэширующий ДНС-сервер. Собственно говоря, по самой процедуре вопросов особых не возникло. На первый взгляд всё заработало. Но есть одна проблема: логи буквально за считаные минуты разрастаются до огромных размеров. И записи в них вот такого содержания:

error (unexpected RCODE SERVFAIL) resolving '211.70.191.186.IN-ADDR.ARPA/PTR/IN': 170.51.242.18#53
error (unexpected RCODE REFUSED) resolving 'www.newultra.ru/A/IN';: 193.104.149.65#53
error (unexpected RCODE REFUSED) resolving '55.186.136.89.in-addr.arpa/PTR/IN': 194.102.255.3#53
error (unexpected RCODE SERVFAIL) resolving 'highschoolemail.com/MX/IN': 64.207.128.246#53
error (unexpected RCODE REFUSED) resolving 'www.realfit.ru/A/IN';: 83.170.91.205#53
error (unexpected RCODE SERVFAIL) resolving '219.247.28.196.IN-ADDR.ARPA/PTR/IN': 66.198.145.99#53
error (unexpected RCODE REFUSED) resolving 'www.newultra.ru/A/IN';: 91.210.6.228#53
error (FORMERR) resolving 'u8lafv05630edji3ui4m2muoms.gcdn.biz/AAAA/IN': 94.75.223.25#53
error (unexpected RCODE SERVFAIL) resolving '219.247.28.196.IN-ADDR.ARPA/PTR/IN': 193.50.53.3#53
error (unexpected RCODE REFUSED) resolving '125.64-127.111.23.163.in-addr.arpa/PTR/IN': 163.23.111.65#53
error (unexpected RCODE SERVFAIL) resolving '219.247.28.196.IN-ADDR.ARPA/PTR/IN': 66.198.145.99#53
error (FORMERR) resolving 'u8lafv05630edji3ui4m2muoms.gcdn.biz/AAAA/IN': 188.40.44.206#53
error (unexpected RCODE REFUSED) resolving '200.169.147.120.in-addr.arpa/PTR/IN': 144.135.133.76#53
error (unexpected RCODE SERVFAIL) resolving 'highschoolemail.com/TXT/IN': 64.207.128.246#53
error (unexpected RCODE SERVFAIL) resolving 'www.pink-pelikan.ru/A/IN';: 91.142.81.238#53
error (FORMERR) resolving 'u8lafv05630edji3ui4m2muoms.gcdn.biz/AAAA/IN': 94.75.223.25#53
error (unexpected RCODE REFUSED) resolving '26.212.120.193.in-addr.arpa/PTR/IN': 192.111.39.4#53
error (unexpected RCODE SERVFAIL) resolving '219.247.28.196.IN-ADDR.ARPA/PTR/IN': 193.50.53.3#53
error (FORMERR) resolving 'u8lafv05630edji3ui4m2muoms.gcdn.biz/AAAA/IN': 85.17.79.33#53
error (unexpected RCODE REFUSED) resolving '133.138.151.90.in-addr.arpa/PTR/IN': 195.38.32.2#53
error (unexpected RCODE REFUSED) resolving 'www.newultra.ru/A/IN';: 91.210.6.228#53
error (unexpected RCODE REFUSED) resolving '4.107.151.90.in-addr.arpa/PTR/IN': 195.38.33.2#53
error (unexpected RCODE REFUSED) resolving '133.138.151.90.in-addr.arpa/PTR/IN': 195.38.33.2#53
error (unexpected RCODE REFUSED) resolving '4.107.151.90.in-addr.arpa/PTR/IN': 195.38.32.2#53
error (unexpected RCODE REFUSED) resolving 'medsys.co.uk/MX/IN': 158.43.129.77#53
error (unexpected RCODE REFUSED) resolving 'medsys.co.uk/A/IN': 158.43.193.77#53
error (unexpected RCODE SERVFAIL) resolving 'www.pink-pelikan.ru/A/IN';: 91.142.84.206#53
error (FORMERR) resolving 'u8lafv05630edji3ui4m2muoms.gcdn.biz/AAAA/IN': 85.17.79.33#53
error (unexpected RCODE REFUSED) resolving '219.247.28.196.IN-ADDR.ARPA/PTR/IN': 206.82.130.196#53
error (unexpected RCODE REFUSED) resolving '26.212.120.193.in-addr.arpa/PTR/IN': 192.111.39.1#53
error (unexpected RCODE REFUSED) resolving 'www.newultra.ru/A/IN';: 193.104.149.65#53
error (unexpected RCODE REFUSED) resolving '125.64-127.111.23.163.in-addr.arpa/PTR/IN': 163.23.111.65#53
error (unexpected RCODE REFUSED) resolving '133.138.151.90.in-addr.arpa/PTR/IN': 195.38.32.2#53
error (unexpected RCODE REFUSED) resolving '4.107.151.90.in-addr.arpa/PTR/IN': 195.38.33.2#53
error (unexpected RCODE REFUSED) resolving '133.138.151.90.in-addr.arpa/PTR/IN': 195.38.33.2#53
error (unexpected RCODE REFUSED) resolving '4.107.151.90.in-addr.arpa/PTR/IN': 195.38.32.2#53
error (unexpected RCODE REFUSED) resolving 'www.newultra.ru/A/IN';: 193.104.149.65#53
error (unexpected RCODE REFUSED) resolving '55.186.136.89.in-addr.arpa/PTR/IN': 194.102.255.3#53
error (FORMERR) resolving 'a296759604eedd6537600849db0595f0f7e9f2537b67cbb4.gcdn.biz/AAAA/IN': 94.75.223.25#53
error (FORMERR) resolving 'u8lafv05630edji3ui4m2muoms.gcdn.biz/AAAA/IN': 188.40.44.206#53
error (unexpected RCODE SERVFAIL) resolving '90.53.188.91.in-addr.arpa/PTR/IN': 81.198.180.1#53
error (unexpected RCODE REFUSED) resolving '133.138.151.90.in-addr.arpa/PTR/IN': 195.38.33.2#53
error (unexpected RCODE REFUSED) resolving '133.138.151.90.in-addr.arpa/PTR/IN': 195.38.32.2#53
error (unexpected RCODE REFUSED) resolving 'www.newultra.ru/A/IN';: 91.210.6.228#53
error (unexpected RCODE REFUSED) resolving '76.96.53.92.in-addr.arpa/PTR/IN': 92.53.98.100#53
error (unexpected RCODE REFUSED) resolving '219.247.28.196.IN-ADDR.ARPA/PTR/IN': 206.82.130.196#53
error (unexpected RCODE REFUSED) resolving '133.138.151.90.in-addr.arpa/PTR/IN': 195.38.33.2#53
error (unexpected RCODE REFUSED) resolving '133.138.151.90.in-addr.arpa/PTR/IN': 195.38.32.2#53
error (FORMERR) resolving 'a296759604eedd6537600849db0595f0f7e9f2537b67cbb4.gcdn.biz/AAAA/IN': 85.17.79.33#53
error (unexpected RCODE REFUSED) resolving '76.96.53.92.in-addr.arpa/PTR/IN': 92.53.116.200#53
error (unexpected RCODE REFUSED) resolving 'www.7dvd.ru/A/IN';: 89.108.104.3#53
error (unexpected RCODE SERVFAIL) resolving 'www.7dvd.ru/A/IN';: 89.108.64.2#53
error (unexpected RCODE REFUSED) resolving '247.237.38.89.IN-ADDR.ARPA/PTR/IN': 82.79.33.10#53
error (unexpected RCODE SERVFAIL) resolving '90.53.188.91.in-addr.arpa/PTR/IN': 81.198.180.1#53
error (unexpected RCODE SERVFAIL) resolving 'highschoolemail.com/A/IN': 70.32.65.137#53
error (unexpected RCODE SERVFAIL) resolving 'www.pink-pelikan.ru/A/IN';: 91.142.84.206#53
error (FORMERR) resolving 'a296759604eedd6537600849db0595f0f7e9f2537b67cbb4.gcdn.biz/AAAA/IN': 188.40.44.206#53
error (unexpected RCODE REFUSED) resolving '13.145.245.121.IN-ADDR.ARPA/PTR/IN': 202.54.15.30#53
error (unexpected RCODE REFUSED) resolving '140.102.151.90.in-addr.arpa/PTR/IN': 195.38.33.2#53
error (unexpected RCODE REFUSED) resolving '224.140.151.90.in-addr.arpa/PTR/IN': 195.38.33.2#53
error (unexpected RCODE REFUSED) resolving '94.141.151.90.in-addr.arpa/PTR/IN': 195.38.32.2#53
error (unexpected RCODE REFUSED) resolving '94.141.151.90.in-addr.arpa/PTR/IN': 195.38.33.2#53
error (unexpected RCODE REFUSED) resolving '140.102.151.90.in-addr.arpa/PTR/IN': 195.38.32.2#53
error (unexpected RCODE REFUSED) resolving '224.140.151.90.in-addr.arpa/PTR/IN': 195.38.32.2#53
error (unexpected RCODE REFUSED) resolving 'medsys.co.uk/TXT/IN': 158.43.129.77#53
error (unexpected RCODE REFUSED) resolving 'medsys.co.uk/MX/IN': 158.43.129.77#53
error (unexpected RCODE REFUSED) resolving 'www.newultra.ru/A/IN';: 193.104.149.65#53
error (unexpected RCODE SERVFAIL) resolving 'www.pink-pelikan.ru/A/IN';: 91.142.81.238#53
error (unexpected RCODE REFUSED) resolving 'medsys.co.uk/A/IN': 158.43.193.77#53
error (unexpected RCODE REFUSED) resolving '21.212.120.193.in-addr.arpa/PTR/IN': 192.111.39.1#53
error (unexpected RCODE REFUSED) resolving '19.212.120.193.in-addr.arpa/PTR/IN': 192.111.39.1#53
error (unexpected RCODE REFUSED) resolving 'medsys.co.uk/TXT/IN': 158.43.193.77#53
error (unexpected RCODE REFUSED) resolving 'www.newultra.ru/A/IN';: 91.210.6.228#53
error (unexpected RCODE REFUSED) resolving 'medsys.co.uk/MX/IN': 158.43.193.77#53
error (unexpected RCODE REFUSED) resolving 'medsys.co.uk/A/IN': 158.43.129.77#53
error (unexpected RCODE REFUSED) resolving '19.212.120.193.in-addr.arpa/PTR/IN': 192.111.39.4#53
error (unexpected RCODE REFUSED) resolving 'medsys.co.uk/A/IN': 158.43.129.77#53
error (unexpected RCODE REFUSED) resolving '26.212.120.193.in-addr.arpa/PTR/IN': 192.111.39.4#53
error (unexpected RCODE SERVFAIL) resolving 'highschoolemail.com/MX/IN': 64.207.128.246#53
error (unexpected RCODE REFUSED) resolving 'medsys.co.uk/MX/IN': 158.43.129.77#53
error (unexpected RCODE REFUSED) resolving '39.141.151.90.in-addr.arpa/PTR/IN': 195.38.32.2#53
error (unexpected RCODE REFUSED) resolving '39.141.151.90.in-addr.arpa/PTR/IN': 195.38.33.2#53
error (unexpected RCODE REFUSED) resolving '140.102.151.90.in-addr.arpa/PTR/IN': 195.38.33.2#53
error (unexpected RCODE REFUSED) resolving '224.140.151.90.in-addr.arpa/PTR/IN': 195.38.33.2#53
error (unexpected RCODE REFUSED) resolving '140.102.151.90.in-addr.arpa/PTR/IN': 195.38.32.2#53
error (unexpected RCODE REFUSED) resolving '224.140.151.90.in-addr.arpa/PTR/IN': 195.38.32.2#53
error (unexpected RCODE REFUSED) resolving 'medsys.co.uk/A/IN': 158.43.193.77#53
error (unexpected RCODE REFUSED) resolving '26.212.120.193.in-addr.arpa/PTR/IN': 192.111.39.1#53
error (unexpected RCODE REFUSED) resolving 'www.newultra.ru/A/IN';: 193.104.149.65#53
error (unexpected RCODE SERVFAIL) resolving '32server.bpiconnect.com/A/IN': 217.160.81.164#53
error (unexpected RCODE REFUSED) resolving 'www.newultra.ru/A/IN';: 91.210.6.228#53
error (unexpected RCODE REFUSED) resolving 'topya.ru/A/IN': 77.120.107.131#53
error (unexpected RCODE SERVFAIL) resolving 'highschoolemail.com/A/IN': 64.207.128.246#53
error (unexpected RCODE REFUSED) resolving '21.212.120.193.in-addr.arpa/PTR/IN': 192.111.39.1#53
error (unexpected RCODE REFUSED) resolving '19.212.120.193.in-addr.arpa/PTR/IN': 192.111.39.1#53
error (unexpected RCODE SERVFAIL) resolving '32server.bpiconnect.com/A/IN': 217.160.80.164#53
error (unexpected RCODE REFUSED) resolving 'topya.ru/A/IN': 77.120.107.132#53
error (unexpected RCODE REFUSED) resolving '56.143.151.90.in-addr.arpa/PTR/IN': 195.38.32.2#53
error (unexpected RCODE REFUSED) resolving '167.102.151.90.in-addr.arpa/PTR/IN': 195.38.32.2#53
error (unexpected RCODE REFUSED) resolving '32.100.151.90.in-addr.arpa/PTR/IN': 195.38.33.2#53
error (unexpected RCODE REFUSED) resolving '167.102.151.90.in-addr.arpa/PTR/IN': 195.38.33.2#53
error (unexpected RCODE REFUSED) resolving '224.140.151.90.in-addr.arpa/PTR/IN': 195.38.32.2#53
error (unexpected RCODE REFUSED) resolving '56.143.151.90.in-addr.arpa/PTR/IN': 195.38.33.2#53
error (unexpected RCODE REFUSED) resolving '224.140.151.90.in-addr.arpa/PTR/IN': 195.38.33.2#53
error (unexpected RCODE REFUSED) resolving '32.100.151.90.in-addr.arpa/PTR/IN': 195.38.32.2#53
error (unexpected RCODE REFUSED) resolving '167.102.151.90.in-addr.arpa/PTR/IN': 195.38.33.2#53
error (unexpected RCODE REFUSED) resolving '56.143.151.90.in-addr.arpa/PTR/IN': 195.38.32.2#53
error (unexpected RCODE REFUSED) resolving '167.102.151.90.in-addr.arpa/PTR/IN': 195.38.32.2#53
error (unexpected RCODE REFUSED) resolving '56.143.151.90.in-addr.arpa/PTR/IN': 195.38.33.2#53
error (unexpected RCODE SERVFAIL) resolving 'highschoolemail.com/MX/IN': 70.32.65.137#53
error (unexpected RCODE REFUSED) resolving '21.212.120.193.in-addr.arpa/PTR/IN': 192.111.39.4#53
error (unexpected RCODE REFUSED) resolving '19.212.120.193.in-addr.arpa/PTR/IN': 192.111.39.4#53
error (unexpected RCODE REFUSED) resolving '125.64-127.111.23.163.in-addr.arpa/PTR/IN': 163.23.111.65#53
error (unexpected RCODE SERVFAIL) resolving '211.70.191.186.IN-ADDR.ARPA/PTR/IN': 170.51.242.18#53

И это лишь маленький кусочек лога. Мне пришлось остановить named, дабы он весь винт не забил своими логами…
Вот конфиг:

//
// named.conf
//
// Provided by Red Hat bind package to configure the ISC BIND named(8) DNS
// server as a caching only nameserver (as a localhost DNS resolver only).
//
// See /usr/share/doc/bind*/sample/ for example named configuration files.
//

options {
        listen-on port 53 { 127.0.0.1;
        192.168.199.2; };
// listen-on-v6 port 53 { ::1; };
        directory "/var/named";
        dump-file "/var/named/data/cache_dump.db";
        statistics-file "/var/named/data/named_stats.txt";
        memstatistics-file "/var/named/data/named_mem_stats.txt";
        allow-query { localhost;
        192.168.0.0/16; };
// forwarders { 212.49.118.2;
// 212.49.103.2; };
        forwarders { 212.49.103.2;
        212.49.118.2; };
        recursion yes;

// dnssec-enable yes;
// dnssec-validation yes;
// dnssec-lookaside auto;

        /* Path to ISC DLV key */
        bindkeys-file "/etc/named.iscdlv.key";
};
logging {
        channel default_debug {
                file "data/named.run";
                severity dynamic;
        };
};

zone "." IN {
        type hint;
        file "named.ca";
};

zone "_msdcs.egarant.local" {
 type slave;
 file "_msdcs.egarant.local";
 masters { 192.168.199.202;
 192.168.199.199; };
 };

zone "egarant.local" {
 type slave;
 file "egarant.local";
 masters { 192.168.199.202;
 192.168.199.199; };
 };

zone "_msdcs.egarant1.local" {
 type slave;
 file "_msdcs.egarant1.local";
 masters { 192.168.1.200;
 192.168.1.201; };
 };

zone "egarant1.local" {
 type slave;
 file "egarant1.local";
 masters { 192.168.1.200;
 192.168.1.201; };
 };

include "/etc/named.rfc1912.zones";

Ещё я в файл /etc/sysconfig/named добавил вот такую строчку:
OPTIONS=»-4″
Это чтоб он только ай-пишники v4 кэшировал, а v6 пропускал мимо.
Один мой товарищ написал по этому поводу следующее:

Интересная ситуация…
если смотреть ошибку вида:
error (unexpected RCODE REFUSED) resolving ‘55.186.136.89.in-addr.arpa/PTR/IN’: 194.102.255.3#53
она говорит о том, что твой сервак не может получить ответ на запрос от сервера 194.102.255.3. Если пробовать спросить у этого сервера руками — он действительно ничего не отвечает. То есть, строго говоря, ничего криминального в этом нет…
У меня в логах тоже есть такие ошибки, но их число не превышает 1-2-х десятков за сутки.
Мне кажется тут проблему не в named надо искать, а в том, почему он щемится непонятно куда и спрашивает непонятно что… Причем, обрати внимание, что очень много запросов на обратные зоны…
Может у тебя какой сифилис живет, который и лезет везде подряд, просто named его показал лицом?
Постарайся отловить кто шлет все эти запросы…

Вот в связи с этим и вопрос: Как и с помощью чего можно попытаться отследить этот самый «сифилис»? Дело в том, что пока сервер, где установлен Named, никем не используется в качечестве DNS-сервера. Т.е. рабочие станции к нему пока не обращаются с днс-запросами. Неужели что-то непосредственно с самого сервера куда-то ломится?
Помогите понять причину, пожалуйста.

?