Re: Что не так в DNS в Debian buster

[Anatoly Pugachev]

On Mon, May 17, 2021 at 4:42 PM Maksim Dmitrichenko  wrote:
>
> Спасибо, Сергей, за реакцию. Но у меня на нескольких компах с buster одно и 
> то же: /etc/resolv.conf - это не ссылка на какой-то там файл, а 
> сгенерированный NN'ом фалик. Я так понимаю, что при переходе с девятки на 
> десятку отключили у NM логику использования dnsmasq. systemd-resolved хоть и 
> запускается сейчас и висит на 53-м порту на локальном IP-шнике, как понимаю, 
> никем не используется, потому что /etc/resolv.conf про него вообще ничего не 
> знает. /me как-то не понимает как можно было такой дефолт запилить (все компы 
> ставились с нуля без upgrade).
>
> Таким образом, получается, что неизбежать танцев с бубном по редактированию 
> конфигов NM, что при апгрейде на 11-й выпуск, прилетит бумерангом скорее 
> всего.

Максим, да какие "танцы с бубном" то? Если комп один, то на нем можно
и руками один раз настроить, как вам уже порекомендовал Сергей. Если
компов много, то тут ansible вам сильно поможет настроить оставшиеся
компы по аналогии с первым настроенным, единственное playbook все-таки
придется написать и протестировать на том же первом/локальном компе.

Re: Что не так в DNS в Debian buster

[Maksim Dmitrichenko]

Спасибо, Сергей, за реакцию. Но у меня на нескольких компах с buster одно и
то же: /etc/resolv.conf - это не ссылка на какой-то там файл, а
сгенерированный NN'ом фалик. Я так понимаю, что при переходе с девятки на
десятку отключили у NM логику использования dnsmasq. systemd-resolved хоть
и запускается сейчас и висит на 53-м порту на локальном IP-шнике, как
понимаю, никем не используется, потому что /etc/resolv.conf про него вообще
ничего не знает. /me как-то не понимает как можно было такой дефолт
запилить (все компы ставились с нуля без upgrade).

Таким образом, получается, что неизбежать танцев с бубном по редактированию
конфигов NM, что при апгрейде на 11-й выпуск, прилетит бумерангом скорее
всего.

пн, 17 мая 2021 г. в 16:32, Sergey Spiridonov :

> On Fri, 14 May 2021 16:16:40 +0300
> Maksim Dmitrichenko  wrote:
>
> > Я знаю, что я слоупок, но не так давно обновился до buster и немного
> > не понимаю, что у меня теперь происходит с DNS.
> >
> > Ранее (на девятке) у меня NetworkManager запускал dnsmasq и прописывал
> > локальный DNS сервер в /etc/resolv.conf - при этом можно было удобно
> > настроить, что при подключении к рабочему VPN, в рабочий DNS сервер
> > улетали только запросы от dnsmasq, касающиеся резолва ресурсов в
> > рабочей сетке. NetworkManager управлял dnsmasq на лету по мере
> > подключения/отключения новых соединений.
> >
> > Теперь же я вижу, что локально (на 127.0.0.53 почему-то) запущен
> > systemd-resolved. dnsmasq - не запущен вообще, в /etc/resolv.conf
> > каждый раз при отключении/подключении VPN пишет NetworkManager, а все
> > программы, пытаясь резолвить ресурсы, доступные по VPN, отправляют в
> > половине случаев свои запросы к серверу провайдера и, получая отлуп,
> > говорят, что no such address.
> >
> > Я, конечно, могу влезть в /etc/NetworkManager/NetworkManager.conf,
> > задизаблить systemd-resolved и так далее, но почему такой неработающий
> > идиотизм сделан по дефолту? Может надо какие-то хитрые пакеты
> > установить или снести, чтобы всё вернулось в прямой вид?
> >
>
> Привет, боролся с этой проблемой с переменным успехом на Дебине, Убунте
> и Федоре.
>
> Если ты согласен жить с системд-резолвед (не всегда это возможно), то
> решение простое:
>
> необходимо добавить в конфигурацию сервера
>
> push "dhcp-option DOMAIN rabochaya.setka.com"
>
> системд-резолвед и НМ достаточно умны, чтобы перенаправлять ДНС запросы
> после этого в ДНС от рабочей сетки (который тоже должен пушиться).
>
> При этом на клиенте в НМ должна быть включена опция "Use this
> connection only for resources on its network"
>
>
> Если настройки сервера ты поменять не можешь, то должно помочь на
> клиенте
>
>  sudo nmcli connection modify rabochiy-vpn ipv4.dns-search
> rabochaya.setka.com
>
>
> Если же непременно необходимо использовать днсмаск, то инструкция
> такая (не стал переводить с английского)
>
>
> Install dnsmasq
>
> sudo apt install dnsmasq
>
> Disable systemd-resolved listener on port 53 (do not
> touch /etc/systemd/resolved.conf, because it may be overwritten on
> upgrade):
>
> $ cat /etc/systemd/resolved.conf.d/noresolved.conf
> [Resolve]
> DNSStubListener=no
>
> and restart it
>
> $ sudo systemctl restart systemd-resolved
>
> (alternatively disable it completely by $ sudo systemctl disable
> systemd-resolved.service)
>
> Delete /etc/resolv.conf and create again. This is important, because
> resolv.conf is a symbolic link to /run/systemd/resolve/stub-resolv.conf
> by default. If you will not delete symbolic link, the file will be
> overwritten by systemd on reboot (even though we disabled
> systemd-resolved!). Also NetworkManager (NM) checks if it is a symbolic
> link to detect systemd-resolved configuration.
>
> $ sudo rm /etc/resolv.conf
> $ sudo touch /etc/resolv.conf
>
> Disable overwriting of /etc/resolv.conf by NM (there is also an option
> rc-manager, but it does not work, despite it is described in a manual):
>
> $ cat /etc/NetworkManager/conf.d/disableresolv.conf
> [main]
> dns=none
>
> and restart it:
>
> $ sudo systemctl restart NetworkManager
>
> Tell dnsmasq to use resolv.conf from NM:
>
> $ cat /etc/dnsmasq.d/nmresolv.conf
> resolv-file=/var/run/NetworkManager/resolv.conf
>
> Резолвинг рабочей сетки, например так
>
> cat /etc/dnsmasq.d/rabsetka
> server=/rabochaya.setka.com/<айпи днс сервера в рабочей сетке>
>
> and restart it:
>
> $ sudo systemctl restart dnsmasq
>
> Use dnsmasq for resolving:
>
> $ cat /etc/resolv.conf
> # Use local dnsmasq for resolving
> nameserver 127.0.0.1
>
> Публиковал для Убунты здесь
>
>
> https://askubuntu.com/questions/898605/how-to-disable-systemd-resolved-and-resolve-dns-with-dnsmasq
> --
> С уважением, Сергей Спиридонов
>


-- 
With best regards
  Maksim Dmitrichenko

Что не так в DNS в Debian buster

[Maksim Dmitrichenko]

Я знаю, что я слоупок, но не так давно обновился до buster и немного не
понимаю, что у меня теперь происходит с DNS.

Ранее (на девятке) у меня NetworkManager запускал dnsmasq и прописывал
локальный DNS сервер в /etc/resolv.conf - при этом можно было удобно
настроить, что при подключении к рабочему VPN, в рабочий DNS сервер улетали
только запросы от dnsmasq, касающиеся резолва ресурсов в рабочей сетке.
NetworkManager управлял dnsmasq на лету по мере подключения/отключения
новых соединений.

Теперь же я вижу, что локально (на 127.0.0.53 почему-то) запущен
systemd-resolved. dnsmasq - не запущен вообще, в /etc/resolv.conf каждый
раз при отключении/подключении VPN пишет NetworkManager, а все программы,
пытаясь резолвить ресурсы, доступные по VPN, отправляют в половине случаев
свои запросы к серверу провайдера и, получая отлуп, говорят, что no such
address.

Я, конечно, могу влезть в /etc/NetworkManager/NetworkManager.conf,
задизаблить systemd-resolved и так далее, но почему такой неработающий
идиотизм сделан по дефолту? Может надо какие-то хитрые пакеты установить
или снести, чтобы всё вернулось в прямой вид?

-- 
With best regards
  Maksim Dmitrichenko

CUPS mDNS/DNS-SD discovery

[sergio]

Хочу принтер автомагически обнаружеваемый по сети.


Поставил на сервере CUSP, avahi-daemon. На клиенте поставил только
avahi-daemon. Мозилла печатает!


Теперь десятая венда. Она шлёт mdns запрос, avahi ей отвечает, ответ
приходит венде, но принтер она не показывает. Ручками добавляешь, всё
работает. НО! если принтер подключить по сети, то венда сама обнаружит
два устройства, сам принтер и принтер капса. Но при этом, у этого
принтера, подключенного к капсу "локейшн" будет
http://printerIP:8018/wsd и венда печатает напрямую на принтер, а не на
капс. Пробовал добавить в обычный DNS записи, венда их спрашивает,
безрезультатно:

_ipp._tcp   PTR cups
cupsA 
cupsSRV 0 0 631 cups
cupsTXT (
"txtvers=1"
"qtotl=1"
"rp=printers/printer"
"adminurl=ipp://cups/printers/printer"
"ty=Samsung ML-2160 series"
"pdl=application/octet-stream,application/pdf, 
application/postscript,image/jpeg ,image/png,image/urf"
"URF=none" )


Штатный принт сервис андроида 8.1 и "Android CUPS Print" шлют mdns
запросы, получают ответы от авахи, но принтер не обнаруживают, даже
сетевой.


И ещё, можно ли на линуксе получить lpr который будет автоматически
обнаруживать CUPS? (Сейчас, что бы lpr на клиенте работал, нужно
поставить cups-bsd и прописать ServerName в /etc/cups/client.conf)

-- 
sergio

Re: VPN и корпоративный DNS

[Artem Chuprina]

Max Dmitrichenko -> Debian Russian Mailing List  @ Sat, 18 Mar 2017 22:43:58 
+0300:

 >> ... до тех пор, пока не выяснится, что VPN с работы пропихивает свои NS
 >> как дефолтные (а вовсе не для своих доменов), да и роутинг на три сетки
 >> из тех полутора десятков, что он выставляет, выставлять ни в коем случае
 >> не надо. Для чего таки приходится лезть в коннект-скрипт.
 >>

 > ИМХО, зачастую проще подойти к админу на работе и сказать, что делать так
 > не хорошо )

Любая задача имеет красивое, простое и очевидное неправильное
решение. Он не умеет по-другому.

Re: VPN и корпоративный DNS

[Max Dmitrichenko]

18 марта 2017 г., 19:15 пользователь Artem Chuprina 
написал:

> Max Dmitrichenko -> debian-russian@lists.debian.org  @ Sat, 18 Mar 2017
> 15:56:41 +0300:
>

> ... до тех пор, пока не выяснится, что VPN с работы пропихивает свои NS
> как дефолтные (а вовсе не для своих доменов), да и роутинг на три сетки
> из тех полутора десятков, что он выставляет, выставлять ни в коем случае
> не надо. Для чего таки приходится лезть в коннект-скрипт.
>

ИМХО, зачастую проще подойти к админу на работе и сказать, что делать так
не хорошо )

-- 
With best regards
  Max Dmitrichenko

Re: VPN и корпоративный DNS

[Artem Chuprina]

Max Dmitrichenko -> debian-russian@lists.debian.org  @ Sat, 18 Mar 2017 
15:56:41 +0300:

 >> Это совершенно необязательно. Вообще dnsmasq умеет прекрасно
 >> взаимодействовать с resolvconf-ом и получать от него адреса основных
 >> DNS-серверов. Хотя вот утверждать что появление в этой компании еще и
 >> networkmanager не приведет к какому-нибудь непониманию не возьмусь.
 >>

 > А я берусь утверждать, что в этой компании это будет кучей малой. Если его
 > не снести, то происходит следующее:
 > 1) NM записывает в /etc/resolv.conf 127.0.0.1 и запускает dnsmasq
 > 2) Изменение состояния любого интерфеса вызыает цепочку скриптов
 > /etc/network/if-*.d , среди которых есть скрипт resolvconf
 > 3) resolvconf перезаписывает /etc/resolv.conf, dnsmasq после этого курит в
 > сторонке.

А почему он у меня так не делает? В смысле, resolvconf в курсе о
существовании dnsmasq и прочих кэширующих неймсерверов. Или наоборот,
они о нем в курсе.

А вот NM у меня отсутствует. Видимо, он-то и вмешивается в ситуацию...

 > Кроме того, я не очень представляю себе механизм, которым resolvconf мог бы
 > накормить dnsmasq инфой для сплита, то есть помимо самого nameserver'а,
 > скормить префиксы и локальные домены.

resolvconf не может.

 >> Гораздо интереснее написать такой connect-script для openvpn, чтобы
 >> подключал корпоративные DNS-ы для каких надо доменов при поднятии vpn,
 >> а при опускании - убирал.
 >>

 > Интереснее делать то, что уже до вас сделано и работает путем добавления
 > одной строчки в конфиг?

... до тех пор, пока не выяснится, что VPN с работы пропихивает свои NS
как дефолтные (а вовсе не для своих доменов), да и роутинг на три сетки
из тех полутора десятков, что он выставляет, выставлять ни в коем случае
не надо. Для чего таки приходится лезть в коннект-скрипт.

Re: VPN и корпоративный DNS

[Victor Wagner]

On Sat, 18 Mar 2017 15:56:41 +0300
Max Dmitrichenko <dmitr...@gmail.com> wrote:

> 18 марта 2017 г., 15:17 пользователь Victor Wagner
> <vi...@wagner.pp.ru> написал:
> 
> 
> > Это совершенно необязательно. Вообще dnsmasq умеет прекрасно
> > взаимодействовать с resolvconf-ом и получать от него адреса основных
> > DNS-серверов. Хотя вот утверждать что появление в этой компании еще
> > и networkmanager не приведет к какому-нибудь непониманию не
> > возьмусь. 
> 
> А я берусь утверждать, что в этой компании это будет кучей малой.
> Если его не снести, то происходит следующее:
> 1) NM записывает в /etc/resolv.conf 127.0.0.1 и запускает dnsmasq
> 2) Изменение состояния любого интерфеса вызыает цепочку скриптов
> /etc/network/if-*.d , среди которых есть скрипт resolvconf

На интерфейсы openvpn это обычно не распространяется.

> 3) resolvconf перезаписывает /etc/resolv.conf, dnsmasq после этого
> курит в сторонке.

Так надо resolvconf настроить, чтобы не забывал прописать 127.0.0.1 в
перезаписываемый resolv.conf.

 
> 
> Интереснее делать то, что уже до вас сделано и работает путем
> добавления одной строчки в конфиг?

Когда работает - хорошо. А когда не работает - становится очень плохо
потому что nm в качестве коннект-скрипта подставляет openvpn бинарник.
И чтобы подправить его на коленке нужно по крайней мере скачать
исходник пакета. А потребность  в этом обычно возникет когда ты сидишь
в глухом лесу, с неба капает вода, а gprs еле теплится.

Поэтому я предпочитаю такие решения, которые можно прочитать и
ПРЕДСТАВЛЯТЬ СЕБЕ как они работают.  

Более того, прочитав хорошее решение начинаешь лучше представлять себе
как устроен мир.

Я когда увидел что NM работает с OpenVPN позволяя ее поднимать опускать
простому пользователю,  я подумал "как классно", надо все свои vpn
перевести на это. Но тут выяснилось что оно не умеет использвоать
готовые конфиги клиента openvpn предоставленные администратором сети,
надо настраивать через меню, а в меню, естественно предусмотрено только
процентов 10 из возможных опций конфигурации openvpn.

И в итоге пришлось отказаться от использования NM для этой цели и
запускать openvpn через старую добрую дебиановскую систему
инит-скриптов. Которую достаточно аккуратно подправили для
совместимости с systemd.


> 
> Интересное обычно побеждает лень, стало быть неинтересно )
> 
У меня как-то других дел хватает. Проще на рабочей машине веб-прокси
поднять, и не зависеть от того, насколько сисадмин корректно настроил
DNS в VPN-сегменте - из офиса-то все резолвится правильно.

Re: VPN и корпоративный DNS

[Max Dmitrichenko]

18 марта 2017 г., 15:17 пользователь Victor Wagner <vi...@wagner.pp.ru>
написал:


> Это совершенно необязательно. Вообще dnsmasq умеет прекрасно
> взаимодействовать с resolvconf-ом и получать от него адреса основных
> DNS-серверов. Хотя вот утверждать что появление в этой компании еще и
> networkmanager не приведет к какому-нибудь непониманию не возьмусь.
>

А я берусь утверждать, что в этой компании это будет кучей малой. Если его
не снести, то происходит следующее:
1) NM записывает в /etc/resolv.conf 127.0.0.1 и запускает dnsmasq
2) Изменение состояния любого интерфеса вызыает цепочку скриптов
/etc/network/if-*.d , среди которых есть скрипт resolvconf
3) resolvconf перезаписывает /etc/resolv.conf, dnsmasq после этого курит в
сторонке.

Кроме того, я не очень представляю себе механизм, которым resolvconf мог бы
накормить dnsmasq инфой для сплита, то есть помимо самого nameserver'а,
скормить префиксы и локальные домены.


> Гораздо интереснее написать такой connect-script для openvpn, чтобы
> подключал корпоративные DNS-ы для каких надо доменов при поднятии vpn,
> а при опускании - убирал.
>

Интереснее делать то, что уже до вас сделано и работает путем добавления
одной строчки в конфиг?

Хотя если вы из лагера nm-хейтеров, то в этом случае да, придется
пофантазировать.


> Мне это как-то все лениво сделать.
>

Интересное обычно побеждает лень, стало быть неинтересно )

-- 
With best regards
  Max Dmitrichenko

Re: VPN и корпоративный DNS

[Victor Wagner]

On Sat, 18 Mar 2017 12:54:32 +0300
Max Dmitrichenko <dmitr...@gmail.com> wrote:

> Сам себе в итоге отвечаю, решение нашел давно, но только сейчас руки
> дошли отписать.
> 
> 1) Надо снести пакет resolvconf, если он есть.

Это совершенно необязательно. Вообще dnsmasq умеет прекрасно
взаимодействовать с resolvconf-ом и получать от него адреса основных 
DNS-серверов. Хотя вот утверждать что появление в этой компании еще и
networkmanager не приведет к какому-нибудь непониманию не возьмусь.

Гораздо интереснее написать такой connect-script для openvpn, чтобы
подключал корпоративные DNS-ы для каких надо доменов при поднятии vpn,
а при опускании - убирал.

Мне это как-то все лениво сделать.

в

Re: VPN и корпоративный DNS

[Max Dmitrichenko]

Сам себе в итоге отвечаю, решение нашел давно, но только сейчас руки дошли
отписать.

1) Надо снести пакет resolvconf, если он есть.
2) В /etc/NetworkManager/NetworkManager.conf в секцию [main] добавляем
dns=dnsmasq. Это режим как раз запускает dnsmasq и сплитит запросы.

12 июля 2016 г., 1:28 пользователь Max Dmitrichenko <dmitr...@gmail.com>
написал:

