man781 Posted August 5, 2014 · Report post Доброго всем времени суток. Сижу я тихо, никого не трогаю. Админю ) Все работает. Трафик ходит. Тыщи людей радуются нашему инету. Но вот изредка меня огорчают некоторые пользователи, которые находят такие сайты, которые у них "не открываются", а у других провайдеров открываются. Итак. Последний случай. Сайт www.li.ru. Проверяю - не резолвится имя. Проверяю на другом провайдере - резолвится, сайт без проблем открывается в браузере. Для справки - резолв через гугл паблик днс dig @8.8.8.8 www.li.ru ; <<>> DiG 9.9.5-3-Ubuntu <<>> @8.8.8.8 www.li.ru ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21468 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;www.li.ru. IN A ;; ANSWER SECTION: www.li.ru. 806 IN A 88.212.196.88 www.li.ru. 806 IN A 88.212.196.87 ;; Query time: 41 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Tue Aug 05 14:07:35 FET 2014 ;; MSG SIZE rcvd: 70 Для справки - вот так выглядит запрос на свой днс серв. dig @мой_серв_днс www.li.ru ; <<>> DiG 9.9.5-3-Ubuntu <<>> @мой_серв_днс www.li.ru ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 59844 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.li.ru. IN A ;; Query time: 4999 msec ;; SERVER: мой_серв_днс#53(мой_серв_днс) ;; WHEN: Tue Aug 05 13:51:13 FET 2014 ;; MSG SIZE rcvd: 27 Получаю SERVFAIL Сервак bind9 на Debian7. 99,9% хостов резолвится без вопросов, но вот попадаются "странные". И самое печальное, что в логах байнда - вообще ПУСТО по поиску www.li.ru (хотя в других случаях хотя бы был REFUSED) Кто виноват, куда рыть, что клиентам говорить. Ткните, плиз, мордой ) Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
ipaddr.ru Posted August 5, 2014 · Report post Включить крупный подробный дебаг на байнде. Сделать dig +trace. Результаты можно сюда. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
st_re Posted August 5, 2014 · Report post вообще у них крывенько... dig ns li.ru @a.dns.ripn.net. ;; AUTHORITY SECTION: li.ru. 345600 IN NS ns2.li.ru. li.ru. 345600 IN NS ns.li.ru. На NS и NS2 зона прописана по другому dig ns li.ru @ns.li.ru. ;; ANSWER SECTION: li.ru. 900 IN NS ns4.li.ru. li.ru. 900 IN NS ns2.li.ru. li.ru. 900 IN NS ns3.li.ru. li.ru. 900 IN NS ns.li.ru. А там все плохо.. на NS3 и 4 зона не прописана # dig ns li.ru @ns3.li.ru. ;; AUTHORITY SECTION: ru. 172800 IN NS d.dns.ripn.net. ru. 172800 IN NS b.dns.ripn.net. ru. 172800 IN NS a.dns.ripn.net. ru. 172800 IN NS e.dns.ripn.net. ru. 172800 IN NS f.dns.ripn.net. # dig ns li.ru @ns4.li.ru. ru. 172800 IN NS e.dns.ripn.net. ru. 172800 IN NS f.dns.ripn.net. ru. 172800 IN NS a.dns.ripn.net. ru. 172800 IN NS b.dns.ripn.net. ru. 172800 IN NS d.dns.ripn.net. Ваш бинд спросил у 3-4 и обломался. rndc flush и наверное заработает, пока снова не попытается сходить на не удачный NS Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
man781 Posted August 5, 2014 · Report post Включить крупный подробный дебаг на байнде. Сделать dig +trace. Результаты можно сюда. Дебаг пока не включал, вот пока трассировка днс запроса dig @мой_серв www.li.ru +trace ; <<>> DiG 9.9.5-3-Ubuntu <<>> @мой_серв www.li.ru +trace ; (1 server found) ;; global options: +cmd . 3600000 IN NS K.ROOT-SERVERS.NET. . 3600000 IN NS L.ROOT-SERVERS.NET. . 3600000 IN NS C.ROOT-SERVERS.NET. . 3600000 IN NS B.ROOT-SERVERS.NET. . 3600000 IN NS I.ROOT-SERVERS.NET. . 3600000 IN NS H.ROOT-SERVERS.NET. . 3600000 IN NS D.ROOT-SERVERS.NET. . 3600000 IN NS J.ROOT-SERVERS.NET. . 3600000 IN NS F.ROOT-SERVERS.NET. . 3600000 IN NS M.ROOT-SERVERS.NET. . 3600000 IN NS E.ROOT-SERVERS.NET. . 3600000 IN NS G.ROOT-SERVERS.NET. . 3600000 IN NS A.ROOT-SERVERS.NET. ;; Received 239 bytes from мой_серв#53(мой_серв) in 16 ms ru. 172800 IN NS a.dns.ripn.net. ru. 172800 IN NS b.dns.ripn.net. ru. 172800 IN NS d.dns.ripn.net. ru. 172800 IN NS e.dns.ripn.net. ru. 172800 IN NS f.dns.ripn.net. ru. 86400 IN DS 51272 8 2 13ECAF18251EEC90C6BC8F16E2730F1F597F6D7E406C4A8FF1D4FD7D 760D6EEE ru. 86400 IN RRSIG DS 8 1 86400 20140812000000 20140804230000 8230 . UeGaRKF+BM5KSYj+Nus8o+CE6vE9DRYeJz5tv1A4LjEhv8Fpev4RYA7M PriNyNQJlcfG2c9dgftLiL0zXMl7Wu1OLZB+83Gikj1p2N7zYH+7gutA CbRZgfmPUH2jxUjBBwFr+Ihcr21MS9lTpKh1oizWC19tZGvKHsEJZcjR lMQ= ;; Received 557 bytes from 199.7.83.42#53(L.ROOT-SERVERS.NET) in 36 ms li.ru. 345600 IN NS ns.li.ru. li.ru. 345600 IN NS ns2.li.ru. tdui9d4jkuds8b9t86gj39pgflcnlgm5.ru. 3600 IN NSEC3 1 1 3 00FF TK5F5CCCO39AMJ1KLIC9U1L5NTNNNBIE NS SOA RRSIG DNSKEY NSEC3PARAM tdui9d4jkuds8b9t86gj39pgflcnlgm5.ru. 3600 IN RRSIG NSEC3 8 2 3600 20140829185822 20140722092008 43590 ru. RJi6PuLXZUgZUV32Ou8M0jl0CAkenJl8242MrpToZzlgpYljKGr5a3x4 iDAzhtxBuEQy3AYL7wCqM6ngy5lgHDtp/PlmG3GHsrf4xaOzJgVBQ0i3 K4YS/s2FbnTG77zRrvfUqgJLUAvnvTWEwSUMxj1xF/k/JbWENF5OEUdH 8es= 7b5guvqhttcfnm68pqo7erle3lg9jpbg.ru. 3600 IN NSEC3 1 1 3 00FF 7MB13U9MUJE7KF370QNQ736NMEHS2AR7 NS DS RRSIG 7b5guvqhttcfnm68pqo7erle3lg9jpbg.ru. 3600 IN RRSIG NSEC3 8 2 3600 20140903052404 20140722092008 43590 ru. VdtUlZn4rGZrk6wxNgRUf6FxCR0JYqBzSD2NQ6T0Ck1SnTjLJKfMvt7D n82hC2WRQikC/mnnsQGMmJipP3n8jNF5wq0YDACksaeW33mU1WTvr1Vt 2Tz6C+ue9cUE2r5JjocYe9D5sZQc3W5KlbGFCqkSSOSabi07omeSE5xn 3Fc= dig: couldn't get address for 'ns.li.ru': no more а вот трассировка днс запроса на гугл паблик днс dig @8.8.8.8 www.li.ru +trace ; <<>> DiG 9.9.5-3-Ubuntu <<>> @8.8.8.8 www.li.ru +trace ; (1 server found) ;; global options: +cmd . 15331 IN NS h.root-servers.net. . 15331 IN NS c.root-servers.net. . 15331 IN NS a.root-servers.net. . 15331 IN NS m.root-servers.net. . 15331 IN NS l.root-servers.net. . 15331 IN NS k.root-servers.net. . 15331 IN NS e.root-servers.net. . 15331 IN NS i.root-servers.net. . 15331 IN NS f.root-servers.net. . 15331 IN NS b.root-servers.net. . 15331 IN NS j.root-servers.net. . 15331 IN NS g.root-servers.net. . 15331 IN NS d.root-servers.net. . 15331 IN RRSIG NS 8 0 518400 20140812000000 20140804230000 8230 . UP0wVkCFEC+cHbELEbOZal742nmggb31zzoJN23dVuaTuY5v+3tl9P4R LLpNuNjap99YHxezuIb8yZKI+Ipgtd27S1b88BpfSrSDacBHpqy80DhP u4SGdKh84b4xawlT8ek7KsSY3e8xa7aI4KrFXdeuzAERaB/cQ5qqZypt 4Lw= ;; Received 397 bytes from 8.8.8.8#53(8.8.8.8) in 629 ms ru. 172800 IN NS f.dns.ripn.net. ru. 172800 IN NS d.dns.ripn.net. ru. 172800 IN NS e.dns.ripn.net. ru. 172800 IN NS a.dns.ripn.net. ru. 172800 IN NS b.dns.ripn.net. ru. 86400 IN DS 51272 8 2 13ECAF18251EEC90C6BC8F16E2730F1F597F6D7E406C4A8FF1D4FD7D 760D6EEE ru. 86400 IN RRSIG DS 8 1 86400 20140812000000 20140804230000 8230 . UeGaRKF+BM5KSYj+Nus8o+CE6vE9DRYeJz5tv1A4LjEhv8Fpev4RYA7M PriNyNQJlcfG2c9dgftLiL0zXMl7Wu1OLZB+83Gikj1p2N7zYH+7gutA CbRZgfmPUH2jxUjBBwFr+Ihcr21MS9lTpKh1oizWC19tZGvKHsEJZcjR lMQ= ;; Received 557 bytes from 199.7.91.13#53(d.root-servers.net) in 223 ms li.ru. 345600 IN NS ns.li.ru. li.ru. 345600 IN NS ns2.li.ru. TDUI9D4JKUDS8B9T86GJ39PGFLCNLGM5.ru. 3600 IN NSEC3 1 1 3 00FF TK5F5CCCO39AMJ1KLIC9U1L5NTNNNBIE NS SOA RRSIG DNSKEY NSEC3PARAM TDUI9D4JKUDS8B9T86GJ39PGFLCNLGM5.ru. 3600 IN RRSIG NSEC3 8 2 3600 20140829185822 20140722092008 43590 ru. RJi6PuLXZUgZUV32Ou8M0jl0CAkenJl8242MrpToZzlgpYljKGr5a3x4 iDAzhtxBuEQy3AYL7wCqM6ngy5lgHDtp/PlmG3GHsrf4xaOzJgVBQ0i3 K4YS/s2FbnTG77zRrvfUqgJLUAvnvTWEwSUMxj1xF/k/JbWENF5OEUdH 8es= 7B5GUVQHTTCFNM68PQO7ERLE3LG9JPBG.ru. 3600 IN NSEC3 1 1 3 00FF 7MB13U9MUJE7KF370QNQ736NMEHS2AR7 NS DS RRSIG 7B5GUVQHTTCFNM68PQO7ERLE3LG9JPBG.ru. 3600 IN RRSIG NSEC3 8 2 3600 20140903052404 20140722092008 43590 ru. VdtUlZn4rGZrk6wxNgRUf6FxCR0JYqBzSD2NQ6T0Ck1SnTjLJKfMvt7D n82hC2WRQikC/mnnsQGMmJipP3n8jNF5wq0YDACksaeW33mU1WTvr1Vt 2Tz6C+ue9cUE2r5JjocYe9D5sZQc3W5KlbGFCqkSSOSabi07omeSE5xn 3Fc= dig: couldn't get address for 'ns.li.ru': no more вообще у них крывенько... dig ns li.ru @a.dns.ripn.net. ;; AUTHORITY SECTION: li.ru. 345600 IN NS ns2.li.ru. li.ru. 345600 IN NS ns.li.ru. На NS и NS2 зона прописана по другому dig ns li.ru @ns.li.ru. ;; ANSWER SECTION: li.ru. 900 IN NS ns4.li.ru. li.ru. 900 IN NS ns2.li.ru. li.ru. 900 IN NS ns3.li.ru. li.ru. 900 IN NS ns.li.ru. А там все плохо.. на NS3 и 4 зона не прописана # dig ns li.ru @ns3.li.ru. ;; AUTHORITY SECTION: ru. 172800 IN NS d.dns.ripn.net. ru. 172800 IN NS b.dns.ripn.net. ru. 172800 IN NS a.dns.ripn.net. ru. 172800 IN NS e.dns.ripn.net. ru. 172800 IN NS f.dns.ripn.net. # dig ns li.ru @ns4.li.ru. ru. 172800 IN NS e.dns.ripn.net. ru. 172800 IN NS f.dns.ripn.net. ru. 172800 IN NS a.dns.ripn.net. ru. 172800 IN NS b.dns.ripn.net. ru. 172800 IN NS d.dns.ripn.net. Ваш бинд спросил у 3-4 и обломался. rndc flush и наверное заработает, пока снова не попытается сходить на не удачный NS rndc flush, конечно, пробовал - не помогает. (хотя в других случаях бывало да, помогало на некторое время). Почему же тот же гугл в итоге все таки отдает запись. Неужели они в кеше храняят последнюю удачную запись? Я как-то тоже брал и делал для таких вот случаев "временно", чтобы клиенты не сожрали - зону и записи прямо у себя на серве прописывал. Правда это очень не красивый вариант. Вот думаю написать администрации того ресурса про некорректность их записей. Но могут и послать, а скорее проигнорят. Ведь у остальных типа работает.... Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
man781 Posted August 5, 2014 · Report post Так что в итоге посоветуете оптимально в таких случаях? а) Писать каждый раз таким ресурсам? (геморрой, да и просто проигнорят в 0,9 случаях ) б) Что говорить клиентам? Они то видят, что у других провайдеров работает - значит наш сервис (ISP) "плохой". в) Что-то еще сделать, чтобы у меня тоже работало ? г) Почему у других провайдеров данный ресурс работает?! :) Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
g3fox Posted August 5, 2014 · Report post Как костыльный но рабочий вариант можете завести себе эту зону с типом forward и как forwarders указать "рабочие" NS-серверы. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
No_name Posted August 5, 2014 · Report post 2 man781 Да, тоже бывали такие ситуации, редко, но бывали. Помогало кратковременное включение форвардинга на гугловский днс. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
st_re Posted August 5, 2014 · Report post Посмотрел по логам. Мои на li.ru ходят. Ошибок ресолва нет. unbound. на тестовом бинде первые полсотни запросов разным *.li.ru без ошибок. бинд правда 9.9.3-P1 и люди у него не спрашивают, только роботы. Я бы снял трафик к ns*.li.ru тисипидампом и сделал параллельно rbdc flush и посмотрел че там спрашивается и че отвечается. что то кеш отравляет. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Ivan_83 Posted August 6, 2014 · Report post Мой ну очень тупой резолвер. REQUESTING DNS record for www.li.ru Results: founded: 18 records, request time: 0 DNS head: Size =557 ID =29218 Flags =[QR=1, OPCODE=0, AA=0, TC=0, RD=0, RA=0, Z=0, AD=0, CD=0, RCODE=0] QDCount=1 ANCount=0 NSCount=7 ARCount=11 Win32 DNS error 0: Операция успешно завершена. Server: RU, Type=2 (NS), Class=1, TTL=172800, server: A.DNS.RIPN.NET Server: RU, Type=2 (NS), Class=1, TTL=172800, server: B.DNS.RIPN.NET Server: RU, Type=2 (NS), Class=1, TTL=172800, server: D.DNS.RIPN.NET Server: RU, Type=2 (NS), Class=1, TTL=172800, server: E.DNS.RIPN.NET Server: RU, Type=2 (NS), Class=1, TTL=172800, server: F.DNS.RIPN.NET Server: RU, Type=43 (DS), Class=1, TTL=86400 Server: RU, Type=46 (RRSIG), Class=1, TTL=86400 Server: A.DNS.RIPN.NET, Type=1 (A), Class=1, TTL=172800, address: 193.232.128.6 Server: B.DNS.RIPN.NET, Type=1 (A), Class=1, TTL=172800, address: 194.85.252.62 Server: D.DNS.RIPN.NET, Type=1 (A), Class=1, TTL=172800, address: 194.190.124.17 Server: E.DNS.RIPN.NET, Type=1 (A), Class=1, TTL=172800, address: 193.232.142.17 Server: F.DNS.RIPN.NET, Type=1 (A), Class=1, TTL=172800, address: 193.232.156.17 Server: A.DNS.RIPN.NET, Type=28 (AAAA), Class=1, TTL=172800, address: 2001.678.17.0.193.232.128.6 Server: B.DNS.RIPN.NET, Type=28 (AAAA), Class=1, TTL=172800, address: 2001.678.16.0.194.85.252.62 Server: D.DNS.RIPN.NET, Type=28 (AAAA), Class=1, TTL=172800, address: 2001.678.18.0.194.190.124.17 Server: E.DNS.RIPN.NET, Type=28 (AAAA), Class=1, TTL=172800, address: 2001.678.15.0.193.232.142.17 Server: F.DNS.RIPN.NET, Type=28 (AAAA), Class=1, TTL=172800, address: 2001.678.14.0.193.232.156.17 OPT_RR: UDPPayloadSize=1472, Flags= [DO=0], Version=192, ExRCode=5, RRDataSize=0 Results: founded: 9 records, request time: 0 DNS head: Size =592 ID =29296 Flags =[QR=1, OPCODE=0, AA=0, TC=0, RD=0, RA=0, Z=0, AD=0, CD=0, RCODE=0] QDCount=1 ANCount=0 NSCount=6 ARCount=3 Win32 DNS error 0: Операция успешно завершена. Server: LI.RU, Type=2 (NS), Class=1, TTL=345600, server: NS2.LI.RU Server: LI.RU, Type=2 (NS), Class=1, TTL=345600, server: NS.LI.RU Server: TDUI9D4JKUDS8B9T86GJ39PGFLCNLGM5.RU, Type=50 (NSEC3), Class=1, TTL=3600 Server: TDUI9D4JKUDS8B9T86GJ39PGFLCNLGM5.RU, Type=46 (RRSIG), Class=1, TTL=3600 Server: 7B5GUVQHTTCFNM68PQO7ERLE3LG9JPBG.RU, Type=50 (NSEC3), Class=1, TTL=3600 Server: 7B5GUVQHTTCFNM68PQO7ERLE3LG9JPBG.RU, Type=46 (RRSIG), Class=1, TTL=3600 Server: NS.LI.RU, Type=1 (A), Class=1, TTL=345600, address: 88.212.202.56 Server: NS2.LI.RU, Type=1 (A), Class=1, TTL=345600, address: 88.212.196.87 OPT_RR: UDPPayloadSize=4096, Flags= [DO=0], Version=0, ExRCode=16, RRDataSize=0 REQUEST COMPLETE, FOUND, results: hops: 3, total time: 62 DNS head: Size =70 ID =29297 Flags =[QR=1, OPCODE=0, AA=1, TC=0, RD=0, RA=0, Z=0, AD=0, CD=0, RCODE=0] QDCount=1 ANCount=2 NSCount=0 ARCount=1 Win32 DNS error 0: Операция успешно завершена. Server: WWW.LI.RU, Type=1 (A), Class=1, TTL=900, address: 88.212.196.87 Server: WWW.LI.RU, Type=1 (A), Class=1, TTL=900, address: 88.212.196.88 OPT_RR: UDPPayloadSize=4096, Flags= [DO=0], Version=0, ExRCode=16, RRDataSize=0 ================================================================================== REQUEST COMPLETE, FOUND, results: hops: 3, total time: 62 Server: WWW.LI.RU, Type=1 (A), Class=1, TTL=900, address: 88.212.196.87 Server: WWW.LI.RU, Type=1 (A), Class=1, TTL=900, address: 88.212.196.88 ================================================================================== DONE Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
man781 Posted August 6, 2014 · Report post 2 man781 Да, тоже бывали такие ситуации, редко, но бывали. Помогало кратковременное включение форвардинга на гугловский днс. Действительно помогло Как костыльный но рабочий вариант можете завести себе эту зону с типом forward и как forwarders указать "рабочие" NS-серверы. Да - такой вариант оставлял на крайний случай, тем более и раньше его успешно использовал Но не понадобилось - я написал письмо администрации ресурса. Они подправили у себя. Теперь у меня все резолвится корректно. Всем спасибо за отклик. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
ipaddr.ru Posted August 6, 2014 · Report post ура. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
man781 Posted August 9, 2014 · Report post Еще тогда по теме dns два вопросика 1) Кто использует у себя на площадке решение от skydns (типа родительский контроль, автообновление базы категорий, интеграция с биллингом)? Мы вот давно юзаем. Все работает. Юзеры сами себе в кабинете выбирают белые/черные списки, категории. Возник вопрос - на данный момент схема работает только с одним DNS сервером. Вот по такой инструкции http://www.lanbilling.ru/sky_dns - юзеры шлют запросы, слушает их скайднс прокси на IP адресе физического фейса, "фильтрует" и резолвит запрос через 127.0.0.1, где уже bind слушает) Хотелось бы узнать - кто-нить делал все тоже самое (имею ввиду решение скай днс прокси) но с использованием двух серверов (для горячего резерва)? 2) Насколько критично, когда я своим юзерам передаю (with DHCP) всего один DNS сервер? Ходят байки, что какие-то девайсы неадекватно работают, когда нет секондари днс (типа = 0.0.0.0) Либо вообще не работают, пока руками не впишешь, и люди всякую хрень туда вбивают. 3) Насколько важно для каких-либо служб/сервисов, чтобы корректно резолвился IP адрес фейса в имя, (имеется ввиду IP адрес - на котором висит мой днс сервер (ессно - сервак имеет белый адрес и держит реальную зону (не локальный фейк)). Но вот не имеет PTR записи - потому IP адрес не мой, а вышестоящего провайдера. Нужно ли его просить прописать обратку или это нафиг особо не нужно? Заранее благодарен за ответы. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
ayf Posted August 10, 2014 · Report post Еще тогда по теме dns два вопросика 1) Кто использует у себя на площадке решение от skydns (типа родительский контроль, автообновление базы категорий, интеграция с биллингом)? Мы вот давно юзаем. Все работает. Юзеры сами себе в кабинете выбирают белые/черные списки, категории. Возник вопрос - на данный момент схема работает только с одним DNS сервером. Вот по такой инструкции http://www.lanbilling.ru/sky_dns - юзеры шлют запросы, слушает их скайднс прокси на IP адресе физического фейса, "фильтрует" и резолвит запрос через 127.0.0.1, где уже bind слушает) Хотелось бы узнать - кто-нить делал все тоже самое (имею ввиду решение скай днс прокси) но с использованием двух серверов (для горячего резерва)? 2) Насколько критично, когда я своим юзерам передаю (with DHCP) всего один DNS сервер? Ходят байки, что какие-то девайсы неадекватно работают, когда нет секондари днс (типа = 0.0.0.0) Либо вообще не работают, пока руками не впишешь, и люди всякую хрень туда вбивают. 3) Насколько важно для каких-либо служб/сервисов, чтобы корректно резолвился IP адрес фейса в имя, (имеется ввиду IP адрес - на котором висит мой днс сервер (ессно - сервак имеет белый адрес и держит реальную зону (не локальный фейк)). Но вот не имеет PTR записи - потому IP адрес не мой, а вышестоящего провайдера. Нужно ли его просить прописать обратку или это нафиг особо не нужно? Заранее благодарен за ответы. Некритично. Если бы проблема была, вас бы уже нашли. Никто не мешает клиенту адрес получать по DHCP, а DNS прописать руками. Если, конечно, вы все запросы на 53 порт не редиректите на свой днс. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
man781 Posted August 10, 2014 · Report post спасибо за ответы Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
man781 Posted September 14, 2014 · Report post Заметил, если пропадает инет - то если глянуть rndc status на моем DNS сервере (bind9) - к-во запросов в секунду взлетает под плеху (т.е. сколько в конфиге разрешено, столько и фигачит). recursive clients: 1000/0/1000 Хотя обычно не более 200 в сек. Такое ощущение, что возникает рекурсия к самому себе. Кто-нить знает, в чем фишка? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
GrandPr1de Posted September 14, 2014 · Report post Поидее в таймаутах. Когда ответы клиентам нормально отдаются - то и нагрузка идет средняя, а когда запросы всё идут, а ответов нету. У меня анбаунд тоже с ума сходит если есть прерывание инета. Готов весь проц сожрать в тот момент. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
man781 Posted September 14, 2014 · Report post Вполне логичное объяснение. Спасибо. Вот подкрутил для прикола в конфиге байнда вместо 1000 - 20000 максимально разрешенных рекурсивных запросов в секунду изнутри своей сети. Сэмулировал "отключение Инета" - моментально в 20000 уперлось. Просто суть такая, что когда связь с "вышестоящими" днс серверами поршивая - эта хрень мгновенно подскакивает, а отпускает медленней. Вроде даже один раз пришлось руками перезапустить - чтобы из клинча вывести... А кто в курсе - можно ли в качестве forwarders прописать гуглосервера 8.8.8.8 и 8.8.4.4 с средней нагрузкой в 200 запросов в секунду от моего днс сервера (нерекурсивные запросы)? (а то были проблемки с корневыми серверами, которые я описывал в начале темы, когда "частично некорректные" домены не резолвились, а вот с гуглосерверами таких проблем почему-то не было на тех же самых доменах в то же самое время) Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
GrandPr1de Posted September 14, 2014 · Report post Да можно и на руках ходить. можно ли в качестве forwarders прописать гуглосервера 8.8.8.8 и 8.8.4.4 Да только смысл? Выдайте сразу клиентским компам гуглоднсы. Просто делать рекурсию на рекурсивный днс, это как нат за натом. Сделать можно - смысла\толку мало. Мой анбаунд общаеться с корневыми и бед я не знаю. Зачем вам бинд, кстати говоря? Он у вас домен обслуживает? Я лично с бинда ушел на анбаунд ибо начались таймауты с ответами, анбаунд у меня таким не балуеться. :) Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
man781 Posted September 15, 2014 · Report post Байнд мне нужен, потому что я зону свою держу. Это раз. Второе - есть самописный костыль, который периодически определяет нагрузку на впн тазиках и рулит записями днс в моей зоне - для распределения нагрузки. (имя днс одно - тазиков VPN много). И еще не могу отдать юзерам сразу гуглоднс - потому что юзаю днс фильтрацию (услуга типа родительский контроль). Вообще, я пробовал в свое время unbound - очень понравился (конфигурирование). Но тогда он не умел ротацию (позже добавили) - если одно имя имеет много ипов, то всегда выдавал одинаковый список без ротации. Это плохо для распределения нагрузки впн серверов - клиент всегда использовал первый адрес в списке. P.S. Понятно, что нужно уходит от тазиков с VPN - на IPoE BRAS. ну так все таки - кто-нить прописывал в качестве forwarders 8.8.8.8 и 8.8.4.4 ? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
GrandPr1de Posted September 15, 2014 · Report post Да я пробовал так делать, работает. Если вы уже уверелись, что хотите так сделать - то работать будет. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
man781 Posted September 15, 2014 · Report post Я тоже пробовал. Не долго. Работает. Но может если на постоянку врубить - через какое-то время начнут дропать? (через неделю, месяц) Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
GrandPr1de Posted September 15, 2014 · Report post Вроде не должны. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
man781 Posted September 15, 2014 · Report post Значит совпало - пару недель поработало, потом "что-то пошло не так", некогда было разбираться - убрал forwarders, снова корневые днс серверы юзаются. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Ivan_83 Posted September 15, 2014 · Report post Им не выгодно дропать. 8.8.8.8 и его брат подняты ради того чтобы гугл оперативно узнавал об новых доменах и трендах вреди пользователей, даже таких, кто кто гугль не переносит и старательно блочит всего сервисы у себя. Поэтому плох тот провайдер, который не держит собственный рекурсивный днс с кешем а сливает всё левым конторам. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
man781 Posted January 19, 2015 · Report post Вообщем, после очередной жалобы юзера: мол, такой-то сайт не резолвится, а если гугл днс прописать - все ок, решил таки я уйти от bind9 на unbound. На unbound внезапно нормально резолвится проблемный сайтик. Но вот столкнулся я с тем, что в unbound не работает запись для retracker.local в частности и вообще CNAME запись из "чужого" домена. Как я не крутил варианты полдня. Может кто показать кусок примера конфига unbound для вышеописанных случаев? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...