> Всем привет!
>
> Есть корпоративная сеть, куда юзер коннектится через OpenVPN. У юзера
> линукс. По dhcp он получает корпоративный DNS сервер, который либо
> умеет резолвить только корпоративные адреса, либо умеет и
> интернет-адреса, но это крайне не желательно.
>
> Возможно ли юзеру каким-то образом сконфигурить у себя резолвер так,
> чтобы за корпоративными адресами (по домену, например) он лез к
> корпоративному DNS-серверу, а за всеми остальными к DNS'у провайдера?
>
> --
> With best regards
>   Max Dmitrichenko
>



-- 
With best regards
  Max Dmitrichenko

Re: Тестирование DNS в lxc контейнере.

[Andrey Melnikoff]

Victor Wagner  wrote:
> On Mon, 05 Sep 2016 20:18:00 +0300
> Oleksandr Gavenko  wrote:

> > On 2016-09-05, Иван Лох wrote:
> > 
> > > В системе i386 и ядром amd64 уже ставится и работает?  
> > 
> > Чем такая конфигурация привлекательна?
> > 
> > Вендоры не поставляют 32-bit драйверов и хочется сэкономить на RAM в
> > офисных компьютерах?
> > 

> Дебиан не предоставляет процедуры crossgrade с i386 на amd64 с
> сохранением всей конфигурациии системы.

Вполне себе позволяет. Сам уже несколько машин проапгрейдил.

Re: Тестирование DNS в lxc контейнере.

[Иван Лох]

On Tue, Sep 06, 2016 at 10:45:32AM +0300, Eugene Berdnikov wrote:
> > Но независимо от того чем эта конфигурация привлекательна, она штатная
> > и kvm работает из коробки, также как и другие программы. В отличии
> > от VirtualBox. 
> 
>  В каком смысле, 64-битный VirtualBox не запускается в 32-битной
>  системе под 64-битным ядром, у которого все виртуалбоксовые
>  64-битные модули подгружены? 

Да

Re: Тестирование DNS в lxc контейнере.

[Михаил Касаджиков]

07.09.2016 16:16, Илья пишет:
>> В ГОСТ ещё применяется «ЭВМ» и «ПЭВМ», но сейчас многие
>> этих аббревиатур даже и не знают.
>> Зато в любой конторке разработчиков «деплоят» «билды»,
>> которые потом «фейлятся» и всё это нужно «инвестигировать»
>> и «фиксить». А также выдать «эстимейт» и «резолюшн». И
>> потом эти клоуны удивляются что в разговоре с ними
>> используют мат? Зато резко умнеют переходят на человеческий
>> язык.
>>
> 
> Ну про "в любой" это вы зря. Большинство разработчиков
> 1С, такую терминологию вряд ли используют :). 

Кстати, да. Это же вообще смешно! В англоговорящих странах разработчики
не стыдятся использовать в работе слова из своего обычного языка. Немцы,
кстати, как и французы, стараются термины переводить на свой язык, как
бы страшно это для остального мира не звучало. А вот русскоговорящие
своего языка стыдятся. А тех кто не стыдится — высмеивают.
Грустно это всё. О каком возрождении, или улучшении чего бы то ни было
вообще можно говорить с таким отношением к себе самим…

Re: Тестирование DNS в lxc контейнере.

[Илья]

В Wed, 7 Sep 2016 15:16:29 +0300
Михаил Касаджиков  пишет:

 
> В ГОСТ ещё применяется «ЭВМ» и «ПЭВМ», но сейчас многие
> этих аббревиатур даже и не знают.
> Зато в любой конторке разработчиков «деплоят» «билды»,
> которые потом «фейлятся» и всё это нужно «инвестигировать»
> и «фиксить». А также выдать «эстимейт» и «резолюшн». И
> потом эти клоуны удивляются что в разговоре с ними
> используют мат? Зато резко умнеют переходят на человеческий
> язык.
> 

Ну про "в любой" это вы зря. Большинство разработчиков
1С, такую терминологию вряд ли используют :). 

Дисциплиной по стандартам (в хорошем смысле) в РФ не
только разработчики страдают, что не всегда критично. Я
работал в одной юридической гос. "конторе" (99% юристов с
высшим образованием!!!), так они смогли в справочник
"Общероссийский классификатор организационно-правовых форм"
забить более тысячи единиц (хотя тогда в стандарте было 
не более 100) - включая такие формы, как "РАО ЕС" и "РАО
Железные дороги". А ГИБДД и Кадастровая служба не знают что
существует ОКТМО... теперь номеров не хватает. :)

Re: Тестирование DNS в lxc контейнере.

[Михаил Касаджиков]

07.09.2016 14:40, Илья пишет:
> В Wed, 7 Sep 2016 12:25:03 +0200
> Konstantin Matyukhin  пишет:
> 
>> Не впадайте в крайности. Одно дело дискета, а другое
>> какой-нибудь "драйвер слушателя локальной сети".
>> У врачей есть латынь неспроста, однако с пациентами на ней
>> никто не предлагает разговаривать.
> 
> Я что то не понял ход вашей мысли. Я сам призываю не впадать
> в крайности. Я хотел сказать, что я не знаю никаких
> правил по компьютерной терминологии. 
> 
> В СССР были вроде стандарты, где эти термины описаны. Их вроде
> даже не отменяли. Но кто то ими пользуется? Кстати, в ГОСТ
> 28273-89 применяют термин "ГМД", а не общепринятое "дискета". 
> 
> Повторюсь, но я думаю в рассылке не все активные члены
> международного сообщества Debian и тем более разработчики и
> требовать от них соблюдения терминологии разработчиков как то
> не правильно. Впрочем даже разработчик в одной области,
> может не знать "общепринятой" терминологии в другой. Зачем
> "бодаться" то из за ерунды? 

В ГОСТ ещё применяется «ЭВМ» и «ПЭВМ», но сейчас многие этих аббревиатур
даже и не знают.
Зато в любой конторке разработчиков «деплоят» «билды», которые потом
«фейлятся» и всё это нужно «инвестигировать» и «фиксить». А также выдать
«эстимейт» и «резолюшн». И потом эти клоуны удивляются что в разговоре с
ними используют мат? Зато резко умнеют переходят на человеческий язык.

Re: Тестирование DNS в lxc контейнере.

[Илья]

В Wed, 7 Sep 2016 12:25:03 +0200
Konstantin Matyukhin  пишет:

> Не впадайте в крайности. Одно дело дискета, а другое
> какой-нибудь "драйвер слушателя локальной сети".
> У врачей есть латынь неспроста, однако с пациентами на ней
> никто не предлагает разговаривать.

Я что то не понял ход вашей мысли. Я сам призываю не впадать
в крайности. Я хотел сказать, что я не знаю никаких
правил по компьютерной терминологии. 

В СССР были вроде стандарты, где эти термины описаны. Их вроде
даже не отменяли. Но кто то ими пользуется? Кстати, в ГОСТ
28273-89 применяют термин "ГМД", а не общепринятое "дискета". 

Повторюсь, но я думаю в рассылке не все активные члены
международного сообщества Debian и тем более разработчики и
требовать от них соблюдения терминологии разработчиков как то
не правильно. Впрочем даже разработчик в одной области,
может не знать "общепринятой" терминологии в другой. Зачем
"бодаться" то из за ерунды? 

Re: Тестирование DNS в lxc контейнере.

[Михаил Касаджиков]

07.09.2016 13:25, Konstantin Matyukhin пишет:
> Я не понимаю чем плохо в русскоязычной рассылке
> использовать русскоязычные термины? Даже если они не
> "общепринятые". И что такое "общепринятые", где и кем? Floppy
> disk, флоп, ГМД или дискета? Мне не понятно как найти правила выбора
> термина.
> 
> 
> Не впадайте в крайности. Одно дело дискета, а другое какой-нибудь "драйвер 
> слушателя локальной сети".
> У врачей есть латынь неспроста, однако с пациентами на ней никто не 
> предлагает разговаривать.

Однако, вряд ли они между собой в одной тусовке разговаривают полностью на 
латыни.

Re: Тестирование DNS в lxc контейнере.

[Михаил Касаджиков]

06.09.2016 21:16, Victor Wagner пишет:
>>>>> Естественно, среди этих моделей реальности нет той, которая
>>>>> наиболее удобна нормальным людям, умеющим думать и желающим
>>>>> понимать. Проприетарная софтина,  пусть и выпущенная под
>>>>> номинально открытой лицензией - она отучает людей думать.
>>>>
>>>> Как раз модель «на хосте с виртуалками есть своя виртуальная сеть
>>>> для них со своим DHCP и DNS» есть и прекрасно работает. Называется
>>>> «Тип подключения; сетевой мост». # brctl show lxcbr0 bridge name  
>>>
>>> А по-человечески можно? Без ублюдских NLS? Bridged networking или
>>> как? Я этого новояза в который превратили компьютерную технолоию
>>> переводчики, не разумею. В исходниках там сообщения на английском,
>>> вот давайте той терминологией и пользоваться.  
>>
>> А давайте без «давайте», хорошо? Я предпочитаю чтобы компьютер мне
>> рассказывал свои сказки на понятном МНЕ языке, там где не нужна
>> машиночитаемость. Вам нравится всё на английском? Хотите чтобы
> 
> Мне нравится однозначность. Сообщество разработчиков OpenSource -
> интернациональное. Поэтому хочешь не хочешь, общаться с людьми, которые
> способны что-то изменить, проиходится по-английски.

А теперь посмотрим на название рассылки…
В debian-user — английский язык.
В debian-russian — русский язык.

Опять же, я не против какого-то конкретного языка. Мне не нравится засирание 
одного языка терминами из другого, при наличии таких же по смыслу слов в 
засираемом языке. И не надо отмазываться жаргонами и прочей фигнёй — всё это не 
более чем выпендрёж. Как банковское «пролонгирование» вместо «продление», так и 
компьютерное «девелоперы» вместо «разработчики».

> По-русски, к сожалению, получается общаться только с носителями
> стокгольмского синдрома, которые защищают галимую проприетарщину
> и безграмотные переводы.

А вот мутные фантазии на политические и прочие подобные темы оставьте при себе. 
Не надо превращать техническую рассылку в очередной политосрач.

Re: Тестирование DNS в lxc контейнере.

[Konstantin Matyukhin]

>
> Я не понимаю чем плохо в русскоязычной рассылке
> использовать русскоязычные термины? Даже если они не
> "общепринятые". И что такое "общепринятые", где и кем? Floppy
> disk, флоп, ГМД или дискета? Мне не понятно как найти правила выбора
> термина.


Не впадайте в крайности. Одно дело дискета, а другое какой-нибудь "драйвер
слушателя локальной сети".
У врачей есть латынь неспроста, однако с пациентами на ней никто не
предлагает разговаривать.

-- 
С уважением,
Константин Матюхин

Re: Тестирование DNS в lxc контейнере.

[Илья]

В Tue, 6 Sep 2016 21:20:14 +0300
Victor Wagner  пишет:

> On Tue, 6 Sep 2016 17:47:48 +0300
> Михаил Касаджиков  wrote:
> 
> Поэтому либо вы пользуетесь общепринятой, а не местечковой
> терминологией, либо вас никто не понимает.


Я не понимаю чем плохо в русскоязычной рассылке
использовать русскоязычные термины? Даже если они не
"общепринятые". И что такое "общепринятые", где и кем? Floppy
disk, флоп, ГМД или дискета? Мне не понятно как найти правила выбора
термина. По мне,главное что бы было понятно описано,
хоть "та квадратная ё... фигня которая в дырку системника
засовывается ... на которой ты мне игру дал б...". По моему
мнению множество компьютерных терминов вообще скоро уйдет из
употребления.

Изучая французский я узнал, что у французов вроде
законодательно запрещено использовать иностранные термины. 
У них на каждый английский компьютерный термин свой. 
Это одна крайность, есть и другая, лексикон типа: компьютер, компьютерщик, 
компьютить, манагер и т.д. 

Re: Тестирование DNS в lxc контейнере.

[Victor Wagner]

On Tue, 6 Sep 2016 17:47:48 +0300
Михаил Касаджиков  wrote:

> А давайте без «давайте», хорошо? Я предпочитаю чтобы компьютер мне
> рассказывал свои сказки на понятном МНЕ языке, там где не нужна
> машиночитаемость. Вам нравится всё на английском? Хотите чтобы

Речь идет не о том, чтобы компьютер что-то вам рассказывал, а том, чтобы
вы рассказывали что-то другим людям, способным разобраться во
внутреннем устройстве программы. 

Сообщество OpenSource
интернационально, и его язык - английский.

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






-- 
   Victor Wagner 

Re: Тестирование DNS в lxc контейнере.

[Victor Wagner]

On Tue, 6 Sep 2016 17:47:48 +0300
Михаил Касаджиков <ha...@h13online.net> wrote:

> 06.09.2016 09:28, Victor Wagner пишет:
> >>> Естественно, среди этих моделей реальности нет той, которая
> >>> наиболее удобна нормальным людям, умеющим думать и желающим
> >>> понимать. Проприетарная софтина,  пусть и выпущенная под
> >>> номинально открытой лицензией - она отучает людей думать.
> >>
> >> Как раз модель «на хосте с виртуалками есть своя виртуальная сеть
> >> для них со своим DHCP и DNS» есть и прекрасно работает. Называется
> >> «Тип подключения; сетевой мост». # brctl show lxcbr0 bridge name  
> > 
> > А по-человечески можно? Без ублюдских NLS? Bridged networking или
> > как? Я этого новояза в который превратили компьютерную технолоию
> > переводчики, не разумею. В исходниках там сообщения на английском,
> > вот давайте той терминологией и пользоваться.  
> 
> А давайте без «давайте», хорошо? Я предпочитаю чтобы компьютер мне
> рассказывал свои сказки на понятном МНЕ языке, там где не нужна
> машиночитаемость. Вам нравится всё на английском? Хотите чтобы

Мне нравится однозначность. Сообщество разработчиков OpenSource -
интернациональное. Поэтому хочешь не хочешь, общаться с людьми, которые
способны что-то изменить, проиходится по-английски.

По-русски, к сожалению, получается общаться только с носителями
стокгольмского синдрома, которые защищают галимую проприетарщину
и безграмотные переводы.

Реч


> VirtualBox вам всё сообщал на английском языке? Да на здоровье! Но не
> надо навязывать своё «абсолютно верное» мнение другим людям.
> 
> > Судя по имени bridge в вашем примере это выглядит как "у virtual box
> > есть возможность прицепиться к уже существующему сетевому
> > интерфейсу, и мы ее используем, цепляясь к бриджу, созданному для
> > lxc-контейнеров".  
> 
> Да, именно так. Мне не нужна куча виртуальных сетей на рабочем компе
> и я решил оставить один вариант, создаваемый скриптом из пакета lxc.
> Не потому что там как-то запредельно круто это сделано, а потому что
> мне такой вариант удобнее. Всё, точка. Нет тут никаких высоченных
> материй.
> 
> > То есть это фактически признание "Virtual Box управлять сетью не
> > умеет, все надо делать руками, но слава богу, есть возможность
> > прицепиться к созданному руками".  
> 
> Нет, не так. И LXC, и libvirt, и VirtualBox могут полностью
> самостоятельно создавать виртуальные сети. Но мне не нужен весь этот
> зоопарк, поэтому я оставил один вариант. Неужели не понятно???
> 
> > У VMWare почему-то лучше получилось.  
> 
> В то время когда я использовал VMWare там был какой-то страх и ужас.
> Удобнее было сеть создавать самостоятельно, в /etc/network/interfaces,
> что я и делал. Как с этим сейчас — не знаю, давно уже не использую
> VMWare.
> 
> > Разработчики qemu/kvm вместо этого потратили усилия  на
> > действительно полезные вещи.  
> 
> Я ни коим образом не принижаю заслуг разработчиков qemu/KVM. Я их
> разработку просто использую на серверах. Но это вовсе не означает что
> остальные разработчики — дураки только лишь потому что одному
> конкретному человеку их творение не нравится. Не нравится — не
> пользуйтесь, никто ж не заставляет. Благо, альтернативы есть.
> 
> >> Если бы религиозные войны, что компьютерные, что мировые приводили
> >> не к смерти и разрушениям, а к чему-то созидательному — на
> >> здоровье. Но глядя на исторический опыт — в топку!  
> > 
> > К сожалению,  без смерти  и разрушения старого и
> > отжившего, построить новое и хорошее нельзя.  
> 
> Именно это я могу сказать по поводу «Я этого новояза в который
> превратили компьютерную технолоию переводчики, не разумею.» и «В
> исходниках там сообщения на английском, вот давайте той терминологией
> и пользоваться.» Как вы и просите — старое выбрасываем.
> 



-- 
   Victor Wagner <vi...@wagner.pp.ru>

Re: Тестирование DNS в lxc контейнере.

[Михаил Касаджиков]

06.09.2016 09:28, Victor Wagner пишет:
>>> Естественно, среди этих моделей реальности нет той, которая наиболее
>>> удобна нормальным людям, умеющим думать и желающим понимать.
>>> Проприетарная софтина,  пусть и выпущенная под номинально открытой
>>> лицензией - она отучает людей думать.  
>>
>> Как раз модель «на хосте с виртуалками есть своя виртуальная сеть для
>> них со своим DHCP и DNS» есть и прекрасно работает. Называется «Тип
>> подключения; сетевой мост». # brctl show lxcbr0 bridge name
> 
> А по-человечески можно? Без ублюдских NLS? Bridged networking или как?
> Я этого новояза в который превратили компьютерную технолоию
> переводчики, не разумею. В исходниках там сообщения на английском, вот
> давайте той терминологией и пользоваться.

А давайте без «давайте», хорошо? Я предпочитаю чтобы компьютер мне
рассказывал свои сказки на понятном МНЕ языке, там где не нужна
машиночитаемость. Вам нравится всё на английском? Хотите чтобы
VirtualBox вам всё сообщал на английском языке? Да на здоровье! Но не
надо навязывать своё «абсолютно верное» мнение другим людям.

> Судя по имени bridge в вашем примере это выглядит как "у virtual box
> есть возможность прицепиться к уже существующему сетевому интерфейсу, и
> мы ее используем, цепляясь к бриджу, созданному для lxc-контейнеров".

Да, именно так. Мне не нужна куча виртуальных сетей на рабочем компе и я
решил оставить один вариант, создаваемый скриптом из пакета lxc. Не
потому что там как-то запредельно круто это сделано, а потому что мне
такой вариант удобнее. Всё, точка. Нет тут никаких высоченных материй.

> То есть это фактически признание "Virtual Box управлять сетью не умеет,
> все надо делать руками, но слава богу, есть возможность прицепиться к
> созданному руками".

Нет, не так. И LXC, и libvirt, и VirtualBox могут полностью
самостоятельно создавать виртуальные сети. Но мне не нужен весь этот
зоопарк, поэтому я оставил один вариант. Неужели не понятно???

> У VMWare почему-то лучше получилось.

В то время когда я использовал VMWare там был какой-то страх и ужас.
Удобнее было сеть создавать самостоятельно, в /etc/network/interfaces,
что я и делал. Как с этим сейчас — не знаю, давно уже не использую VMWare.

> Разработчики qemu/kvm вместо этого потратили усилия  на действительно
> полезные вещи.

Я ни коим образом не принижаю заслуг разработчиков qemu/KVM. Я их
разработку просто использую на серверах. Но это вовсе не означает что
остальные разработчики — дураки только лишь потому что одному
конкретному человеку их творение не нравится. Не нравится — не
пользуйтесь, никто ж не заставляет. Благо, альтернативы есть.

>> Если бы религиозные войны, что компьютерные, что мировые приводили не
>> к смерти и разрушениям, а к чему-то созидательному — на здоровье. Но
>> глядя на исторический опыт — в топку!
> 
> К сожалению,  без смерти  и разрушения старого и
> отжившего, построить новое и хорошее нельзя.

Именно это я могу сказать по поводу «Я этого новояза в который
превратили компьютерную технолоию переводчики, не разумею.» и «В
исходниках там сообщения на английском, вот давайте той терминологией и
пользоваться.» Как вы и просите — старое выбрасываем.

Re: Тестирование DNS в lxc контейнере.

[Eugene Berdnikov]

On Tue, Sep 06, 2016 at 01:30:07AM +0300, Иван Лох wrote:
> On Mon, Sep 05, 2016 at 08:18:00PM +0300, Oleksandr Gavenko wrote:
> > On 2016-09-05, Иван Лох wrote:
> > 
> > > В системе i386 и ядром amd64 уже ставится и работает?
> > 
> > Чем такая конфигурация привлекательна?
> 
> Экономией памяти. Если у меня в точности одно приложение должно
> запускаться в 64-разрядной моде, то я его в ней и запускаю.
> 
> Но независимо от того чем эта конфигурация привлекательна, она штатная
> и kvm работает из коробки, также как и другие программы. В отличии
> от VirtualBox. 

 В каком смысле, 64-битный VirtualBox не запускается в 32-битной
 системе под 64-битным ядром, у которого все виртуалбоксовые
 64-битные модули подгружены? Или речь о гостевой системе?
-- 
 Eugene Berdnikov

Re: Тестирование DNS в lxc контейнере.

[Victor Wagner]

On Mon, 5 Sep 2016 23:20:32 +0300
Михаил Касаджиков <ha...@h13online.net> wrote:


> > Естественно, среди этих моделей реальности нет той, которая наиболее
> > удобна нормальным людям, умеющим думать и желающим понимать.
> > Проприетарная софтина,  пусть и выпущенная под номинально открытой
> > лицензией - она отучает людей думать.  
> 
> Как раз модель «на хосте с виртуалками есть своя виртуальная сеть для
> них со своим DHCP и DNS» есть и прекрасно работает. Называется «Тип
> подключения; сетевой мост». # brctl show lxcbr0 bridge name

А по-человечески можно? Без ублюдских NLS? Bridged networking или как?
Я этого новояза в который превратили компьютерную технолоию
переводчики, не разумею. В исходниках там сообщения на английском, вот
давайте той терминологией и пользоваться.

Судя по имени bridge в вашем примере это выглядит как "у virtual box
есть возможность прицепиться к уже существующему сетевому интерфейсу, и
мы ее используем, цепляясь к бриджу, созданному для lxc-контейнеров".

То есть это фактически признание "Virtual Box управлять сетью не умеет,
все надо делать руками, но слава богу, есть возможность прицепиться к
созданному руками". А все усилия, потраченные разработчиками virtual box
на создание "удобной и дружественной к пользователю" системы управления
виртуальными сетями - выкрасить и выбросить.

У VMWare почему-то лучше получилось.

Разработчики qemu/kvm вместо этого потратили усилия  на действительно
полезные вещи.

 
> Если бы религиозные войны, что компьютерные, что мировые приводили не
> к смерти и разрушениям, а к чему-то созидательному — на здоровье. Но
> глядя на исторический опыт — в топку!

К сожалению,  без смерти  и разрушения старого и
отжившего, построить новое и хорошее нельзя.
 

Re: Тестирование DNS в lxc контейнере.

[Иван Лох]

On Mon, Sep 05, 2016 at 08:18:00PM +0300, Oleksandr Gavenko wrote:
> On 2016-09-05, Иван Лох wrote:
> 
> > В системе i386 и ядром amd64 уже ставится и работает?
> 
> Чем такая конфигурация привлекательна?

Экономией памяти. Если у меня в точности одно приложение должно
запускаться в 64-разрядной моде, то я его в ней и запускаю.

Но независимо от того чем эта конфигурация привлекательна, она штатная
и kvm работает из коробки, также как и другие программы. В отличии
от VirtualBox. 

Re: Тестирование DNS в lxc контейнере.

[Михаил Касаджиков]

05.09.2016 23:25, Hleb Valoshka пишет:
> On 9/5/16, Михаил Касаджиков  wrote:
>>> VirtualBox не запустится пока не выгрузить kvm.ko и наоборот с vboxdrv.ko
>>
>> Прекрасно работают одновременно и KVM и VirtualBox:
>> $ lsmod | grep -e ^kvm -e ^vbox
>> vboxpci24576  0
>> vboxnetadp 28672  0
>> vboxnetflt 28672  0
>> vboxdrv   450560  3 vboxnetadp,vboxnetflt,vboxpci
>> kvm_amd61440  0
>> kvm   565248  1 kvm_amd
> 
> Модули в ядре уживаются, но qemu с ускорением не запустишь, если
> запущена виртуалка VirtualBox.

Хм. Действительно, либо KVM, либо VirtualBox. Давно я тут KVM не запускал, как 
перенёс все мини серверы на отдельный комп.
Прошу прощения за дезинформацию.

Re: Тестирование DNS в lxc контейнере.

[Hleb Valoshka]

On 9/5/16, Михаил Касаджиков  wrote:
>> VirtualBox не запустится пока не выгрузить kvm.ko и наоборот с vboxdrv.ko
>
> Прекрасно работают одновременно и KVM и VirtualBox:
> $ lsmod | grep -e ^kvm -e ^vbox
> vboxpci24576  0
> vboxnetadp 28672  0
> vboxnetflt 28672  0
> vboxdrv   450560  3 vboxnetadp,vboxnetflt,vboxpci
> kvm_amd61440  0
> kvm   565248  1 kvm_amd

Модули в ядре уживаются, но qemu с ускорением не запустишь, если
запущена виртуалка VirtualBox.

Re: Тестирование DNS в lxc контейнере.

[Михаил Касаджиков]

05.09.2016 20:38, Victor Wagner пишет:
>>>> вила трансляции. Так что пока лишь диагноз
>>>> "голова и руки".  
>>>
>>> Не очевидно. Лично мне очевидно что с хоста, который является
>>> nat-ящим роутером между внутренней сетью и внешней, внутренняя сеть
>>> должна быть просто ВИДНА. Соотвественно ничего пробрасывать не
>>> должно быть нужно. Оно должно просто по умолчанию быть доступно.  
>>
>>  У виртуалбокса несколько типов подключения к сети, включая NAT,
>> бридж, встроенный адаптер хоста, внутренняя сеть и что-то там ещё. А
>> всё потому, что разные люди хотят реализовать виртуалками разные
> 
> Вот я про то же, что у виртуал бокса несколько жестко прибитых гвоздями
> способов подключения к сети, а не возможность собрать из кубиков то,
> что надо.
> 
>> модели реальности. Кто-то хочет, чтобы сетевой адаптер виртуальной
> 
> Естественно, среди этих моделей реальности нет той, которая наиболее
> удобна нормальным людям, умеющим думать и желающим понимать.
> Проприетарная софтина,  пусть и выпущенная под номинально открытой
> лицензией - она отучает людей думать.

Как раз модель «на хосте с виртуалками есть своя виртуальная сеть для них со 
своим DHCP и DNS» есть и прекрасно работает. Называется «Тип подключения; 
сетевой мост».
# brctl show lxcbr0
bridge name bridge id   STP enabled interfaces
lxcbr0  8000.fefe43a96481   no  veth16AORX

# ip -4 addr show dev lxcbr0
6: lxcbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP 
group default qlen 1000
inet 10.10.13.1/24 scope global lxcbr0
   valid_lft forever preferred_lft forever

# netstat -lnup | grep 10.10.13.1:53
udp0  0 10.10.13.1:53   0.0.0.0:*   
3113/dnsmasq

И вот так добавлен домен с виртуалками в общий DNS на компе:

# cat /etc/dnsmasq.d/lxc
server=/lxc/10.10.13.1

И всё прекрасно работает и для QEMU, и для VirtualBox, и для LXC. Одновременно. 
Не вижу никакой сложности при использовании VireualBox с произвольной 
конфигурацией сети.

>>  Так что не надо религиозных войн, и не надо выдавать частные неудачи
>>  в конфигурации сети за глобальные проблемы программного интерфейса.
> 
> Нет, вот именно что надо религиозных войн. Потому что религозные войны
> они за свободу. За право самому определять то что тебе удобно, а что
> нет. 

Если бы религиозные войны, что компьютерные, что мировые приводили не к смерти 
и разрушениям, а к чему-то созидательному — на здоровье. Но глядя на 
исторический опыт — в топку!

Re: Тестирование DNS в lxc контейнере.

[Eugene Berdnikov]

On Mon, Sep 05, 2016 at 08:38:02PM +0300, Victor Wagner wrote:
> On Mon, 5 Sep 2016 17:03:32 +0300
> Eugene Berdnikov  wrote:
> 
> вила трансляции. Так что пока лишь диагноз
> > > > "голова и руки".  
> > > 
> > > Не очевидно. Лично мне очевидно что с хоста, который является
> > > nat-ящим роутером между внутренней сетью и внешней, внутренняя сеть
> > > должна быть просто ВИДНА. Соотвественно ничего пробрасывать не
> > > должно быть нужно. Оно должно просто по умолчанию быть доступно.  
> > 
> >  У виртуалбокса несколько типов подключения к сети, включая NAT,
> > бридж, встроенный адаптер хоста, внутренняя сеть и что-то там ещё. А
> > всё потому, что разные люди хотят реализовать виртуалками разные
> 
> Вот я про то же, что у виртуал бокса несколько жестко прибитых гвоздями
> способов подключения к сети, а не возможность собрать из кубиков то,
> что надо.

 Нет, неправда.

> > модели реальности. Кто-то хочет, чтобы сетевой адаптер виртуальной
> 
> Естественно, среди этих моделей реальности нет той, которая наиболее
> удобна нормальным людям, умеющим думать и желающим понимать.

 Ваша "любимая" модель (сеть, присоединённая через адаптер к хост-системе)
 там есть. Вы, наверное, её не нашли, так плохо искали. Меню всего из пятка
 типов подключений к сети. Впрочем, для человека, априори уверенного в
 наличии одного единственно правильного решения, которое непременно должно
 быть всенародно любимым правильными гражданами (как во времена СССР),
 пяток это слишком много, конечно.
-- 
 Eugene Berdnikov

Re: Тестирование DNS в lxc контейнере.

[Vasiliy P. Melnik]

>
> Естественно, среди этих моделей реальности нет той, которая наиболее
> удобна нормальным людям, умеющим думать и желающим понимать.
> Проприетарная софтина,  пусть и выпущенная под номинально открытой
> лицензией - она отучает людей думать.
>

А где записывают в очередь не думающих? а то мне нравится виртуалбокс - мне
ка-то оно надо чтобы протестировать что-то, да и скорость работы
устраивает, а наличие интерфейса я таки считаю плюсом. И мне таки хватает
чем заниматься, кроме виртуалок.

Ну и плюс ко всему я предпочитаю айфон - не, у меня были и леново, и лыжа
не дешевая, только обратно вернулся на айфон. Свой старый 5S я таки за два
года добил, пришлось пойти и купить новый 5S, сейчас очень даже не дорого.

А еще я считаю самым удобным офисным пакетом все таки микрософт офис, хоть
сам и пользуюсь либрой

Re: Тестирование DNS в lxc контейнере.

[Victor Wagner]

On Mon, 5 Sep 2016 17:03:32 +0300
Eugene Berdnikov  wrote:

вила трансляции. Так что пока лишь диагноз
> > > "голова и руки".  
> > 
> > Не очевидно. Лично мне очевидно что с хоста, который является
> > nat-ящим роутером между внутренней сетью и внешней, внутренняя сеть
> > должна быть просто ВИДНА. Соотвественно ничего пробрасывать не
> > должно быть нужно. Оно должно просто по умолчанию быть доступно.  
> 
>  У виртуалбокса несколько типов подключения к сети, включая NAT,
> бридж, встроенный адаптер хоста, внутренняя сеть и что-то там ещё. А
> всё потому, что разные люди хотят реализовать виртуалками разные

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

> модели реальности. Кто-то хочет, чтобы сетевой адаптер виртуальной

Естественно, среди этих моделей реальности нет той, которая наиболее
удобна нормальным людям, умеющим думать и желающим понимать.
Проприетарная софтина,  пусть и выпущенная под номинально открытой
лицензией - она отучает людей думать.


> 
>  Так что не надо религиозных войн, и не надо выдавать частные неудачи
>  в конфигурации сети за глобальные проблемы программного интерфейса.

Нет, вот именно что надо религиозных войн. Потому что религозные войны
они за свободу. За право самому определять то что тебе удобно, а что
нет. 

Для тех, кто склонен  в этом плане доверять вендору софта, есть iPhone
и iPad. Им нечего делать за клавиатурой универсального компьютера.

Собственнно это продолжение той же войны в которой людьми против зомби
уже было проиграно сражение за систему инициализации.

Кстати, в процессе дискуссии на эту тему где-то в devel прозвучало

"Debian is not about choice". Ты действительно этого хочешь? Чтобы не
было выбора и надо было использовать то, что решили голосованием?

-- 
   Victor Wagner 

Re: Тестирование DNS в lxc контейнере.

[Victor Wagner]

On Mon, 05 Sep 2016 20:18:00 +0300
Oleksandr Gavenko  wrote:

> On 2016-09-05, Иван Лох wrote:
> 
> > В системе i386 и ядром amd64 уже ставится и работает?  
> 
> Чем такая конфигурация привлекательна?
> 
> Вендоры не поставляют 32-bit драйверов и хочется сэкономить на RAM в
> офисных компьютерах?
> 

Дебиан не предоставляет процедуры crossgrade с i386 на amd64 с
сохранением всей конфигурациии системы.



-- 
   Victor Wagner 

Re: Тестирование DNS в lxc контейнере.

[Vasiliy P. Melnik]

5 сентября 2016 г., 20:18 пользователь Oleksandr Gavenko  написал:

> On 2016-09-05, Иван Лох wrote:
>
> > В системе i386 и ядром amd64 уже ставится и работает?
>
> Чем такая конфигурация привлекательна?
>
> Вендоры не поставляют 32-bit драйверов и хочется сэкономить на RAM в
> офисных
> компьютерах?
>

Уже больше года новые офисные компы комплектую минимум 8 гигами оперативки.
Все что меньше - это не память, это уже склероз.

Re: Тестирование DNS в lxc контейнере.

[Vasiliy P. Melnik]

- Хаим, я слышал вы выиграли миллион в лотерею! Это правда?
- Не совсем.
- Что значит не совсем?
- Ну во-первых не миллион, а тысячу. Во-вторых, не в лотерею, а в карты. И
в третьих, не выиграл, а проиграл.

Re: Тестирование DNS в lxc контейнере.

[Oleksandr Gavenko]

On 2016-09-05, Иван Лох wrote:

> В системе i386 и ядром amd64 уже ставится и работает?

Чем такая конфигурация привлекательна?

Вендоры не поставляют 32-bit драйверов и хочется сэкономить на RAM в офисных
компьютерах?

-- 
http://defun.work/

Re: Тестирование DNS в lxc контейнере.

[Oleksandr Gavenko]

On 2016-09-05, Михаил Касаджиков wrote:

>> VirtualBox не запустится пока не выгрузить kvm.ko и наоборот с vboxdrv.ko
>
> Прекрасно работают одновременно и KVM и VirtualBox:
> $ lsmod | grep -e ^kvm -e ^vbox
> vboxpci24576  0
> vboxnetadp 28672  0
> vboxnetflt 28672  0
> vboxdrv   450560  3 vboxnetadp,vboxnetflt,vboxpci
> kvm_amd61440  0
> kvm   565248  1 kvm_amd

Я сделал коственный вывод, KVM ускорение Android эмулятора конфликтует с
VirtualBox. Модули то загружаются, но конкретно ругались приложения:

  $ emulator-x86 -avd $NAME -qemu -m 512 -enable-kvm
  $ virtualbox

У меня было как в:

  
http://stackoverflow.com/questions/16168799/android-emulator-and-virtualbox-cannot-run-at-same-time

Правда официальный Android эмулятор у меня жутко тупил, я использовал freeware
Genymotion, который основан на VirtualBox ))

-- 
http://defun.work/

Re: Тестирование DNS в lxc контейнере.

[Михаил Касаджиков]

05.09.2016 00:27, Oleksandr Gavenko пишет:
> On 2016-09-04, Victor Wagner wrote:
>> Eugene Berdnikov  wrote:
 Лучше взять KVM, а не virtual box.   
>>>
>>>  Чем лучше? Неужто в virtualbox резолвер криво работает? :)
>>
>> 1. Не нужно дополннительных модулей в ядро.
> 
> bash# lsmod | grep kvm
> 63:kvm_intel 184320  0
> 64:kvm   552960  1 kvm_intel
> 
> VirtualBox не запустится пока не выгрузить kvm.ko и наоборот с vboxdrv.ko

Прекрасно работают одновременно и KVM и VirtualBox:
$ lsmod | grep -e ^kvm -e ^vbox
vboxpci24576  0
vboxnetadp 28672  0
vboxnetflt 28672  0
vboxdrv   450560  3 vboxnetadp,vboxnetflt,vboxpci
kvm_amd61440  0
kvm   565248  1 kvm_amd

Re: Тестирование DNS в lxc контейнере.

[Eugene Berdnikov]

On Mon, Sep 05, 2016 at 01:27:52PM +0300, Victor Wagner wrote:
> On Mon, 5 Sep 2016 12:50:23 +0300
> Eugene Berdnikov <b...@protva.ru> wrote:
> 
> > > Ну то есть  ситуация "видеть я эту консоль не хочу,
> > > пустите меня по SSH и HTTP, но лишних внешних IP у меня нет".  
> > 
> >  Очевидно, в гостевую сеть нужно пробрасывть ssh и http, а снаружи
> >  должны быть видны имена (что можно сделать пробросом dns внутрь или
> >  приёмом апдейтов изнутри, через nat, внешним dns'ом). Если nat был
> >  встроенный виртуалбоксовый, неудивительно, что ничего не получилось,
> >  потому как проброс внутрь это уже не nat (во всяком случае не то,
> >  что называется "nat'ом" в виртуалбоксе), а дополнительные правила
> >  трансляции. Так что пока лишь диагноз "голова и руки".
> 
> Не очевидно. Лично мне очевидно что с хоста, который является
> nat-ящим роутером между внутренней сетью и внешней, внутренняя сеть
> должна быть просто ВИДНА. Соотвественно ничего пробрасывать не должно
> быть нужно. Оно должно просто по умолчанию быть доступно.

 У виртуалбокса несколько типов подключения к сети, включая NAT, бридж,
 встроенный адаптер хоста, внутренняя сеть и что-то там ещё. А всё потому,
 что разные люди хотят реализовать виртуалками разные модели реальности.
 Кто-то хочет, чтобы сетевой адаптер виртуальной машины "торчал" прямо
 в корпоративный LAN, а все промежуточные бриджи, хост-системы и прочая
 муть -- для него лишние слои абстраций. Кто-то же хочет, чтобы система
 виртуализации сама делала nat, а конфигурить iptables на хост-системе
 ему нафиг не сдалось. Вы же хотите такую модель, где гость подсоединён
 к некоей виртуальной сети, и эта сеть через виртуальный адаптер заходит
 на хост-систему. ОК. Все модели хороши и имеют право на жизнь, и все
 в виртуалбоксе более-менее нормально работают. В частности, родной
 для vb тип подключения NAT содержит стандартную для шлюзов функцию
 проброса портов во внутреннюю сеть.

 Так что не надо религиозных войн, и не надо выдавать частные неудачи
 в конфигурации сети за глобальные проблемы программного интерфейса.
-- 
 Eugene Berdnikov

Re: Тестирование DNS в lxc контейнере.

[Victor Wagner]

On Mon, 5 Sep 2016 12:50:23 +0300
Eugene Berdnikov <b...@protva.ru> wrote:


> > Ну то есть  ситуация "видеть я эту консоль не хочу,
> > пустите меня по SSH и HTTP, но лишних внешних IP у меня нет".  
> 
>  Очевидно, в гостевую сеть нужно пробрасывть ssh и http, а снаружи
>  должны быть видны имена (что можно сделать пробросом dns внутрь или
>  приёмом апдейтов изнутри, через nat, внешним dns'ом). Если nat был
>  встроенный виртуалбоксовый, неудивительно, что ничего не получилось,
>  потому как проброс внутрь это уже не nat (во всяком случае не то,
>  что называется "nat'ом" в виртуалбоксе), а дополнительные правила
>  трансляции. Так что пока лишь диагноз "голова и руки".

Не очевидно. Лично мне очевидно что с хоста, который является
nat-ящим роутером между внутренней сетью и внешней, внутренняя сеть
должна быть просто ВИДНА. Соотвественно ничего пробрасывать не должно
быть нужно. Оно должно просто по умолчанию быть доступно. А создание
внутреней сети, которая по умолчанию не доступна с хоста должно
требовать если не плясок с бубном, то осознанного решения "я хочу,
чтобы эта сеть не была доступна".

Вопрос о взаимодействии между dhcp-сервером внутренней сети и
dns резолвером хоста - он несколько более интересный. Мой вариант -
когда на хосте есть один общий dhcp-сервер для всех внутренних сетей, и
он же является локальным dns-сервером, поэтому сервит заодно и адресат
хостов из внутренних сетей, может кому-то не понравится.




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

Теперь можно. Потому что я ее уже написал. И желающие могут скачать и
использовать. Но вообще-то чайникам я могу порекомендовать только
"мышки, станьте ежиками". То есть если либо переставай быть чайником,
либо универсальный компьютер не для тебя, купи себе айфон.

Re: Тестирование DNS в lxc контейнере.

[Eugene Berdnikov]

On Mon, Sep 05, 2016 at 07:50:16AM +0300, Victor Wagner wrote:
> On Sun, 4 Sep 2016 17:37:25 +0300
> Eugene Berdnikov <b...@protva.ru> wrote:
> 
> > > 2. Куда гибче и проще конфигурация сети. В VirtualBox попытались
> > > создать интерфейс для чайников, в результате получилось шаг вправо,
> > > шаг влево считается побег.  
> > 
> >  Приведите пример шага вправо и пример шагa влево, за которые
> > интерфейс виртуалбокса стреляет в юзера.
> 
> Помнится, у меня были проблемы с какой-то совершенно тривиальной на мой
> взгляд конфигурацией. Вроде виртуальной сети, которая
> NAT-ится во внешний мир, а внутри виртуалкам раздают адреса по DHCP, и
> потом можно с хост-системы ходить на эти виртуалки, используя их
> hostname в качестве DNS имен.
> 
> Ну то есть  ситуация "видеть я эту консоль не хочу,
> пустите меня по SSH и HTTP, но лишних внешних IP у меня нет".

 Очевидно, в гостевую сеть нужно пробрасывть ssh и http, а снаружи
 должны быть видны имена (что можно сделать пробросом dns внутрь или
 приёмом апдейтов изнутри, через nat, внешним dns'ом). Если nat был
 встроенный виртуалбоксовый, неудивительно, что ничего не получилось,
 потому как проброс внутрь это уже не nat (во всяком случае не то,
 что называется "nat'ом" в виртуалбоксе), а дополнительные правила
 трансляции. Так что пока лишь диагноз "голова и руки".

> > > 3. Конфигурация всего остального у kvm тоже гибче, хотя это не
> > > слишком актуально для задачи тестирования DNS. Но может потом
> > > захочется еще чего потестировать. (а к тому времени в KVM уже и
> > > 3d-графика будет)  
> > 
> >  Человеку нужно было не гибче, а побыстрее и попроще.
> >  И вот тут-то kvm натурально сосёт.
> 
> Человеку нужно "чтобы решало его задачу". В этом сосут все изделия
> Oracle. 

 Не надо экстремизма и передёргиваний на ровном месте. Виртуалбокс
 это изделие Сана, а не Оракла. Ораклу достались лишь права на него.

 А задачу "побыстрее и попроще" решает таки виртуалбокс, а не kvm.

> А написать обертку вокруг голого kvm которая делает то что надо в
> нужных мне случаях, но при этом не мешает лезть грязными лапами в
> командную строку kvm или в его монитор у меня заняло 500 строк на
> питоне.

 Да, это офигенно быстро и просто, надо всем чайникам рекомендовать.
-- 
 Eugene Berdnikov

Re: Тестирование DNS в lxc контейнере.

[Иван Лох]

On Sun, Sep 04, 2016 at 05:37:25PM +0300, Eugene Berdnikov wrote:
> On Sun, Sep 04, 2016 at 08:39:57AM +0300, Victor Wagner wrote:
> > On Sat, 3 Sep 2016 21:34:36 +0300
> > Eugene Berdnikov  wrote:
> > > > 
> > > > Лучше взять KVM, а не virtual box.   
> > > 
> > >  Чем лучше? Неужто в virtualbox резолвер криво работает? :)
> > 
> > 1. Не нужно дополннительных модулей в ядро.
> 
>  Это забота пакетного менеджера.

В системе i386 и ядром amd64 уже ставится и работает?

Re: Тестирование DNS в lxc контейнере.

[Victor Wagner]

On Mon, 05 Sep 2016 00:27:16 +0300
Oleksandr Gavenko  wrote:

> On 2016-09-04, Victor Wagner wrote:
> > Eugene Berdnikov  wrote:  
> >> > Лучше взять KVM, а не virtual box. 
> >> 
> >>  Чем лучше? Неужто в virtualbox резолвер криво работает? :)  
> >
> > 1. Не нужно дополннительных модулей в ядро.  
> 
> bash# lsmod | grep kvm
> 63:kvm_intel 184320  0
> 64:kvm   552960  1 kvm_intel
> 
> VirtualBox не запустится пока не выгрузить kvm.ko и наоборот с
> vboxdrv.ko

Об этом я даже и не знал, поскольку с virtualbox-ом имею дело обычно в
чужих руках. Вот с lxc kvm прекрасно уживается.

 
> Наверно имелось ввиду что kvm в дереве исходников Linux:


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

В свое время я с vmware регулярно на это напарывался, почему и
предпочитаю использовать kvm, хотя vmware умеет некоторые вещи, которые
kvm не умеет.

вв> 
> Таки да, Oracle в любой момент может убить проект VirtualBox.
> 



-- 
   Victor Wagner 

Re: Тестирование DNS в lxc контейнере.

[Victor Wagner]

On Sun, 4 Sep 2016 17:37:25 +0300
Eugene Berdnikov <b...@protva.ru> wrote:

> On Sun, Sep 04, 2016 at 08:39:57AM +0300, Victor Wagner wrote:
> > On Sat, 3 Sep 2016 21:34:36 +0300
> > Eugene Berdnikov <b...@protva.ru> wrote:  
> > > > 
> > > > Лучше взять KVM, а не virtual box. 
> > > 
> > >  Чем лучше? Неужто в virtualbox резолвер криво работает? :)  
> > 
> > 1. Не нужно дополннительных модулей в ядро.  
> 
>  Это забота пакетного менеджера.

Не "пакетного менеджера", а мейнтейнера соответствующих пакетов.



> > 2. Куда гибче и проще конфигурация сети. В VirtualBox попытались
> > создать интерфейс для чайников, в результате получилось шаг вправо,
> > шаг влево считается побег.  
> 
>  Приведите пример шага вправо и пример шагa влево, за которые
> интерфейс виртуалбокса стреляет в юзера.

Помнится, у меня были проблемы с какой-то совершенно тривиальной на мой
взгляд конфигурацией. Вроде виртуальной сети, которая
NAT-ится во внешний мир, а внутри виртуалкам раздают адреса по DHCP, и
потом можно с хост-системы ходить на эти виртуалки, используя их
hostname в качестве DNS имен.

Ну то есть  ситуация "видеть я эту консоль не хочу,
пустите меня по SSH и HTTP, но лишних внешних IP у меня нет".
 
> > 3. Конфигурация всего остального у kvm тоже гибче, хотя это не
> > слишком актуально для задачи тестирования DNS. Но может потом
> > захочется еще чего потестировать. (а к тому времени в KVM уже и
> > 3d-графика будет)  
> 
>  Человеку нужно было не гибче, а побыстрее и попроще.
>  И вот тут-то kvm натурально сосёт.

Человеку нужно "чтобы решало его задачу". В этом сосут все изделия
Oracle. 

А написать обертку вокруг голого kvm которая делает то что надо в
нужных мне случаях, но при этом не мешает лезть грязными лапами в
командную строку kvm или в его монитор у меня заняло 500 строк на
питоне.



-- 
   Victor Wagner <vi...@wagner.pp.ru>

Re: Тестирование DNS в lxc контейнере.

[Oleksandr Gavenko]

On 2016-09-04, Victor Wagner wrote:
> Eugene Berdnikov  wrote:
>> > Лучше взять KVM, а не virtual box.   
>> 
>>  Чем лучше? Неужто в virtualbox резолвер криво работает? :)
>
> 1. Не нужно дополннительных модулей в ядро.

bash# lsmod | grep kvm
63:kvm_intel 184320  0
64:kvm   552960  1 kvm_intel

VirtualBox не запустится пока не выгрузить kvm.ko и наоборот с vboxdrv.ko

Наверно имелось ввиду что kvm в дереве исходников Linux:

  bash# locate kvm.ko
  /lib/modules/4.5.0-2-amd64/kernel/arch/x86/kvm/kvm.ko

  bash# locate vboxdrv.ko
  /lib/modules/4.5.0-2-amd64/updates/dkms/vboxdrv.ko

Таки да, Oracle в любой момент может убить проект VirtualBox.

-- 
http://defun.work/

Re: Тестирование DNS в lxc контейнере.

[Eugene Berdnikov]

On Sun, Sep 04, 2016 at 08:39:57AM +0300, Victor Wagner wrote:
> On Sat, 3 Sep 2016 21:34:36 +0300
> Eugene Berdnikov <b...@protva.ru> wrote:
> > > 
> > > Лучше взять KVM, а не virtual box.   
> > 
> >  Чем лучше? Неужто в virtualbox резолвер криво работает? :)
> 
> 1. Не нужно дополннительных модулей в ядро.

 Это забота пакетного менеджера.

> 2. Куда гибче и проще конфигурация сети. В VirtualBox попытались
> создать интерфейс для чайников, в результате получилось шаг вправо, шаг
> влево считается побег.

 Приведите пример шага вправо и пример шагa влево, за которые интерфейс
 виртуалбокса стреляет в юзера.

> 3. Конфигурация всего остального у kvm тоже гибче, хотя это не слишком
> актуально для задачи тестирования DNS. Но может потом захочется еще
> чего потестировать. (а к тому времени в KVM уже и 3d-графика будет)

 Человеку нужно было не гибче, а побыстрее и попроще.
 И вот тут-то kvm натурально сосёт.
-- 
 Eugene Berdnikov

Re: Тестирование DNS в lxc контейнере.

[Victor Wagner]

On Sat, 3 Sep 2016 21:34:36 +0300
Eugene Berdnikov <b...@protva.ru> wrote:


> > 
> > Лучше взять KVM, а не virtual box.   
> 
>  Чем лучше? Неужто в virtualbox резолвер криво работает? :)

1. Не нужно дополннительных модулей в ядро.
2. Куда гибче и проще конфигурация сети. В VirtualBox попытались
создать интерфейс для чайников, в результате получилось шаг вправо, шаг
влево считается побег.
3. Конфигурация всего остального у kvm тоже гибче, хотя это не слишком
актуально для задачи тестирования DNS. Но может потом захочется еще
чего потестировать. (а к тому времени в KVM уже и 3d-графика будет)

Re: Тестирование DNS в lxc контейнере.

[Eugene Berdnikov]

On Sat, Sep 03, 2016 at 09:12:58PM +0300, Victor Wagner wrote:
> On Sat, 03 Sep 2016 16:20:40 +0300
> Oleksandr Gavenko <gaven...@gmail.com> wrote:
> 
> > On 2016-09-03, Oleksandr Gavenko wrote:
> > 
> > > Я не хочу заводить virtualbox под Debian sid, но не очевидно как в
> > > LXC контейнере будет выполняться разрешение имен DNS.  
> > 
> > В LXC релиз Sid не стартует, а в Stretch connman завершается с
> > ошибками.
> > 
> > В итоге проверил в VirtualBox ))
> 
> Лучше взять KVM, а не virtual box. 

 Чем лучше? Неужто в virtualbox резолвер криво работает? :)
-- 
 Eugene Berdnikov

Re: Тестирование DNS в lxc контейнере.

[Victor Wagner]

On Sat, 03 Sep 2016 16:20:40 +0300
Oleksandr Gavenko <gaven...@gmail.com> wrote:

> On 2016-09-03, Oleksandr Gavenko wrote:
> 
> > Я не хочу заводить virtualbox под Debian sid, но не очевидно как в
> > LXC контейнере будет выполняться разрешение имен DNS.  
> 
> В LXC релиз Sid не стартует, а в Stretch connman завершается с
> ошибками.
> 
> В итоге проверил в VirtualBox ))
> 

Лучше взять KVM, а не virtual box. 

Re: Тестирование DNS в lxc контейнере.

[Victor Wagner]

On Sat, 03 Sep 2016 13:00:17 +0300
Oleksandr Gavenko <gaven...@gmail.com> wrote:

> Я не понимаю можно ли в LXC проверить что мой багрепорт разрешен.

В принципе да.

>   https://bugs.debian.org/cgi-bin/bugreport.cgi?archive=yes=805797
> connman: Utility to flush DNS cache?
> 
> Я не хочу заводить virtualbox под Debian sid, но не очевидно как в LXC
> контейнере будет выполняться разрешение имен DNS.
> 
> У контейнера есть lxcbr0 с настройками в /etc/default/lxc-net
> 
> 
> 
> Используется ли libc из host в LXC guest? Или только ядро шарится, а
> весь userspace берется из файлов в /var/lib/lxc/*/* ?

Шарится только ядро. Можно поставить 32-битную систему, можно
поставить вообще другой дистрибутив. У меня на рабочей машине есть
наприимер centos6-32бит в lxc. А хост система jessie 64бит.

Но: насколько говорит мой опыт,  lxc хорошо работает тогда, когда хост
(ядро и lxc-утилиты) новее, чем guest-ы. То есть во времена wheezy
регулярно приходилось сталкиваться  с проблемами при апгрейде testing
в контейнере.

Re: Тестирование DNS в lxc контейнере.

[Oleksandr Gavenko]

On 2016-09-03, Oleksandr Gavenko wrote:

> Я не хочу заводить virtualbox под Debian sid, но не очевидно как в LXC
> контейнере будет выполняться разрешение имен DNS.

В LXC релиз Sid не стартует, а в Stretch connman завершается с ошибками.

В итоге проверил в VirtualBox ))

-- 
http://defun.work/

Тестирование DNS в lxc контейнере.

[Oleksandr Gavenko]

Я не понимаю можно ли в LXC проверить что мой багрепорт разрешен.

  https://bugs.debian.org/cgi-bin/bugreport.cgi?archive=yes=805797
connman: Utility to flush DNS cache?

Я не хочу заводить virtualbox под Debian sid, но не очевидно как в LXC
контейнере будет выполняться разрешение имен DNS.

У контейнера есть lxcbr0 с настройками в /etc/default/lxc-net



Используется ли libc из host в LXC guest? Или только ядро шарится, а весь
userspace берется из файлов в /var/lib/lxc/*/* ?

-- 
http://defun.work/

Re: VPN и корпоративный DNS

[Pavel Volkov]

On вторник, 12 июля 2016 г. 1:28:23 MSK, Max Dmitrichenko wrote:

Всем привет!

Есть корпоративная сеть, куда юзер коннектится через OpenVPN. У юзера
линукс. По dhcp он получает корпоративный DNS сервер, который либо
умеет резолвить только корпоративные адреса, либо умеет и
интернет-адреса, но это крайне не желательно.

Возможно ли юзеру каким-то образом сконфигурить у себя резолвер так,
чтобы за корпоративными адресами (по домену, например) он лез к
корпоративному DNS-серверу, а за всеми остальными к DNS'у провайдера?



Если юзер использует systemd-resolved, то там это штатная функция.

Примерный network-файл:

[Match]
Name=tap0

[Network]
DHCP=ipv4
Domains=

Re: VPN и корпоративный DNS

[Andrey Melnikoff]

Artem Chuprina <r...@lasgalen.net> wrote:
> Andrey Melnikoff -> debian-russian@lists.debian.org  @ Tue, 12 Jul 2016 
> 15:56:19 +0300:

>  >>  > Есть корпоративная сеть, куда юзер коннектится через OpenVPN. У юзера
>  >>  > линукс. По dhcp он получает корпоративный DNS сервер, который либо
>  >>  > умеет резолвить только корпоративные адреса, либо умеет и
>  >>  > интернет-адреса, но это крайне не желательно.

>  >>  > Возможно ли юзеру каким-то образом сконфигурить у себя резолвер так,
>  >>  > чтобы за корпоративными адресами (по домену, например) он лез к
>  >>  > корпоративному DNS-серверу, а за всеми остальными к DNS'у провайдера?

>  >> Резолвер - нет. Свой кэширующий DNS-сервер - да. У меня так настроен 
> dnsmasq.

>  >> Засада, правда, есть: когда коллега на голубом глазу шлет тебе ссылку, в
>  >> которой неквалифицированное имя хоста (http://wiki/path), надо, чтобы в
>  >> этот момент домен по умолчанию у резолвера был корпоративным, что в
>  >> рассматриваемой ситуации, подозреваю, как минимум неправильно, а скорее
>  >> - не вариант. И то не факт, что поможет.
>  > А кто мешает прописать в resolv.conf: search local. corp.domain. 
> other.corp.domain. ?
> resolvconf, кажется :)
dpkg --purge resolvconf по нему плачет. У меня вот нигде нету и проблемы этой 
нету.

> Не помню, то ли там есть какая-то грабля, то ли я просто не доделал настройку 
> resolvconf.

Да нет там никакой грабли. Есть противоесстественный интелект в районе
переписывания domain|search

> То ли затупил между "настроить dnsmasq" и "настроить resolvconf", когда
> хачил скрипт для openconnect - у меня рабочий VPN выдает роутинги,
> которые конфликтуют с домашними, и приходится аккуратно вырезать лишнее
> из полученной инфы.
А не проще домашную сеть перенастроить на 198.18.0.0/15 и избавиться от
проблемы пересечения адресов?

Re: VPN и корпоративный DNS

[Artem Chuprina]

Andrey Melnikoff -> debian-russian@lists.debian.org  @ Tue, 12 Jul 2016 
15:56:19 +0300:

 >>  > Есть корпоративная сеть, куда юзер коннектится через OpenVPN. У юзера
 >>  > линукс. По dhcp он получает корпоративный DNS сервер, который либо
 >>  > умеет резолвить только корпоративные адреса, либо умеет и
 >>  > интернет-адреса, но это крайне не желательно.

 >>  > Возможно ли юзеру каким-то образом сконфигурить у себя резолвер так,
 >>  > чтобы за корпоративными адресами (по домену, например) он лез к
 >>  > корпоративному DNS-серверу, а за всеми остальными к DNS'у провайдера?

 >> Резолвер - нет. Свой кэширующий DNS-сервер - да. У меня так настроен 
 >> dnsmasq.

 >> Засада, правда, есть: когда коллега на голубом глазу шлет тебе ссылку, в
 >> которой неквалифицированное имя хоста (http://wiki/path), надо, чтобы в
 >> этот момент домен по умолчанию у резолвера был корпоративным, что в
 >> рассматриваемой ситуации, подозреваю, как минимум неправильно, а скорее
 >> - не вариант. И то не факт, что поможет.
 > А кто мешает прописать в resolv.conf: search local. corp.domain. 
 > other.corp.domain. ?

resolvconf, кажется :)

Не помню, то ли там есть какая-то грабля, то ли я просто не доделал настройку 
resolvconf.

То ли затупил между "настроить dnsmasq" и "настроить resolvconf", когда
хачил скрипт для openconnect - у меня рабочий VPN выдает роутинги,
которые конфликтуют с домашними, и приходится аккуратно вырезать лишнее
из полученной инфы.

Re: VPN и корпоративный DNS

[Andrey Melnikoff]

Artem Chuprina <r...@lasgalen.net> wrote:
> Max Dmitrichenko -> Debian Russian Mailing List  @ Tue, 12 Jul 2016 01:28:23 
> +0300:

>  > Всем привет!

>  > Есть корпоративная сеть, куда юзер коннектится через OpenVPN. У юзера
>  > линукс. По dhcp он получает корпоративный DNS сервер, который либо
>  > умеет резолвить только корпоративные адреса, либо умеет и
>  > интернет-адреса, но это крайне не желательно.

>  > Возможно ли юзеру каким-то образом сконфигурить у себя резолвер так,
>  > чтобы за корпоративными адресами (по домену, например) он лез к
>  > корпоративному DNS-серверу, а за всеми остальными к DNS'у провайдера?

> Резолвер - нет. Свой кэширующий DNS-сервер - да. У меня так настроен dnsmasq.

> Засада, правда, есть: когда коллега на голубом глазу шлет тебе ссылку, в
> которой неквалифицированное имя хоста (http://wiki/path), надо, чтобы в
> этот момент домен по умолчанию у резолвера был корпоративным, что в
> рассматриваемой ситуации, подозреваю, как минимум неправильно, а скорее
> - не вариант. И то не факт, что поможет.
А кто мешает прописать в resolv.conf: search local. corp.domain. 
other.corp.domain. ?

Re: VPN и корпоративный DNS

[Victor Wagner]

On Tue, 12 Jul 2016 11:23:44 +0300
Artem Chuprina <r...@lasgalen.net> wrote:

 
> Резолвер - нет. Свой кэширующий DNS-сервер - да. У меня так настроен
> dnsmasq.
> 
> Засада, правда, есть: когда коллега на голубом глазу шлет тебе
> ссылку, в которой неквалифицированное имя хоста (http://wiki/path),
> надо, чтобы в этот момент домен по умолчанию у резолвера был
> корпоративным, что в рассматриваемой ситуации, подозреваю, как
> минимум неправильно, а скорее
> - не вариант. И то не факт, что поможет.

Там не домен, там список доменов, в которых производится поиск
неквалифицированных имен. Так что добавление при поднятии VPN
корпоративного домена в список search в resolv.conf может и помочь.
Если только неестественный интеллект браузера не окажется сильнее и не
начнет подставлять всякие .com раньше, чем резолвер вернет что найдет.

Re: VPN и корпоративный DNS

[VladVladow]

если запретить рекурсивные запросы из VPN-сетей bind9, не найдя у себя зону 
скажет клиенту идти и спросить у таких-то (прописаны в forwarders)

12.07.2016, 01:28, "Max Dmitrichenko" <dmitr...@gmail.com>:
> Есть корпоративная сеть, куда юзер коннектится через OpenVPN. У юзера
> линукс. По dhcp он получает корпоративный DNS сервер, который либо
> умеет резолвить только корпоративные адреса, либо умеет и
> интернет-адреса, но это крайне не желательно.
>
> Возможно ли юзеру каким-то образом сконфигурить у себя резолвер так,
> чтобы за корпоративными адресами (по домену, например) он лез к
> корпоративному DNS-серверу, а за всеми остальными к DNS'у провайдера?

Re: VPN и корпоративный DNS

[Artem Chuprina]

Max Dmitrichenko -> Victor Wagner  @ Tue, 12 Jul 2016 11:21:37 +0300:

 >> Кэширующий нейм-сервер надо. Про bind уже написали, а для решения этой
 >> задачи хватит и dnsmasq, которому можно рассказать про
 >> появление-исчезновение сервера для конкретной зоны (из client-connect
 >> скрипта openvpn) через dBus API.

 > Угу, посмотрю сюда. А есть тут знатоки network manager, которые знаю,
 > как его победить, чтобы он его не трогал /etc/resolv.conf при каждом
 > новом подключении к WiFi?

Он с пакетом resolvconf не уживается?  Вообще-то в его (resolvconf)
отсутствие /etc/resolv.conf меняют все, кому не лень, а не лень многим.

resolvconf тоже его трогает, но у него где-то как-то возможна тонкая
настройка.  И он, когда стоит - единая точка входа для всех желающих
поменять /etc/resolv.conf.

Re: VPN и корпоративный DNS

[Artem Chuprina]

Max Dmitrichenko -> Debian Russian Mailing List  @ Tue, 12 Jul 2016 01:28:23 
+0300:

 > Всем привет!

 > Есть корпоративная сеть, куда юзер коннектится через OpenVPN. У юзера
 > линукс. По dhcp он получает корпоративный DNS сервер, который либо
 > умеет резолвить только корпоративные адреса, либо умеет и
 > интернет-адреса, но это крайне не желательно.

 > Возможно ли юзеру каким-то образом сконфигурить у себя резолвер так,
 > чтобы за корпоративными адресами (по домену, например) он лез к
 > корпоративному DNS-серверу, а за всеми остальными к DNS'у провайдера?

Резолвер - нет. Свой кэширующий DNS-сервер - да. У меня так настроен dnsmasq.

Засада, правда, есть: когда коллега на голубом глазу шлет тебе ссылку, в
которой неквалифицированное имя хоста (http://wiki/path), надо, чтобы в
этот момент домен по умолчанию у резолвера был корпоративным, что в
рассматриваемой ситуации, подозреваю, как минимум неправильно, а скорее
- не вариант. И то не факт, что поможет.

Re: VPN и корпоративный DNS

[Max Dmitrichenko]

> Кэширующий нейм-сервер надо. Про bind уже написали, а для решения этой
> задачи хватит и dnsmasq, которому можно рассказать про
> появление-исчезновение сервера для конкретной зоны (из client-connect
> скрипта openvpn) через dBus API.

Угу, посмотрю сюда. А есть тут знатоки network manager, которые знаю,
как его победить, чтобы он его не трогал /etc/resolv.conf при каждом
новом подключении к WiFi?



-- 
With best regards
  Max Dmitrichenko

Re: VPN и корпоративный DNS

[Victor Wagner]

On Tue, 12 Jul 2016 01:28:23 +0300
Max Dmitrichenko <dmitr...@gmail.com> wrote:

> Всем привет!
> 
> Есть корпоративная сеть, куда юзер коннектится через OpenVPN. У юзера
> линукс. По dhcp он получает корпоративный DNS сервер, который либо
> умеет резолвить только корпоративные адреса, либо умеет и
> интернет-адреса, но это крайне не желательно.
> 
> Возможно ли юзеру каким-то образом сконфигурить у себя резолвер так,
> чтобы за корпоративными адресами (по домену, например) он лез к
> корпоративному DNS-серверу, а за всеми остальными к DNS'у провайдера?
> 

Кэширующий нейм-сервер надо. Про bind уже написали, а для решения этой
задачи хватит и dnsmasq, которому можно рассказать про
появление-исчезновение сервера для конкретной зоны (из client-connect
скрипта openvpn) через dBus API.

Re: VPN и корпоративный DNS

[Pavel Ammosov]

On Tue, Jul 12, 2016 at 01:28:23AM +0300, Max Dmitrichenko wrote:
> Возможно ли юзеру каким-то образом сконфигурить у себя резолвер так,
> чтобы за корпоративными адресами (по домену, например) он лез к
> корпоративному DNS-серверу, а за всеми остальными к DNS'у провайдера?

Ресолвер - нет, а с bind9 можно сделать через zone с type forward:

zone "example.com" {
type forward;
forwarders { xx.xx.xx.xx; yy.yy.yy.yy; };
};

Re: VPN и корпоративный DNS

[Eugene Berdnikov]

On Tue, Jul 12, 2016 at 01:28:23AM +0300, Max Dmitrichenko wrote:
> Всем привет!
> 
> Есть корпоративная сеть, куда юзер коннектится через OpenVPN. У юзера
> линукс. По dhcp он получает корпоративный DNS сервер, который либо
> умеет резолвить только корпоративные адреса, либо умеет и
> интернет-адреса, но это крайне не желательно.
> 
> Возможно ли юзеру каким-то образом сконфигурить у себя резолвер так,
> чтобы за корпоративными адресами (по домену, например) он лез к
> корпоративному DNS-серверу, а за всеми остальными к DNS'у провайдера?

 Нет. Классическая модель резолвинга имён этого не позволяет.

 Но если мотив этого вопроса заключается в безопасности, я не вижу
 особых препятствий тому, чтобы выдавать vpn-клиентам выделенные
 серверы dns, которые будут резолвить и внутренние, и внешние адреса,
 и при этом находиться за файрволом, в некотором подобии dmz.
-- 
 Eugene Berdnikov

VPN и корпоративный DNS

[Max Dmitrichenko]

Всем привет!

Есть корпоративная сеть, куда юзер коннектится через OpenVPN. У юзера
линукс. По dhcp он получает корпоративный DNS сервер, который либо
умеет резолвить только корпоративные адреса, либо умеет и
интернет-адреса, но это крайне не желательно.

Возможно ли юзеру каким-то образом сконфигурить у себя резолвер так,
чтобы за корпоративными адресами (по домену, например) он лез к
корпоративному DNS-серверу, а за всеми остальными к DNS'у провайдера?

-- 
With best regards
  Max Dmitrichenko

Re: Вопросы об организации DNS (взаимосвязь между организациями).

[Hleb Valoshka]

On 1/11/16, Oleksandr Gavenko  wrote:

> *anycast addressing* - специальной техникой добиваются что одному IP
> несколько
> хостов разрешается в зависимости от географии региона?

Если из сети А в сеть Б есть несколько маршрутов, то выбор  делается в
соответствии с метрикой маршрута, либо, если к нужному адресу ведут
маршруты в сети Б и В, при этом сеть В является частью Б, т.е. имеет
более длинную маску, то выбор делается в пользу маршрута В. При этом
совсем не обязательно, что все эти маршруты ведут в одну и ту же
реальную сеть, т.е. можно иметь одну и ту же подсеть в Европе и
Америке, но европейцы будут ходить на европейские сервера, а
американцы - на амерканские.
Это разруливается, если не ошибаюсь, на уровне BGP.

Re: Вопросы об организации DNS (взаимосвязь между организациями).

[Oleksandr Gavenko]

On 2016-01-11, Vasiliy P. Melnik wrote:

> Допустим он прокидает лично меня. Я смогу только в блоге и на форумах
> плакаться?
>
> в иканн
>  
Я читал что арбитром выступает ICANN, ниже вы пишите:

>
> https://en.wikipedia.org/wiki/WHOIS - говорит что это база кто каким 
> доменом
> или диапазоном IP владеет. Я так и не понял кто владелец этой базы.
>
> ну давай на пальцах:)

> есть ооо хостмастер, которое представляет владельца домена .ua , напрямую
> ооо хостмастер домены не регистрирует - для этого есть регистраторы, их
> достаточно много. Базу хуиза  ведет тоже ооо хостмастер, сервера зоны тоже
> они держат. Ну и спорты тоже в первую очередь через них решаются. Поэтому и
> говорю - в хуизе должна быть актуальная и верная инфромация, а не шлак в
> виде "зарегистрировано в интересах клиента". Все изменения в хуизе у
> хостмастера логируются, поэтому даже если регистратор захочет смухлевать -
> получит по наглой рыжей морде.
>
т.е. баз WHOIS много, у каждого провайдера TLDs своя. Далее:


> Мой регистратор позволяет менять whois записи через свой WEB интерфейс.
> По сути регистратор обладает правом менять записи как угодно.
>
> да , но лог изменений сохраняется, а регистратор в любом случае получит 
> трындюлей.
>  

Вот тут я понял где заблуждался. У меня такие мысли что с DNS разбирался
недавно и исторические детали прошли мимо меня.

Я не верно представлял о количестве и отношениях меджу провайдерами DNS и
регистраторами DNS. Сейчас когда расплодилось куча gTLDs провайдеры пытаются
продавать/регистирровать сами. Раньше же (во времена .com/.org) регистраторы
только собирали денюжку с регистраторов и не заморачивались с оконечными
клиентами.

Задача регистратора - получить денюжку от клиента, собрать данные для WHOIS от
клиента (email, телефон, адрес и от условий регистрации - паспорт, свид на
торговую марку и т.д.) и собрать данные для NS от клиента (адреса
Authoritative NS и возможно предложить клиенту воспользоваться их
Authoritative NS).

Я так понимаю что есть 3 вида споров. Между клиентами (например когда продаешь
домен) - разруливает регистратор. Проблемы с регистратором (например переход к
другому регистратору), тогда арбитром выступает провайдер и на помощь приходит
база WHOIS. Или проблемы с провайдером и тогда арбитром выступает ICANN.

> Продажа домена сводится к смене email в WHOIS?
>
> ну грубо говоря да - и остальных реквизитов тоже. Только мыло просто так не
> меняется - надо заявление писать, подтверждать владение. У нас это копия
> паспорта и письмо бумажное.  
>
Это для .ru / .ua? Мне интересно также что происходит для .com / .org...

> Это получается что реселер обладает правом менять ссылку на мой Authority 
> NS у
> Registry Provider а клиент напрямую нет?
>
> так же как жек может у тебя дома отключить электричество, допустим.
>  
Классная аналогия ))

> Выходит что реселеры втихаря передают между собою это право не позволяя
> покупателю напрямую общаться с Registry Provider?
>
> почему втихаря? я работал на провадере, который успешно подох - народ
> позабирал свои домены. Это бизнес - никому проблемы не нужны. Почитай про
> sex.com - там тоже целая история была, подменили владельца. Но в итоге
> первоначальный владелец отсудил домен. С тех пор уже столько прошло времени
> и столько раз менялись правила, что такая ситуация сложно повторимая.

Провайдер или регистратор? Смерть провайдера мне кажется экстраординарным
событием...

Если регистратор - что были вывишены инструкции как перейти к другому
регистратору? Или всех скопом перенесли к другому регистратору?


Спасибо за ответы, многое прояснилось! Мне то нужно всего домашнюю страничку
хостить. Но теперь появилась уверенность, можно будет другим если что
подсказать...

-- 
http://defun.work/

Re: Вопросы об организации DNS (взаимосвязь между организациями).

[Vasily Ivanov]

On 2016-01-11 0111 (+0200), Oleksandr Gavenko wrote:

*anycast addressing* - специальной техникой добиваются что одному IP несколько
хостов разрешается в зависимости от географии региона?


Нет, один и тот же префикс анонсируется с разных точек, а на стороне
провайдера выбирается один из маршрутов:

https://en.wikipedia.org/wiki/Anycast#Details

Re: Вопросы об организации DNS (взаимосвязь между организациями).

[Vasiliy P. Melnik]

11 января 2016 г., 12:41 пользователь Oleksandr Gavenko <gaven...@gmail.com>
написал:

> On 2016-01-11, Vasiliy P. Melnik wrote:
>
> > Допустим он прокидает лично меня. Я смогу только в блоге и на форумах
> > плакаться?
> >
> > в иканн
> >
> Я читал что арбитром выступает ICANN, ниже вы пишите:
>

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


> т.е. баз WHOIS много, у каждого провайдера TLDs своя. Далее:
>

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

ну хз - в зоне ua , да. Потому как владельцы зоны .ua два частных лица (в
крайнем случае так раньше было), и вот они, чтобы не заморачиваться решили
скопировать принцип работы икана с другими регистраторами. Тупо под копирку
- сделали компанию, она правда коммерческая, но отношения у нее с
регистраторами полностью идентичны - нельзя прийти в оо хостмастери у них
зарегистрировать домен, они дают на выбор регистраторов.

Вот тут я понял где заблуждался. У меня такие мысли что с DNS разбирался
> недавно и исторические детали прошли мимо меня.
>

оставь ты в покое настройку днс-ов :) обслуживание нс-ов обычно входит в
стоимость регистрации и это головная боль регистратора.


> Я не верно представлял о количестве и отношениях меджу провайдерами DNS и
> регистраторами DNS. Сейчас когда расплодилось куча gTLDs провайдеры
> пытаются
> продавать/регистирровать сами. Раньше же (во времена .com/.org)
> регистраторы
> только собирали денюжку с регистраторов и не заморачивались с оконечными
> клиентами.
>
> Задача регистратора - получить денюжку от клиента, собрать данные для
> WHOIS от
> клиента (email, телефон, адрес и от условий регистрации - паспорт, свид на
> торговую марку и т.д.) и собрать данные для NS от клиента (адреса
> Authoritative NS и возможно предложить клиенту воспользоваться их
> Authoritative NS).
>
> Я так понимаю что есть 3 вида споров. Между клиентами (например когда
> продаешь
> домен) - разруливает регистратор. Проблемы с регистратором (например
> переход к
> другому регистратору), тогда арбитром выступает провайдер и на помощь
> приходит
> база WHOIS. Или проблемы с провайдером и тогда арбитром выступает ICANN.
>

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

Клиент не может напрямую в икане зарегистрировать домен, там какое-то
условие работы организации. Клиент регистрирует домен у регистратора.
Регистратор конечно тоже может работать через посредников, но смысла в этом
особо нету, то есть например у меня есть ресселерский аккаунт у моего
регистратора, но я не продаю домены - мне просто удобно видеть в одной
панели все домены, а домены должны быть зарегистрированы за разными
владельцами.

Высшая инстанция - иканн конечно, но регистратор не заинтересован в
нарушении правил работы, потому как это их бизнес. У меня например
получилась косяковая ситуация с доменом - компания ликвидирована, печать
уничтожена, а домен за компанией остался. Регистратор сказал -
перегистрировать на другую компанию домен мы не можем, но платить через
банк наличкой вы можете, если вас устраивает - платите. Как итог - домен
живой, но если будет разбирательство какое-то - регистратор не при делах,
потому как домен формально остался за той же конмпанией.


> > Продажа домена сводится к смене email в WHOIS?
> >
> > ну грубо говоря да - и остальных реквизитов тоже. Только мыло просто так
> не
> > меняется - надо заявление писать, подтверждать владение. У нас это копия
> > паспорта и письмо бумажное.
> >
> Это для .ru / .ua? Мне интересно также что происходит для .com / .org...
>

это для юа, но для остальных я думаю примерно все та же, за исключением
нюансов каких-нибудь, типа торговой марки для регистрации юа.


>
> Провайдер или регистратор? Смерть провайдера мне кажется экстраординарным
> событием...
>
> Если регистратор - что были вывишены инструкции как перейти к другому
> регистратору? Или всех скопом перенесли к другому регистратору?
>

ничего не мешает провайдеру быть регистратором.

Re: Вопросы об организации DNS (взаимосвязь между организациями).

[Anatoly Pugachev]

On Mon, Jan 11, 2016 at 2:11 AM, Oleksandr Gavenko <gaven...@gmail.com> wrote:
>> On 1/10/16, Oleksandr Gavenko <gaven...@gmail.com> wrote:
>>> 1) Есть 13 Root NS и судя по https://en.wikipedia.org/wiki/Root_name_server
>>> все они в США.
>>
>> На самом деле, их около полусотни разбросанных по всему миру.
>
> Ok, я внимательней почитал wiki:
>
>   As of July 2015, there are 13 root name servers specified, with names in the
>   form letter.root-servers.net, where letter ranges from A to M. This does not
>   mean there are 13 physical servers; each operator uses redundant computer
>   equipment to provide reliable service even if failure of hardware or
>   software occurs. Additionally, nine of the servers operate in multiple
>   geographical locations using a routing technique called anycast addressing,
>   providing increased performance and even more fault tolerance.
>
> *anycast addressing* - специальной техникой добиваются что одному IP несколько
> хостов разрешается в зависимости от географии региона?
>
> Вот откопал:
>
>   https://tools.ietf.org/html/rfc3258
> Distributing Authoritative Name Servers via Shared Unicast Addresses
>
> Как оно работает если показывать на пальцах или простой аналогией?

shared unicast это вероятно anycast. простая схема работы тут [1]
если рассматривать именно эту схему, например, то можно предположить так
R1 - россия
R2 + R3 - европа
R4 + R5 + R6 - сша

1. http://pingbin.com/2011/03/what-is-any-cast-dns/

Вопросы об организации DNS (взаимосвязь между организациями).

[Oleksandr Gavenko]

Общее представление о DNS я получил от:

 * 
http://royal.pingdom.com/2009/06/08/a-visual-explanation-of-how-dns-lookups-work/
 * http://dyn.com/blog/dns-why-its-important-how-it-works/

Вот как я понимаю работу DNS...

getaddrinfo(3) по имени хоста в зависимости от настроек /etc/nsswitch.conf
считывает данные /etc/resolv.conf и по определенному протоколу общается с т.н.
recursive name server.

Recursive name server у меня публичный от Google (8.8.8.8), но его обычно
предоставляет провайдер через DHCP или администратор корпоративной сети.

Узнать свой Recursive name server можно по:

  $ cat /etc/resolve.conf

Recursive NS долбит Root NS. Если ты ищещ ``google.com``, то Root NS скажет
где база для ``com`` TLDs NS (top level domain). TLDs NS ответит где NS для
Authoritative NS для определенной зоны (example.com).

Список Recursive NS можно получить по:

  $ nslookup -type=ns .
  .   nameserver = b.root-servers.net.
  .   nameserver = j.root-servers.net.
  .   nameserver = f.root-servers.net.
...  

Список серверов, отвечающих за разрешение в TLD, например com, можно получить
по:

  $ nslookup -type=ns com
  com   nameserver = e.gtld-servers.net.
  com   nameserver = j.gtld-servers.net.
  com   nameserver = m.gtld-servers.net.
...

Итого когда ищется google.com.ua происходит серия:

  $ dig NS .
  .   10362   IN  NS  c.root-servers.net.

  $ dig @c.root-servers.net NS ua
  ua. 172800  IN  NS  he1.ns.ua.

  $ dig @he1.ns.ua NS com.ua
  com.ua. 72072   IN  NS  k.ns.com.ua.

  $ dig @k.ns.com.ua NS google.com.ua
  google.com.ua.  86400   IN  NS  ns2.google.com.

  $ dig @ns2.google.com A google.com.ua
  google.com.ua.  300 IN  A   173.194.113.15

Понятно что Recursive NS, TLDs NS и Authoritative NS кешируют запросы. Но
после TTL все происходит как описано выше.


Когда регистрируется имя google.com.ua следует обращаться к владельцу
``com.ua`` или реселеру, у которого есть договор с владельцем ``com.ua``.

По итогу покупки продавец спросит меня - где твой NS? Их требуют не менее 2
шт, разнесенные на разных хостах.

Зачастую для удобства продавец содержит сервера разрешения имен. Потому он
попросит IP адреса - как твоему имени назначить DNS записи.



Если что то не так - буду благодарен за уточнения...

Теперь вопросы.

1) Есть 13 Root NS и судя по https://en.wikipedia.org/wiki/Root_name_server
все они в США.

Вся котоквасия вокруг gTLDs доменов - это просто дискусии кто получит записи в
Root NS, как например:

  https://www.iana.org/domains/root/db/law.html

и будет рубить бабло с регистрации?

2) Мельком вычитывал что реселеры покупают право вносить правки в TLDs NS?
Вроде сумма в 2500$ единоразово и 4000$ ежегодно для получения такого права...

3) Как подтверждается право владения доменом?

Я при регистрации указал фейковый апрес организации, но мое мыло, телефонный
номер и платежная карта прошли верификацию.

Хотя эти данные получены регистратором Minds + Machines - никаких документов
от регистратора я не получил. Есть много заверений в соглашениях пользователя
- что они будух добросовестно выполнять обязательства и я являюсь
собственником доменного имени пока плачу.

Если возникают споры - кто арбитр? Какими я согу воспользоваться
доказательствами права собственности? У меня есть списание с банковского
счета, SMS в телефоне и письмо в gmail

Выходит что мне придется полагаться только на порядочность регистратора?

4) Есть ли смысл обращаться к ресселеру за покупкой DNS записи?

5) Нужно ли мне заводить совственные сервера имен?

Я сейчас использую предоставляемые продавцом DNS имен через WEB-форму,
расписав A записи к префиксам:

  www. blog. git. hg.

Не глупо ли держать NS для разрешения таких префиксов на том же хосте куда
ведут сами префиксы?

Можно ли как то улизнуть и отделаться только мастер сервером без слейв?

Кокие от этого могут быть технич последствия?

6) nslookup/dig примеры показывали сервера имен в виде записей:

  .   nameserver = b.root-servers.net.

Почему не IP?

  $ nslookup b.root-servers.net
  Address: 192.228.79.201

Не будет проблемы курицы и яйца? Что бы разрешить имя тебе предлагают другое
имя, и т.д.?

Или утилиты оперируют с IP адресами, а пользователю показывают имена?

-- 
http://defun.work/

Re: Вопросы об организации DNS (взаимосвязь между организациями).

[Vasiliy P. Melnik]

>
> 1) Есть 13 Root NS и судя по
> https://en.wikipedia.org/wiki/Root_name_server
> все они в США.
>
> Вся котоквасия вокруг gTLDs доменов - это просто дискусии кто получит
> записи в
> Root NS, как например:
>
>   https://www.iana.org/domains/root/db/law.html
>
> и будет рубить бабло с регистрации?
>


ну есть иана - она рулюет, могу ошибаться, но скорее всего некоммерческая


> 2) Мельком вычитывал что реселеры покупают право вносить правки в TLDs NS?
> Вроде сумма в 2500$ единоразово и 4000$ ежегодно для получения такого
> права...
>

правки куда? яндекс выкупил зону яндекс за 17 в год, то есть теперь
яндекс может себе позволить написать

http://yandex/

3) Как подтверждается право владения доменом?
>

твоими отношениями с регистратором, ты принимаешь условия договора, когда
домен регистрируешь. Регистратор тоже ведь должен на кого-то домен
повесить. Пока проблем нет - все равно на кого домен зарегистрирован, но
если вдруг чего - как доказывать?


> Выходит что мне придется полагаться только на порядочность регистратора?
>

и да, и нет  - регистратор тоже по договору работает. Но поэтому то и надо
вписывать в хуиз реальные данные, а не данные регистратора - как многие это
любят делать.


> 4) Есть ли смысл обращаться к ресселеру за покупкой DNS записи?
>

в смысле? регистратор и есть ресселер

5) Нужно ли мне заводить совственные сервера имен?


чаще всего нет, обычно домен продается с обслуживанием нс-ов


> Я сейчас использую предоставляемые продавцом DNS имен через WEB-форму,
>
расписав A записи к префиксам:
>
>   www. blog. git. hg.
>
> Не глупо ли держать NS для разрешения таких префиксов на том же хосте куда
> ведут сами префиксы?
>

а тебе какая разница? да и откуда ты знаешь схему работы регистратора,
может у них на выходе какая-то пикса стоит и просто форвардит запросы на
разные сервера.


> Можно ли как то улизнуть и отделаться только мастер сервером без слейв?
>

а смысле? есть куча бесплатных секондари, скажу даже больше - есть
бесплатные праймери


> Кокие от этого могут быть технич последствия?
>

ну не будет работать резолвинг твоей зоны :)


> 6) nslookup/dig примеры показывали сервера имен в виде записей:
>
>   .   nameserver = b.root-servers.net.
>
> Почему не IP?
>

потому шо нс-записи могут быть только имена, как и cname


> Не будет проблемы курицы и яйца? Что бы разрешить имя тебе предлагают
> другое
> имя, и т.д.?
>

ну так придумали протокол - идеального очень мало в интернете :)


> Или утилиты оперируют с IP адресами, а пользователю показывают имена?

странный вопрос - как утилиту написали, так она и работает

Re: Вопросы об организации DNS (взаимосвязь между организациями).

[Anatoly Pugachev]

2016-01-10 23:38 GMT+03:00 Oleksandr Gavenko :
> Итого когда ищется google.com.ua происходит серия:
>
>   $ dig NS .
>   .   10362   IN  NS  c.root-servers.net.
>
>   $ dig @c.root-servers.net NS ua
>   ua. 172800  IN  NS  he1.ns.ua.
>
>   $ dig @he1.ns.ua NS com.ua
>   com.ua. 72072   IN  NS  k.ns.com.ua.
>
>   $ dig @k.ns.com.ua NS google.com.ua
>   google.com.ua.  86400   IN  NS  ns2.google.com.
>
>   $ dig @ns2.google.com A google.com.ua
>   google.com.ua.  300 IN  A   173.194.113.15

попробуйте dig +trace google.com.ua

Re: Вопросы об организации DNS (взаимосвязь между организациями).

[Hleb Valoshka]

On 1/10/16, Oleksandr Gavenko  wrote:
> 1) Есть 13 Root NS и судя по https://en.wikipedia.org/wiki/Root_name_server
> все они в США.

На самом деле, их около полусотни разбросанных по всему миру.

Re: Вопросы об организации DNS (взаимосвязь между организациями).

[Anatoly Pugachev]

2016-01-11 1:49 GMT+03:00 Hleb Valoshka <375...@gmail.com>:
> On 1/10/16, Oleksandr Gavenko  wrote:
>> 1) Есть 13 Root NS и судя по https://en.wikipedia.org/wiki/Root_name_server
>> все они в США.
>
> На самом деле, их около полусотни разбросанных по всему миру.

можно покликать, если javascript включен
http://www.root-servers.org/

Re: Вопросы об организации DNS (взаимосвязь между организациями).

[Oleksandr Gavenko]

On 2016-01-10, Vasiliy P. Melnik wrote:

> 2) Мельком вычитывал что реселеры покупают право вносить правки в TLDs NS?
> Вроде сумма в 2500$ единоразово и 4000$ ежегодно для получения такого 
> права...
>
> правки куда? яндекс выкупил зону яндекс за 17 в год, то есть теперь 
> яндекс может себе позволить написать
>
> http://yandex/
>
Я читал интересную статью про Google и их захват новых gTLDs:

  http://sealedabstract.com/rants/google-our-patron-saint-of-the-closed-web/

Я смотрел на цены для новых gTLDs и там реально рубают деньги:

  emacs.cool 40$
  emacs.today 25$
  emacs.photography 25$
  emacs.technology 40$
  emacs.ninja 40$
  ...

На https://godaddy.com/domains/searchresults.aspx удобно сравнивать.

> 3) Как подтверждается право владения доменом?
>
> твоими отношениями с регистратором, ты принимаешь условия договора, когда
> домен регистрируешь. Регистратор тоже ведь должен на кого-то домен повесить.
>
Допустим он прокидает лично меня. Я смогу только в блоге и на форумах
плакаться?

> Выходит что мне придется полагаться только на порядочность регистратора?
>
> и да, и нет  - регистратор тоже по договору работает. Но поэтому то и надо
> вписывать в хуиз реальные данные, а не данные регистратора - как многие это
> любят делать.
>
https://en.wikipedia.org/wiki/WHOIS - говорит что это база кто каким доменом
или диапазоном IP владеет. Я так и не понял кто владелец этой базы.

Мой регистратор позволяет менять whois записи через свой WEB интерфейс.

По сути регистратор обладает правом менять записи как угодно.

Вот тут говорится о 60 днях для защиты от увода домена:

  https://en.wikipedia.org/wiki/Domain_hijacking#Prevention

> 4) Есть ли смысл обращаться к ресселеру за покупкой DNS записи?
>
> в смысле? регистратор и есть ресселер 
>
Я составил для себя модель что есть владельцы gTLDs и есть реселеры.

Для своей домашней странички на 

  http://icannwiki.com/.work

я вычитал что:

  Registry Provider:Minds + Machines

и покупку свершал через их сайт: https://www.mindsandmachines.com/

У меня сложилось впечатление что суть покупки заключается во внесении адреса
NS покупателя в базу TLDs NS провайдера (что бы он отыечал на ns запрос куда
мне надо). И еще внесение записи в WhoIs - но я вообще не понял что это такое.

Продажа домена сводится к смене email в WHOIS?

И что означает перенос домена с одного селлера к другому? Я пролистывал на
форумах что некоторые продавцы доменов отказвыаются что то там передавать
владельцу при переезде и почему токуча проблем у людей.

Это получается что реселер обладает правом менять ссылку на мой Authority NS у
Registry Provider а клиент напрямую нет?

Выходит что реселеры втихаря передают между собою это право не позволяя
покупателю напрямую общаться с Registry Provider?

Мне кажется абсурдом мой домен в .work передать куда то, например в GoDaddy.
Какие байтики мне нудно будет перенести с Minds+machines?

> Можно ли как то улизнуть и отделаться только мастер сервером без слейв?
>
> а смысле? есть куча бесплатных секондари, скажу даже больше - есть бесплатные 
> праймери
>  
Я посмотрел на ISPsystem от https://ns3.gmhost.hosting/, посмотрел на своего
провайдера, и еще на https://my.freenom.com/

У них есть возможность добавлять записи A, , MX, TXT, CNAME.

Этого ж достаточно для всего?

Т.е. нет необходимости в своих NS, разве что если хочется консолидировать
настройки в текстовом файле bind вместо WEB-интерфейсов разных консолек у
NS провайдеров?

-- 
http://defun.work/

Re: Вопросы об организации DNS (взаимосвязь между организациями).

[Oleksandr Gavenko]

On 2016-01-11, Hleb Valoshka wrote:

> On 1/10/16, Oleksandr Gavenko  wrote:
>> 1) Есть 13 Root NS и судя по https://en.wikipedia.org/wiki/Root_name_server
>> все они в США.
>
> На самом деле, их около полусотни разбросанных по всему миру.

Ok, я внимательней почитал wiki:

  As of July 2015, there are 13 root name servers specified, with names in the
  form letter.root-servers.net, where letter ranges from A to M. This does not
  mean there are 13 physical servers; each operator uses redundant computer
  equipment to provide reliable service even if failure of hardware or
  software occurs. Additionally, nine of the servers operate in multiple
  geographical locations using a routing technique called anycast addressing,
  providing increased performance and even more fault tolerance.

*anycast addressing* - специальной техникой добиваются что одному IP несколько
хостов разрешается в зависимости от географии региона?

Вот откопал:

  https://tools.ietf.org/html/rfc3258
Distributing Authoritative Name Servers via Shared Unicast Addresses

Как оно работает если показывать на пальцах или простой аналогией?

-- 
http://defun.work/

Re: Вопросы об организации DNS (взаимосвязь между организациями).

[Vasiliy P. Melnik]

11 января 2016 г., 1:05 пользователь Oleksandr Gavenko 
написал:

> On 2016-01-10, Vasiliy P. Melnik wrote:
>
> > 2) Мельком вычитывал что реселеры покупают право вносить правки в
> TLDs NS?
> > Вроде сумма в 2500$ единоразово и 4000$ ежегодно для получения
> такого права...
> >
> > правки куда? яндекс выкупил зону яндекс за 17 в год, то есть теперь
> яндекс может себе позволить написать
> >
> > http://yandex/
> >
> Я читал интересную статью про Google и их захват новых gTLDs:
>
>
> http://sealedabstract.com/rants/google-our-patron-saint-of-the-closed-web/
>
> Я смотрел на цены для новых gTLDs и там реально рубают деньги:
>
>   emacs.cool 40$
>   emacs.today 25$
>   emacs.photography 25$
>   emacs.technology 40$
>   emacs.ninja 40$
>

это домены второго уровня - я писал о домене первого уровня


> Допустим он прокидает лично меня. Я смогу только в блоге и на форумах
> плакаться?
>

в иканн


> https://en.wikipedia.org/wiki/WHOIS - говорит что это база кто каким
> доменом
> или диапазоном IP владеет. Я так и не понял кто владелец этой базы.
>

ну давай на пальцах:)
есть ооо хостмастер, которое представляет владельца домена .ua , напрямую
ооо хостмастер домены не регистрирует - для этого есть регистраторы, их
достаточно много. Базу хуиза  ведет тоже ооо хостмастер, сервера зоны тоже
они держат. Ну и спорты тоже в первую очередь через них решаются. Поэтому и
говорю - в хуизе должна быть актуальная и верная инфромация, а не шлак в
виде "зарегистрировано в интересах клиента". Все изменения в хуизе у
хостмастера логируются, поэтому даже если регистратор захочет смухлевать -
получит по наглой рыжей морде.

Мой регистратор позволяет менять whois записи через свой WEB интерфейс.
> По сути регистратор обладает правом менять записи как угодно.
>

да , но лог изменений сохраняется, а регистратор в любом случае получит
трындюлей.


> Вот тут говорится о 60 днях для защиты от увода домена:
>

это называется холд - если ты вдруг забыл продлить домен, то в течение 60
дней домен никто не сможет  выкупить.

Продажа домена сводится к смене email в WHOIS?
>

ну грубо говоря да - и остальных реквизитов тоже. Только мыло просто так не
меняется - надо заявление писать, подтверждать владение. У нас это копия
паспорта и письмо бумажное.


> И что означает перенос домена с одного селлера к другому? Я пролистывал на
> форумах что некоторые продавцы доменов отказвыаются что то там передавать
> владельцу при переезде и почему токуча проблем у людей.
>

потому что пользоваться не умеют, там ничего сложного


> Это получается что реселер обладает правом менять ссылку на мой Authority
> NS у
> Registry Provider а клиент напрямую нет?
>

так же как жек может у тебя дома отключить электричество, допустим.


> Выходит что реселеры втихаря передают между собою это право не позволяя
> покупателю напрямую общаться с Registry Provider?
>

почему втихаря? я работал на провадере, который успешно подох - народ
позабирал свои домены. Это бизнес - никому проблемы не нужны. Почитай про
sex.com - там тоже целая история была, подменили владельца. Но в итоге
первоначальный владелец отсудил домен. С тех пор уже столько прошло времени
и столько раз менялись правила, что такая ситуация сложно повторимая.

Мне кажется абсурдом мой домен в .work передать куда то, например в GoDaddy.
> Какие байтики мне нудно будет перенести с Minds+machines?
>

без понятия - надо читать в годеди, тебе надо - ты и читай :) У нас надо
бумажное заявление нести


> Я посмотрел на ISPsystem от https://ns3.gmhost.hosting/, посмотрел на
> своего
> провайдера, и еще на https://my.freenom.com/
>
> У них есть возможность добавлять записи A, , MX, TXT, CNAME.
>
> Этого ж достаточно для всего?
>

а что-то еще осталось ?:)


> Т.е. нет необходимости в своих NS, разве что если хочется консолидировать
> настройки в текстовом файле bind вместо WEB-интерфейсов разных консолек у
> NS провайдеров?


так если надо у многих есть импорт-экспорт, у тебя там что 500 записей
что-ли? Переносил нс-ы на клоудфлейр - никто не умер, но покликал на
кнопочки, заодно почистил зоны.

Re: Вопросы об организации DNS (взаимосвязь между организациями).

[Oleksandr Gavenko]

On 2016-01-10, Anatoly Pugachev wrote:

> 2016-01-10 23:38 GMT+03:00 Oleksandr Gavenko :
>> Итого когда ищется google.com.ua происходит серия:
>>
>>   $ dig NS .
>>   .   10362   IN  NS  c.root-servers.net.
>>
>>   $ dig @c.root-servers.net NS ua
>>   ua. 172800  IN  NS  he1.ns.ua.
>>
>>   $ dig @he1.ns.ua NS com.ua
>>   com.ua. 72072   IN  NS  k.ns.com.ua.
>>
>>   $ dig @k.ns.com.ua NS google.com.ua
>>   google.com.ua.  86400   IN  NS  ns2.google.com.
>>
>>   $ dig @ns2.google.com A google.com.ua
>>   google.com.ua.  300 IN  A   173.194.113.15
>
> попробуйте dig +trace google.com.ua
>
Wow! Я расписал команды как догадку. "dig +trace" плюет тоже самое!!

И там есть информация о времени выполнения разрешения. Это пригодится для
разборов почему страницы долго загружаются.

Необычно было увидеть что корневые NS извлекались из рекурсивного NS:

  .   9539IN  NS  f.root-servers.net.
  .   9539IN  NS  j.root-servers.net.
  ;; Received 397 bytes from 8.8.4.4#53(8.8.4.4) in 668 ms

Т.е. корневые NS не вшиты жестко в dig...

-- 
http://defun.work/

Re: Как работает локальный DNS кеш?

[Oleksandr Gavenko]

On 2015-11-23, Eugene Berdnikov wrote:

>> которые считывает GLib. Как я понял GLib также умеет общаться с DNS серверами
>> (так как это делает dig, есть ощущение что nslookup использует
>> getaddrinfo(3)).
>
>  В "ltrace nslookup localhost |& fgrep addr" ничего не ловится,
>  значит, getaddrinfo(3) там не используется. Было бы странно для
>  писателей bind9 использовать такие вызовы, ибо их модули
>  извлекают из пакетов гораздо больше информации, которую через
>  API для getaddrinfo получить никак невозможно. С другой стороны,
>  от gethostbyname/getaddrinfo невозможно оторвать просмотр hosts
>  и прочей описанной в nsswitch.conf хни, а dig/nslookup делают
>  исключительно обращения к dns, и ничего более. Поэтому nslookup
>  просто не может работать через getaddrinfo(3).
>
Ясно, я забыл что nslookup из проекта BIND.

>> У меня только сомнения по поводу наличия кода в GLibc работающего с DNS
>> серверами на подобии как это делает dig.
>
>  В чём подобие-то? В glibc есть лишь резолвер, а dig имеет гораздо более
>  широкий функционал.

Я не знал в том что glibc содержит частичную реализацию
протокола (как Вы сказали резолвер):

  https://www.ietf.org/rfc/rfc1035.txt

Было удивительно что glibc не просто прослойка к ядру, но также выполняет
прикладные сервисы как разрешение имен.

Я наивно полагал что этим занимается ядро или сторонняя служба...

-- 
Best regards!

Re: Как работает локальный DNS кеш?

[Oleksandr Gavenko]

On 2015-11-22, Artem Chuprina wrote:

> resolvconf у меня живет весьма неплохо, но я не пользуюсь connman/nm.
> Пользуюсь wicd, и про него знаю, что он сам эту информацию не трогает,
> ею занимается dhclient (или кто там у тебя работает с DHCP) в связке с
> resolvconf.
>
> И кэшем работает dnsmasq.  На домашнем сервере - bind9, и ему приходится
> вручную добавлять скрипт, звездочка в документации неспроста.  А с
> dnsmasq работает из коробки.

В общем прояснилось, еще почитал:

  GETADDRINFO(3)
  `info libc "Name Service Switch"'
  http://www.tldp.org/LDP/nag2/x-087-2-resolv.library.html

Итого getaddrinfo(3), gethostbyname(3) встроены в GLib.

Есть ряд файлов настроек:

  /etc/host.conf
  /etc/hosts
  /etc/resolv.conf
  /etc/nsswitch.conf

которые считывает GLib. Как я понял GLib также умеет общаться с DNS серверами
(так как это делает dig, есть ощущение что nslookup использует
getaddrinfo(3)).

Кеширование DNS запросов может быть сделано либо в GLib, либо в приложении,
либо прописыванием localhost в /etc/resolv.conf и поднятием локального DNS
сервера кеша.

dhclient по успешному выполнению вызывает тригеры, пример доступной информации
в дригере в файле:

  /etc/dhcp/dhclient-enter-hooks.d/debug

for prefix in '' 'cur_' 'new_' 'old_'; do
for basevar in reason interface medium alias_ip_address \
   ...
   domain_name domain_search domain_name_servers \
   ...
   dhcp6_domain_search dhcp6_name_servers ; do
var="${prefix}${basevar}"
eval "content=\$$var"
echo "$var='${content}'" >> /tmp/dhclient-script.debug

resolvconf поставляет свой хук /etc/dhcp/dhclient-enter-hooks.d/resolvconf и
затем сообщает кеширующему DNS серверу о новых настройках.

У меня только сомнения по поводу наличия кода в GLibc работающего с DNS
серверами на подобии как это делает dig.

-- 
Best regards!

Re: Как работает локальный DNS кеш?

[Eugene Berdnikov]

On Mon, Nov 23, 2015 at 08:13:12PM +0200, Oleksandr Gavenko wrote:
> В общем прояснилось, еще почитал:
> 
>   GETADDRINFO(3)
>   `info libc "Name Service Switch"'
>   http://www.tldp.org/LDP/nag2/x-087-2-resolv.library.html
> 
> Итого getaddrinfo(3), gethostbyname(3) встроены в GLib.

 Не в Glib, а в glibc. Под "glib" обычно понимают прикладную библиотеку
 Гнома, а glibc есть базовая библиотека всего линуксового рантайма,
 включающая интерфейсы к вызовам ядра.

> которые считывает GLib. Как я понял GLib также умеет общаться с DNS серверами
> (так как это делает dig, есть ощущение что nslookup использует
> getaddrinfo(3)).

 В "ltrace nslookup localhost |& fgrep addr" ничего не ловится,
 значит, getaddrinfo(3) там не используется. Было бы странно для
 писателей bind9 использовать такие вызовы, ибо их модули
 извлекают из пакетов гораздо больше информации, которую через
 API для getaddrinfo получить никак невозможно. С другой стороны,
 от gethostbyname/getaddrinfo невозможно оторвать просмотр hosts
 и прочей описанной в nsswitch.conf хни, а dig/nslookup делают
 исключительно обращения к dns, и ничего более. Поэтому nslookup
 просто не может работать через getaddrinfo(3).

> У меня только сомнения по поводу наличия кода в GLibc работающего с DNS
> серверами на подобии как это делает dig.

 В чём подобие-то? В glibc есть лишь резолвер, а dig имеет гораздо более
 широкий функционал.
-- 
 Eugene Berdnikov

Re: Как работает локальный DNS кеш?

[Eugene Berdnikov]

On Mon, Nov 23, 2015 at 09:44:17PM +0200, Oleksandr Gavenko wrote:
> Было удивительно что glibc не просто прослойка к ядру, но также выполняет
> прикладные сервисы как разрешение имен.

 В libc традиционно есть масса функций, никак не завязанных на вызовы ядра.
 Например, обработка строк: sscanf, sprintf, strchr, strtok, index и т.д.

> Я наивно полагал что этим занимается ядро или сторонняя служба...

 В ядро этот функционал помещать совершенно незачем. Три главные задачи
 ядра -- предоставление интерфейса к железу, деление общих ресурсов и
 разграничение доступа, а здесь ничего из этого не требуется.
-- 
 Eugene Berdnikov

Re: Как работает локальный DNS кеш?

[Oleksandr Gavenko]

On 2015-11-22, Oleksandr Gavenko wrote:

> Как менеджеры сетевых подключений (connman, wicd, NetworkManager) знают о том
> что нужно передать информацию от DHCP к DNS-кешу? На каждый нужно изучать
> документацию?
>
> Или например не трогать /etc/resolve.conf?
>
> И нужен ли мне локальный DNS кеш?

Пока не знаю ответы, но есть пакет resolvconf, который дружит с многими
другисми пакетами Debian, из resolvconf-1.78/README:

  Resolvconf works with most interface configurers in Debian ('(*)' below
  meaning "with some manual configuration"): 

 isc-dhcp-client, dhcpcd, pump, udhcpc
 ppp
 ifupdown
 network-manager

  DNS caches:

 bind9(*), djbdns dnscache, dnsmasq, nscd, pdnsd

  DNS recursing nameservers:

 bind9(*), pdns-recursor(*), unbound

  and with any program that uses a DNS client library that consults
  /etc/resolv.conf to obtain its list of nameservers:

 the GNU C Library resolver library
 adns
 the djbdns resolver library
 FireDNS

В пакете openresolv поменьше документации.

-- 
Best regards!

Re: Как работает локальный DNS кеш?

[Artem Chuprina]

Oleksandr Gavenko -> debian-russian@lists.debian.org  @ Sun, 22 Nov 2015 
19:06:38 +0200:

 >> Как менеджеры сетевых подключений (connman, wicd, NetworkManager) знают о 
 >> том
 >> что нужно передать информацию от DHCP к DNS-кешу? На каждый нужно изучать
 >> документацию?
 >>
 >> Или например не трогать /etc/resolve.conf?
 >>
 >> И нужен ли мне локальный DNS кеш?

 OG> Пока не знаю ответы, но есть пакет resolvconf, который дружит с многими
 OG> другисми пакетами Debian, из resolvconf-1.78/README:

resolvconf у меня живет весьма неплохо, но я не пользуюсь connman/nm.
Пользуюсь wicd, и про него знаю, что он сам эту информацию не трогает,
ею занимается dhclient (или кто там у тебя работает с DHCP) в связке с
resolvconf.

И кэшем работает dnsmasq.  На домашнем сервере - bind9, и ему приходится
вручную добавлять скрипт, звездочка в документации неспроста.  А с
dnsmasq работает из коробки.

 OG>   Resolvconf works with most interface configurers in Debian ('(*)' below
 OG>   meaning "with some manual configuration"): 

 OG>  isc-dhcp-client, dhcpcd, pump, udhcpc
 OG>  ppp
 OG>  ifupdown
 OG>  network-manager

 OG>   DNS caches:

 OG>  bind9(*), djbdns dnscache, dnsmasq, nscd, pdnsd

 OG>   DNS recursing nameservers:

 OG>  bind9(*), pdns-recursor(*), unbound

 OG>   and with any program that uses a DNS client library that consults
 OG>   /etc/resolv.conf to obtain its list of nameservers:

 OG>  the GNU C Library resolver library
 OG>  adns
 OG>  the djbdns resolver library
 OG>  FireDNS

 OG> В пакете openresolv поменьше документации.

 OG> -- 
 OG> Best regards!

Как работает локальный DNS кеш?

[Oleksandr Gavenko]

Настраивал поддомены у регистратора и сайты на веб-сервере и попался на том
что ни в какую страница не подгружается.

По умолчанию Debian никаких DNS кешей не устанавливает.

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

По:

  $ cat /etc/resolv.conf
  # Generated by Connection Manager
  nameserver 127.0.0.1
  nameserver ::1

понял что виновен connman. Поделие какое то недопиленое. Опции сбросить DNS
кеш в connmanctl нету. Есть опция:

  $ cat /etc/default/connman
  DAEMON_OPTS='--nodnsproxy'

выключить локальный кеш.

Я отправил баг в Debian BTS, на официальном BTS проекта недоступна
регистрация, в офиц. IRC молчат...

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=805797

В cлучае connman мне ясно что аналог вызова:

  $ dhclient wlan0

делает connman и от туда получает адреса DNS серверов, стартуя локальный на
localhost:53

Есть разные DNS-кеши, например я нашел nscd, dnsmasq, named/bind.

Как менеджеры сетевых подключений (connman, wicd, NetworkManager) знают о том
что нужно передать информацию от DHCP к DNS-кешу? На каждый нужно изучать
документацию?

Или например не трогать /etc/resolve.conf?

И нужен ли мне локальный DNS кеш?

-- 
Best regards!

Re: dns-masq в связке с resolvconf и ручном задании dns-nameservers

[Mikhail A Antonov]

18.01.2015 23:39, Artem Chuprina пишет:
 Mikhail A Antonov - debian-russian@lists.debian.org  @ Sat, 10 Jan 2015 
 19:36:12 +0300:

  MAA В /etc/resolvconf/update.d/dnsmasq нашёл что resolvconf берёт все 
 полученные
  MAA сервера и пишет их в файл, который потом обрабатывает dnsmasq.
  MAA dnsmasq в свою очередь берёт первый dns-сервер и общается с ним. А там 
 сервер от
  MAA dhcp.

  MAA Как бы поменять данное поведение? Отредактировать скрипт resolvconf или 
 есть
  MAA какая-нибудь хитрая опция, которая указывает что сервера от dhcp не надо
  MAA использовать если указаны сервера в interfaces.
  MAA Отредактировать скрипт не сложно, но
  MAA * за ним придётся следить во время обновлений
  MAA * другие программы могут продолжать использовать сервера, полученные от 
 dhcp.
  MAA Вариант не запрашивать dns-сервера от dhcp не подходит т.к. в других 
 сетях мне
  MAA нужно использовать именно те сервера, которые мне передал dhcp-сервер.

  MAA Пока такая сеть одна и она полностью мной контролируется - я могу 
 вместо dhcp
  MAA использовать статический адрес и буду уверен что его никому не выдадут, 
 но в
  MAA процессах я вижу висящий dhcp-клиент и есть у меня подозрение что когда 
 он
  MAA проснётся и решит запросить адрес - ему выдадут и адрес и dns-сервера и 
 у меня
  MAA всё сломается. При поднятии интерфейса убивать искать и  убивать 
 dhcp-клиент?
  MAA При смене wifi-сети он нормально заново запустится?

  MAA В общем я в поиске верного решения, которое в дальнейшем потребует 
 минимум
  MAA поддержки.

 Извини, сейчас мозга не хватает, могу неправильно понять, но.

 dnsmasq'у в его конфиге можно объяснить, что данный домен или домены
 надо запрашивать у данного конкретного DNS-сервера, независимо от чего
 бы то ни было.  Фрагмент с этой строчкой можно при желании динамически
 создавать и удалять, dnsmasq умеет подчитывать фрагменты конфигов из
 отдельных файлов.
Дело в том, что мне нужно не домен\домены спрашивать у конкретных NS, а вообще
все запросы отправлять к иным NS, отличным от тех, что мне выдают по dhcp.
Объясню зачем:
У меня дома всем по dhcp выдаётся NS, который находится на роутере. Этот NS
ходит на skydns и запрещает ходить к некоторым группам сайтов. На своём личном
ноутбуке я хочу использовать другие NS, которые ничего не запрещают. По
специфике работы мне приходится бывать там, куда нормальный человек даже не
подумает ходить.
При этом с этим ноутбуком я бываю в совсем разных сетях, в части которых мне
*необходимо* пользоваться NS, которые мне выдали по dhcp.
Как я вижу решение:
Для своей домашней сети настроить некий идентификатор (благо wpasupplicant это
умеет) и по нему назначать себе другие NS, вместо тех, которые выдают мне по 
dhcp.
Вот если использовать опцию dns-nameservers в interfaces - то resolvconf берёт и
указанные мной сервера, и те, которые выдали через dhcp.
Сейчас я настроил так:

iface home inet static
 address 172.16.2.23
 netmask 24
 gateway 172.16.2.1
 dns-nameservers 77.88.8.8 77.88.8.1
 pre-up /sbin/sysctl -w net.ipv6.conf.wlan0.disable_ipv6=0
net.ipv6.conf.wlan0.accept_ra=1 net.ipv6.conf.wlan0.autoconf=1
 up pkill --full dhclient -v -pf /run/dhclient.wlan0.pid -lf
/var/lib/dhcp/dhclient.wlan0.leases wlan0 2 /dev/null || true

Вроде всё работает, но иногда после выхода из s2ram приходится звать ifdown
wlan0; ifup wlan0 т.к. нет IPv4 на интерфейсе. IPv6 есть, а вот IPv4 нету.
Понаблюдаю ещё. Вероятно это умирающий dhcp-клиент убирает за собой v4 с
интерфейса. Будет надоедать - сделаю inet manual и в up позову ip addr add.

-- 
Best regards,
Mikhail
-
WWW: http://www.antmix.ru/
XMPP: ant...@stopicq.ru



signature.asc
Description: OpenPGP digital signature

Re: dns-masq в связке с resolvconf и ручном задании dns-nameservers

[Artem Chuprina]

Mikhail A Antonov - debian-russian@lists.debian.org  @ Sat, 10 Jan 2015 
19:36:12 +0300:

 MAA В /etc/resolvconf/update.d/dnsmasq нашёл что resolvconf берёт все 
полученные
 MAA сервера и пишет их в файл, который потом обрабатывает dnsmasq.
 MAA dnsmasq в свою очередь берёт первый dns-сервер и общается с ним. А там 
сервер от
 MAA dhcp.

 MAA Как бы поменять данное поведение? Отредактировать скрипт resolvconf или 
есть
 MAA какая-нибудь хитрая опция, которая указывает что сервера от dhcp не надо
 MAA использовать если указаны сервера в interfaces.
 MAA Отредактировать скрипт не сложно, но
 MAA * за ним придётся следить во время обновлений
 MAA * другие программы могут продолжать использовать сервера, полученные от 
dhcp.
 MAA Вариант не запрашивать dns-сервера от dhcp не подходит т.к. в других 
сетях мне
 MAA нужно использовать именно те сервера, которые мне передал dhcp-сервер.

 MAA Пока такая сеть одна и она полностью мной контролируется - я могу вместо 
dhcp
 MAA использовать статический адрес и буду уверен что его никому не выдадут, 
но в
 MAA процессах я вижу висящий dhcp-клиент и есть у меня подозрение что когда он
 MAA проснётся и решит запросить адрес - ему выдадут и адрес и dns-сервера и у 
меня
 MAA всё сломается. При поднятии интерфейса убивать искать и  убивать 
dhcp-клиент?
 MAA При смене wifi-сети он нормально заново запустится?

 MAA В общем я в поиске верного решения, которое в дальнейшем потребует минимум
 MAA поддержки.

Извини, сейчас мозга не хватает, могу неправильно понять, но.

dnsmasq'у в его конфиге можно объяснить, что данный домен или домены
надо запрашивать у данного конкретного DNS-сервера, независимо от чего
бы то ни было.  Фрагмент с этой строчкой можно при желании динамически
создавать и удалять, dnsmasq умеет подчитывать фрагменты конфигов из
отдельных файлов.


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87bnlvg6wx@silver.lasgalen.net

dns-masq в связке с resolvconf и ручном задании dns-nameservers

[Mikhail A Antonov]

Здравствуйте.

Имею такую конфигурацию в interfaces:
--
auto wlan0
iface wlan0 inet manual
wpa-driver nl80211
wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf

iface home inet dhcp
 dns-nameservers 77.88.8.88 77.88.8.2

# 'default' is used for wireless networks without an id_str
iface default inet dhcp
--

И вот такое в wpa_supplicant:
--
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1

network={
ssid=antfam105
psk=пароль
proto=RSN
key_mgmt=WPA-PSK
pairwise=TKIP
group=TKIP WEP104 WEP40
auth_alg=OPEN
id_str=home
}
--

У меня установлен dnsmasq в качестве кеширующего dns-сервера исключительно для
этой машины и пакет resolvconf.

При подключении к сети с id_str=home - resolvconf всё равно получает
dns-сервера от dhcp и передаёт dnsmasq. Т.е. резолвинг по факту до
dns-nameservers не доходит.

Посмотрел в /etc/resolvconf/run/interface/:
./lo.dnsmasq:nameserver 127.0.0.1
./wlan0.dhclient:domain hlebn.6-ip.net
./wlan0.dhclient:nameserver 172.16.2.1
./wlan0.inet:nameserver 77.88.8.88
./wlan0.inet:nameserver 77.88.8.2

Т.е. resolvconf понимает какие сервера надо использовать.

Смотрим дальше.

В /etc/resolvconf/update.d/dnsmasq нашёл что resolvconf берёт все полученные
сервера и пишет их в файл, который потом обрабатывает dnsmasq.
dnsmasq в свою очередь берёт первый dns-сервер и общается с ним. А там сервер от
dhcp.

Как бы поменять данное поведение? Отредактировать скрипт resolvconf или есть
какая-нибудь хитрая опция, которая указывает что сервера от dhcp не надо
использовать если указаны сервера в interfaces.
Отредактировать скрипт не сложно, но
* за ним придётся следить во время обновлений
* другие программы могут продолжать использовать сервера, полученные от dhcp.
Вариант не запрашивать dns-сервера от dhcp не подходит т.к. в других сетях мне
нужно использовать именно те сервера, которые мне передал dhcp-сервер.

Пока такая сеть одна и она полностью мной контролируется - я могу вместо dhcp
использовать статический адрес и буду уверен что его никому не выдадут, но в
процессах я вижу висящий dhcp-клиент и есть у меня подозрение что когда он
проснётся и решит запросить адрес - ему выдадут и адрес и dns-сервера и у меня
всё сломается. При поднятии интерфейса убивать искать и  убивать dhcp-клиент?
При смене wifi-сети он нормально заново запустится?

В общем я в поиске верного решения, которое в дальнейшем потребует минимум
поддержки.
Спасибо.


-- 
Best regards,
Mikhail
-
WWW: http://www.antmix.ru/
XMPP: ant...@stopicq.ru



signature.asc
Description: OpenPGP digital signature

Re: dns-masq в связке с resolvconf и ручном задании dns-nameservers

[Eugene Berdnikov]

On Sat, Jan 10, 2015 at 07:36:12PM +0300, Mikhail A Antonov wrote:
 При подключении к сети с id_str=home - resolvconf всё равно получает
 dns-сервера от dhcp и передаёт dnsmasq. Т.е. резолвинг по факту до
 dns-nameservers не доходит.
...
 Как бы поменять данное поведение? Отредактировать скрипт resolvconf или есть
 какая-нибудь хитрая опция, которая указывает что сервера от dhcp не надо
 использовать если указаны сервера в interfaces.
 Отредактировать скрипт не сложно, но
 * за ним придётся следить во время обновлений
 * другие программы могут продолжать использовать сервера, полученные от dhcp.
 Вариант не запрашивать dns-сервера от dhcp не подходит т.к. в других сетях 
 мне
 нужно использовать именно те сервера, которые мне передал dhcp-сервер.

 Если используется isc-dhcp-client (в дебиане по умолчанию), то предлагаю
 прочесть man dhclient-script. Авторы вряд ли надеялись предусмотреть все
 случаи в жизни, но они попытались обеспечить максимальную гибкость.

 В общем я в поиске верного решения, которое в дальнейшем потребует минимум
 поддержки.

 Лучшее решение -- опознать сеть и навесить свои хуки. Если не получится,
 то следующее по затратности решение -- поправить dhclient-script и
 переключить dhclient.conf на свою копию этого скрипта.
-- 
 Eugene Berdnikov


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150110183056.gr19...@sie.protva.ru

Re: Кэширующий сервер DNS для ПК

[Eugene Berdnikov]

On Thu, Sep 04, 2014 at 01:46:18AM +0400, Anton Gorlov wrote:
 03.09.2014 20:41, Алексей Витальевич Коротков пишет:
  Дело в том, что отваливается DNS провайдера в последнее время регулярно
  (доступ по IP в порядке - проверено). Иногда часами нет возможности
  работать в сети. Начальное сообщение, в том числе, с трудом отправил.
  Так что мне он нужен именно на диске, иначе существенно теряется смысл
  затеи.
 
 Так просто указывайте не dns провайдера на вашем кеширующем, а корневые
 сервера dns и забудьте вообще про провайдерские dns.

 Корневые серверы не для пользователей: они рекурсивные запросы
 не обрабатывают. И некоторые из них на других континентах... :)
-- 
 Eugene Berdnikov


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140904061510.gc21...@sie.protva.ru

Re: Кэширующий сервер DNS для ПК

[Алексей Витальевич Коротков]

On Thu, 4 Sep 2014 10:15:10 +0400
Eugene Berdnikov wrote:

EB  Корневые серверы не для пользователей: они рекурсивные запросы
EB  не обрабатывают. И некоторые из них на других континентах... :)

Есть же один российский.


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140904130224.5de77...@desktop.home

Кэширующий сервер DNS для ПК

[Алексей Витальевич Коротков]

Периодически в последнее время возникают проблемы с DNS, предоставляемым
провайдером. Уже начало доставать.

Решил поставить себе на машинку свой.

Никаких дополнительных функций, кроме указанных в теме, не требуется.

В дальнейшем, возможно, потребуется обслуживать домашнюю сетку из 3-4
машинок.

В поиске нашёл pdnsd. В описании смущает следующее:

содержимое кэша записывается на жёсткий диск при выходе

Т.е., если у меня машинка работает в режиме 24/7, то на жёсткий диск
содержимое кэша попадёт только в результате корректной
перезагрузки/выключения или остановки pdnsd? Допустим, если произошло
выключение по причине пропадания электричества, то кэш уйдёт
в /dev/null? Или я что-то неверно понял?

В целом, насколько pdnsd хорош для указанной цели? Или лучше
воспользоваться каким-то другим сервером (если да, то каким и почему)?


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140903190825.061a2...@desktop.home

Re: Кэширующий сервер DNS для ПК

[Mikhail A Antonov]

03.09.2014 19:08, Алексей Витальевич Коротков пишет:
 Периодически в последнее время возникают проблемы с DNS, предоставляемым
 провайдером. Уже начало доставать.

 Решил поставить себе на машинку свой.

 Никаких дополнительных функций, кроме указанных в теме, не требуется.

 В дальнейшем, возможно, потребуется обслуживать домашнюю сетку из 3-4
 машинок.

 В поиске нашёл pdnsd. В описании смущает следующее:

   содержимое кэша записывается на жёсткий диск при выходе

 Т.е., если у меня машинка работает в режиме 24/7, то на жёсткий диск
 содержимое кэша попадёт только в результате корректной
 перезагрузки/выключения или остановки pdnsd? Допустим, если произошло
 выключение по причине пропадания электричества, то кэш уйдёт
 в /dev/null? Или я что-то неверно понял?
Кеш на диске вообще не нужен. Это тебе не вёб. Частозапрашиваемое дешевле
держать в памяти, редко - переспросить.

 В целом, насколько pdnsd хорош для указанной цели? Или лучше
 воспользоваться каким-то другим сервером (если да, то каким и почему)?
Расскажу из того что пробовал:
У pdnsd были очень странные залипы и проблемы от на SRV, то на TXT, то на 
записях. Не знаю как сейчас с этим.
powerdns-recursor - быстрый, но если у машины несколько IP - начинаются танцы с
тем с какого IP ответил. Не умеет быть форвардером.
bind9 - наиболее гибкий и распространённый. Умеет и нужные зоны форвардить куда
следует, и со всеми типами записей работать и вообще.
dnsmasq - dhcpv4+dhcpv6+dns в одном флаконе. За его размеры его часто вкручивают
во всякие роутеры.

Для себя я определился с такой конфигурацией:
* на ноуте, который болтается из сети в сеть, то wifi, то кабель, то ещё чего -
dnsmasq, форвардящий к НС, которые получены от dhcp.
* на шлюзе даже для трёх компов - bind9. Впрочем для 3к компов тоже он.

-- 
Best regards,
Mikhail
-
WWW: http://www.antmix.ru/
XMPP: ant...@stopicq.ru



signature.asc
Description: OpenPGP digital signature

Re: Кэширующий сервер DNS для ПК

[Eugene Berdnikov]

On Wed, Sep 03, 2014 at 07:08:25PM +0400, Алексей Витальевич Коротков wrote:
 Периодически в последнее время возникают проблемы с DNS, предоставляемым
 провайдером. Уже начало доставать.
...
 В поиске нашёл pdnsd. В описании смущает следующее:
 
   содержимое кэша записывается на жёсткий диск при выходе
 
 Т.е., если у меня машинка работает в режиме 24/7, то на жёсткий диск
 содержимое кэша попадёт только в результате корректной
 перезагрузки/выключения или остановки pdnsd? Допустим, если произошло
 выключение по причине пропадания электричества, то кэш уйдёт
 в /dev/null? Или я что-то неверно понял?

 Для домашней машинки потеря кэша не является проблемой, никто из 3-4
 домочадцев просто ничего не заметит. :) Вот если бы сервис предоставлялся
 3-4 тысячам (!) активных юзеров, тогда можно было бы подумать о сохранении
 кэша, потому что его потеря может отразиться в виде некоторого роста
 нагрузки на сервер и сеть после перезапуска. Но ненадолго, до 15-30 минут,
 после чего поток покидающих кэш старых записей сравняется со скоростью
 поступления новых, а hit ratio выйдет на плато.

 В целом, насколько pdnsd хорош для указанной цели?

 Судя по описанию, pdnsd разработан для несколько экзотической цели:
 обеспечить сервис dns тогда, когда связи нет. Не знаю, нужно ли это Вам,
 обычному домашнему пользователю dns без интернета неинтересен... :)

 Вы не написали, что за проблемы с провайдерским dns. В качестве просто
 кэширующего сервера для домашних машин популярен dnsmasq, он хорош ещё
 тем, что имеет +dhcp в одном флаконе. Работает стабильно.
-- 
 Eugene Berdnikov


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140903155749.gx21...@sie.protva.ru

Re: Кэширующий сервер DNS для ПК

[Руслан Коротаев]

Я использую pdnsd, он хорош, особенно если у вас dial-up или «моргающая
сеть» что не редкость в наших просторах. Он для работы в экстремальных
условиях.

Преимущества:
* Крохотный размер.
* Возможность сохранять кэш в файл.
Недостатки:
* Подходит персонального использования, но не для обслуживания сети.

В сочетании с polipo он может существенно ускорять загрузку страниц
когда бродишь по интернету. Если нужен DNS-сервер для небольшой группы
пользователей, то лучше приглядитесь к dnsmasq.

P.S.: Если произойдет внезапное отключение ноутбука, тот кэш
восстановится из последнего сохраненного файла, в этом вся фишка pdnsd.

-- 
С уважением, Коротаев Руслан
Профиль: http://plus.google.com/105183056726716330520


Автор Алексей Витальевич Коротков a.v.korot...@gmail.com 
в сообщении от [Срд 2014-09-03 19:08 +0400] написал:
 Периодически в последнее время возникают проблемы с DNS, предоставляемым
 провайдером. Уже начало доставать.
 
 Решил поставить себе на машинку свой.
 
 Никаких дополнительных функций, кроме указанных в теме, не требуется.
 
 В дальнейшем, возможно, потребуется обслуживать домашнюю сетку из 3-4
 машинок.
 
 В поиске нашёл pdnsd. В описании смущает следующее:
 
   содержимое кэша записывается на жёсткий диск при выходе
 
 Т.е., если у меня машинка работает в режиме 24/7, то на жёсткий диск
 содержимое кэша попадёт только в результате корректной
 перезагрузки/выключения или остановки pdnsd? Допустим, если произошло
 выключение по причине пропадания электричества, то кэш уйдёт
 в /dev/null? Или я что-то неверно понял?
 
 В целом, насколько pdnsd хорош для указанной цели? Или лучше
 воспользоваться каким-то другим сервером (если да, то каким и почему)?
 
 
 -- 
 To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
 Archive: https://lists.debian.org/20140903190825.061a2...@desktop.home
 


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140903163906.GA20559@localhost

Re: Кэширующий сервер DNS для ПК

[Алексей Витальевич Коротков]

On Wed, 3 Sep 2014 19:57:49 +0400
Eugene Berdnikov wrote:

EB Для домашней машинки потеря кэша не является проблемой, никто из 3-4
EB  домочадцев просто ничего не заметит.

В смысле не заметит?

Вот, допустим, я потерял кэщ в памяти по той или иной причине (свет
вырубили, к примеру). Перезагрузился, нужна Сеть (почта, к примеру).

Но при этом получаю вот такое (может часами быть):

$ ping -c5 ya.ru
ping: unknown host ya.ru

При этом

$ ping -c5 213.180.193.3
PING 213.180.193.3 (213.180.193.3) 56(84) bytes of data.
64 bytes from 213.180.193.3: icmp_req=1 ttl=47 time=366 ms
64 bytes from 213.180.193.3: icmp_req=2 ttl=47 time=165 ms
64 bytes from 213.180.193.3: icmp_req=3 ttl=47 time=674 ms
64 bytes from 213.180.193.3: icmp_req=4 ttl=47 time=262 ms
64 bytes from 213.180.193.3: icmp_req=5 ttl=47 time=191 ms

тут не о домочадцах идёт речь, прежде всего, а обо мне самом. Когда у
меня фактически нет доступа в Сеть часами - это мне не очень нравится,
скажем так.

EB  Судя по описанию, pdnsd разработан для несколько экзотической цели:
EB  обеспечить сервис dns тогда, когда связи нет. Не знаю, нужно ли
EB это Вам, обычному домашнему пользователю dns без интернета
EB неинтересен...

Не знаю, может я недостаточно чётко описал проблему... Интернет есть,
но его часами не бывает в том смысле, что имена не резолвятся. Вот как
выше в примере с ping.

EB  Вы не написали, что за проблемы с провайдерским dns. В качестве
EB просто кэширующего сервера для домашних машин популярен dnsmasq, он
EB хорош ещё тем, что имеет +dhcp в одном флаконе. Работает
EB стабильно.

dhcp не нужен. Насколько он хорош для той цели, что я постарался
описать? И как там обстоит дело с кэшем на диске всё же?


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140903205925.76759...@desktop.home

Re: Кэширующий сервер DNS для ПК

[Алексей Витальевич Коротков]

On Wed, 03 Sep 2014 19:29:27 +0400
Mikhail A Antonov wrote:

MAA Кеш на диске вообще не нужен. Это тебе не вёб. Частозапрашиваемое
MAA дешевле держать в памяти, редко - переспросить.

Дело в том, что отваливается DNS провайдера в последнее время регулярно
(доступ по IP в порядке - проверено). Иногда часами нет возможности
работать в сети. Начальное сообщение, в том числе, с трудом отправил.
Так что мне он нужен именно на диске, иначе существенно теряется смысл
затеи.

Забыл ещё написать в исходном сообщении (если это важно): доступ в Сеть
со свистка от МТС (в роутере торчит; канал один-единственный), IP у них
выдаётся не постоянный.

MAA * на ноуте, который болтается из сети в сеть, то wifi, то кабель,
MAA то ещё чего - dnsmasq, форвардящий к НС, которые получены от dhcp.

А как у него с сохранением кэша на диск дело обстоит?

MAA * на шлюзе даже для трёх компов - bind9. Впрочем для 3к компов
MAA тоже он.

bind для (по крайней мере пока что) одной машинки - это, наверно,
перебор всё же. Да и для домашней сетки хотелось бы что-нибудь попроще.


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140903204139.7211f...@desktop.home

Re: Кэширующий сервер DNS для ПК

[Алексей Витальевич Коротков]

On Wed, 3 Sep 2014 22:39:06 +0600
Руслан Коротаев wrote:

 Возможность сохранять кэш в файл.

Я правильно понял, что это делается чисто рукам/по крону? Т.е., сам он
по себе кэш на диск сохраняет только в случае pdnsd stop?


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140903210940.55236...@desktop.home