Windows настраивается по DHCP лучше всех
Конкретнее.
какое из слов "третий dns по dhcp" тебе не понятно?
какой Windows, какой DHCP-cервер?
ты знаешь какой-то виндовс где это работает?
коды полей dhcp довольно таки однозначны и не зависят от реализации.
коды полей dhcp довольно таки однозначны и не зависят от реализации.
да, знаю.
ты заставил меня перепроверить это.
скоро на тебя падёт кара небесная.
в общем, на Win2008 Datacenter x64 работает. На какой не работает? Проверю на виртуалке.
ты заставил меня перепроверить это.
скоро на тебя падёт кара небесная.
в общем, на Win2008 Datacenter x64 работает. На какой не работает? Проверю на виртуалке.
поздравляю
в общем, на Win2008 Datacenter x64 работает.это ты хитро выбрал, чтоб никто другой не перепроверил?
надо было брать под ia64 для верности. =)
Какой, да какой. Тот, который работает у "домохозяйки."
Не обратил внимания, там uname(1) нет.
Какой DHCP сервер вшит в маршрутизатор, не знаю, но это и
не должно быть важно, потому что лежащий рядом UNIX(TM) ---
работает, как и положено.
Более всего меня интересует, как можно диагностировать такую
идиотскую ошибку, если не знать, что суслик, то есть рабочий
DNS сервер, на самом деле есть. В винде ведь нет ни встроенного
резолвера, ни средств диагностики (как, например, из комплекта
ISC BIND).
---
Q21: что такое Win2k?
A21: состема.
Не обратил внимания, там uname(1) нет.
Какой DHCP сервер вшит в маршрутизатор, не знаю, но это и
не должно быть важно, потому что лежащий рядом UNIX(TM) ---
работает, как и положено.
Более всего меня интересует, как можно диагностировать такую
идиотскую ошибку, если не знать, что суслик, то есть рабочий
DNS сервер, на самом деле есть. В винде ведь нет ни встроенного
резолвера, ни средств диагностики (как, например, из комплекта
ISC BIND).
---
Q21: что такое Win2k?
A21: состема.
Это я хитро выбрал то, что у меня есть на домашней машине.
в винде есть ipconfig /all, где ты увидишь все пойманные DNSы
> Win2008 Datacenter x64
В то, что у "домохозяйки" на ноуте может быть amd64, я верю,
но вот в "2008" и, тем более, "Datacenter" верится с трудом.
---
Q38: а по каким, собственно, правилам, тут ведутся дискуссии?
формальной логикой ведь и не пахнет...
A38: http://golovolomka.hobby.ru/humour/flogic.shtml
В то, что у "домохозяйки" на ноуте может быть amd64, я верю,
но вот в "2008" и, тем более, "Datacenter" верится с трудом.
---
Q38: а по каким, собственно, правилам, тут ведутся дискуссии?
формальной логикой ведь и не пахнет...
A38: http://golovolomka.hobby.ru/humour/flogic.shtml
Мне не понятно "Windows настраивается по DHCP лучше всех" без раскрытия темы.
ни встроенногоЭто ты не про dig/nslookup ли, случаем?
резолвера
> в винде есть ipconfig /all, где ты увидишь все пойманные DNSы
И? Где третий?
То, что он есть, выясняется по "cat /etc/resolv.conf" на соседнем UNIX(TM).
Как проверить, работают ли они вообще? dig-то нет.
Вопрос на засыпку: как это сможет сделать "домохозяйка?"
---
Q21: что такое Win2k?
A21: состема.
И? Где третий?
То, что он есть, выясняется по "cat /etc/resolv.conf" на соседнем UNIX(TM).
Как проверить, работают ли они вообще? dig-то нет.
Вопрос на засыпку: как это сможет сделать "домохозяйка?"
---
Q21: что такое Win2k?
A21: состема.
>> ни встроенного резолвера
> Это ты не про dig/nslookup ли, случаем?
Это я про BIND, который в NetBSD (но не во FreeBSD) настроен по
умолчанию локальным резолвером. Он выключен, но в системе для
домохозяек его могли бы и включить, пусть себе работает на 127.0.0.1.
---
A44: Ламеры в гамаке пусть в тапках трахаются --- это их проблемы.
Я в своём гамаке хочу полноценно трахаться на лыжах.
> Это ты не про dig/nslookup ли, случаем?
Это я про BIND, который в NetBSD (но не во FreeBSD) настроен по
умолчанию локальным резолвером. Он выключен, но в системе для
домохозяек его могли бы и включить, пусть себе работает на 127.0.0.1.
---
A44: Ламеры в гамаке пусть в тапках трахаются --- это их проблемы.
Я в своём гамаке хочу полноценно трахаться на лыжах.
dig-то нет.nslookup.
То, что он есть, выясняется по "cat /etc/resolv.conf" на соседнем UNIX(TM).а, может, он там был до DHCP?
но в системе дляЕщё в системе для домохозяек обязательно надо включить веб-сервер и емакс. А то вдруг КОНТРА захочет чего подиагностировать.
домохозяек его могли бы и включить
>> dig-то нет.
> nslookup
Замечательно, если оно там есть, но видишь ли, даже я не знал про это.
Допустим даже, что "usage" под виндой сделали (потому что его нет
и этой "usage" хватает.
А что делать с "домохозяйкой?"
Ещё раз, принадлежащий той же "домохозяйке" ноутбук с UNIX(TM) --- работает,
для этого никаких движений сверх тыканья в такие же менюшки не потребовалось.
---
Q21: что такое Win2k?
A21: состема.
> nslookup
Замечательно, если оно там есть, но видишь ли, даже я не знал про это.
Допустим даже, что "usage" под виндой сделали (потому что его нет
и этой "usage" хватает.
А что делать с "домохозяйкой?"
Ещё раз, принадлежащий той же "домохозяйке" ноутбук с UNIX(TM) --- работает,
для этого никаких движений сверх тыканья в такие же менюшки не потребовалось.
---
Q21: что такое Win2k?
A21: состема.
Вот только не выставляет третий адрес DNS.у нас в общаге до недавнего времени по дхцп получалось толи 4 толи 5 адресов днс. получали их сколько-то там сотен машин и почти все под виндами.
Замечательно, если оно там есть, но видишь ли, даже я не знал про это.А я не знал про dig. Что дальше?
Ещё раз, принадлежащий той же "домохозяйке" ноутбук с UNIX(TM) --- работаетДля твоей домохозяйки самое важное в системе - чтобы третий dns-сервер по dhcp получила? Она потом так и сидит с этим ноутбуком и любуется выводом cat /etc/resolv.conf?
>> Ещё раз, принадлежащий той же "домохозяйке" ноутбук с UNIX(TM) ---
>> работает
> Для твоей домохозяйки самое важное в системе - чтобы третий
> dns-сервер по dhcp получила? Она потом так и сидит с этим
> ноутбуком и любуется выводом cat /etc/resolv.conf?
Да, потому что сетевые клиенты, включая клиенты HTTP/HTTPS,
SMTP/IMAP, XMPP и т.п., должны работать не только локально,
но и соединения как-то устанавливать. А всё остальное у неё
работает.
---
Q21: что такое Win2k?
A21: состема.
>> работает
> Для твоей домохозяйки самое важное в системе - чтобы третий
> dns-сервер по dhcp получила? Она потом так и сидит с этим
> ноутбуком и любуется выводом cat /etc/resolv.conf?
Да, потому что сетевые клиенты, включая клиенты HTTP/HTTPS,
SMTP/IMAP, XMPP и т.п., должны работать не только локально,
но и соединения как-то устанавливать. А всё остальное у неё
работает.
---
Q21: что такое Win2k?
A21: состема.
А всё остальное у неё"Всё остальное" - это что именно?
работает.
Твоя NetBSD настолько не удовлетворяет потребности типичной домохозяйки, что ни до каких там dns-серверов дело не дойдёт. Разве что у этой домохозяйки всегда под рукой есть КОНТРА - но количество таких домохозяек никогда не будет различимо без микроскопа.
> "Всё остальное" - это что именно?
Не знаю, по словам, это её рабочий ноут, а сама "домохозяйка"
фотожурналист и работает редактором.
> Твоя NetBSD настолько не удовлетворяет потребности типичной
> домохозяйки, что ни до каких там dns-серверов дело не дойдёт.
Ты не умеешь читать? Я говорю не про NetBSD, а про UNIX(TM
цифры из NetBSD взяты для оценки объёмов всего BIND, даже если
бы весь набор "base" он отнимал, это всё равно копейки.
И, да, частично этот UNIX(TM) использует программы из NetBSD.
Ну а BIND, он вообще --- один на всех.
---
Q21: что такое Win2k?
A21: состема.
Не знаю, по словам, это её рабочий ноут, а сама "домохозяйка"
фотожурналист и работает редактором.
> Твоя NetBSD настолько не удовлетворяет потребности типичной
> домохозяйки, что ни до каких там dns-серверов дело не дойдёт.
Ты не умеешь читать? Я говорю не про NetBSD, а про UNIX(TM
цифры из NetBSD взяты для оценки объёмов всего BIND, даже если
бы весь набор "base" он отнимал, это всё равно копейки.
И, да, частично этот UNIX(TM) использует программы из NetBSD.
Ну а BIND, он вообще --- один на всех.
---
Q21: что такое Win2k?
A21: состема.
Вопрос о требовании клиентской программой наличия серверной так и проигнорируешь?
Это копейки по сравнению с остальной системой,
и в _операционных_системах_ оно _уже_ есть в базовом комплекте,
его _не_надо_ доставлять отдельно.
---
Q21: что такое Win2k?
A21: состема.
и в _операционных_системах_ оно _уже_ есть в базовом комплекте,
его _не_надо_ доставлять отдельно.
---
Q21: что такое Win2k?
A21: состема.
и в _операционных_системах_ оно _уже_ есть в базовом комплекте,Нахуй слал я такие операционные системы, где в базовом комплекте стоит и включен мешок серверов.
В базовом комплекте той же XP, если мне не изменяет память - только file sharing. В висте и того нет, отдельно включать надо.
Вопрос о требовании клиентской программой наличия серверной так и проигнорируешь?
The following extra packages will be installed:Где здесь сервер?
bind9-host libbind9-40 libcap2 libdns45 libisc45 libisccc40 libisccfg40 liblwres40 libxml2 perl perl-modules sgml-base xml-core
Тссс, удали, пока контра не заметил!
> слал я такие операционные системы, где в базовом комплекте
> стоит и включен мешок серверов.
О, да, named потребляет просто дочёрта ресурсов:
---
Q43: А какое предназначение у винды?
A43: bsod
> стоит и включен мешок серверов.
О, да, named потребляет просто дочёрта ресурсов:
$ ps auxwww | sed -ne 1p -e /bind/p
USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND
bind 428 0.0 0.4 4720 1996 ? Ss Fri10AM 0:00.92 /usr/sbin/named -t /var/named -u bind
root 438 0.0 0.0 1500 236 ? Is Fri10AM 0:00.14 /usr/sbin/rpcbind -h 127.0.0.1
---
Q43: А какое предназначение у винды?
A43: bsod
он не первый написал такое сообщение.
Да какая разница, я тебе уже несколько раз сказал, что то, как
это сделано в твоём погнутом линуксе, меня не интересует, тем
хуже для линукса, потому что в операционных системах BIND стоит
безо всяких перлов. Если ты используешь линукс, это твои личные
трудности. Здесь сравниваются винда и _UNIX(TM)_, работающие у
одной и той же "домохозяйки," человека не просто не работающего
в "информационных технологиях," а гуманитария по образованию.
---
Q43: А какое предназначение у винды?
A43: bsod
это сделано в твоём погнутом линуксе, меня не интересует, тем
хуже для линукса, потому что в операционных системах BIND стоит
безо всяких перлов. Если ты используешь линукс, это твои личные
трудности. Здесь сравниваются винда и _UNIX(TM)_, работающие у
одной и той же "домохозяйки," человека не просто не работающего
в "информационных технологиях," а гуманитария по образованию.
---
Q43: А какое предназначение у винды?
A43: bsod
О, да, named потребляет просто дочёрта ресурсов:Дело не в ресурсах, а в ещё одном сервере с ещё одной пачкой потенциальных уязвимостей.
Дело не в ресурсах, а в ещё одном сервере с ещё одной пачкой потенциальных уязвимостей.Кто мешает ограничить доступ к нему локалхостом?
>> О, да, named потребляет просто дочёрта ресурсов:
> Дело не в ресурсах, а в ещё одном сервере с ещё одной пачкой
> потенциальных уязвимостей.
То есть, ты признаёшь, что в Микрософт не могут не сломать даже
такой отработанный пакет, как BIND? Да ещё так, что смогут взломать
демона, тихо мирно стоящего в стороне и слушающего 127.0.0.1:53.
---
Q43: А какое предназначение у винды?
A43: bsod
> Дело не в ресурсах, а в ещё одном сервере с ещё одной пачкой
> потенциальных уязвимостей.
То есть, ты признаёшь, что в Микрософт не могут не сломать даже
такой отработанный пакет, как BIND? Да ещё так, что смогут взломать
демона, тихо мирно стоящего в стороне и слушающего 127.0.0.1:53.
---
Q43: А какое предназначение у винды?
A43: bsod
в Микрософт не могут не сломатьЯ хакерских атак всё-таки не со стороны microsoft боюсь.
Чем меньше всяких сервисов - тем меньше поверхность для взлома.
>> в Микрософт не могут не сломать
> Я хакерских атак всё-таки не со стороны microsoft боюсь.
> Чем меньше всяких сервисов - тем меньше поверхность для взлома.
Как, по-твоему, работают корневые серверы DNS?
Почему их никто не ломает? Не пытаются, что ли?
Почему тогда в операционных системах не боятся оставлять
открытыми наружу все эти sshd, named, ntpd, httpd, ftpd?
Кстати, про ntpd. Почему винда не предоставляет пользователю
возможностей выставлять точное время из сети?
Это очень сложно, да? В операционных системах это делается
созданием одного-двух файлов, при некотором желании, можно
наваять скрипт на тикле, который будет делать такое ажно
с графическим интерфейсом.
---
Q43: А какое предназначение у винды?
A43: bsod
> Я хакерских атак всё-таки не со стороны microsoft боюсь.
> Чем меньше всяких сервисов - тем меньше поверхность для взлома.
Как, по-твоему, работают корневые серверы DNS?
Почему их никто не ломает? Не пытаются, что ли?
Почему тогда в операционных системах не боятся оставлять
открытыми наружу все эти sshd, named, ntpd, httpd, ftpd?
Кстати, про ntpd. Почему винда не предоставляет пользователю
возможностей выставлять точное время из сети?
Это очень сложно, да? В операционных системах это делается
созданием одного-двух файлов, при некотором желании, можно
наваять скрипт на тикле, который будет делать такое ажно
с графическим интерфейсом.
---
Q43: А какое предназначение у винды?
A43: bsod
Почему тогда в операционных системах не боятся оставлятьВ операционных системах оставляют наружу открытыми так мало служб, как только возможно.
Если от сервера не требуется работать веб-сервером - никакой httpd там стоять не будет.
Я, конечно, не знаю, может быть, у тебя всё по другому и серверов у тебя там сейчас сотня стоит, на все случаи жизни.
выставлять точное время по сигналу из сетиЭто ты что сейчас имеешь в виду и зачем оно нужно?
>Кстати, про ntpd. Почему винда не предоставляет пользователю
>возможностей выставлять точное время по сигналу из сети?
>Это очень сложно, да? В операционных системах это делается
>созданием одного-двух файлов, при некотором желании, можно
>наваять скрипт на тикле, который будет делать такое ажно
>с графическим интерфейсом.
ты когда винду в последний раз видел? есть в ней такое, хоть и криво реализовано.
>возможностей выставлять точное время по сигналу из сети?
>Это очень сложно, да? В операционных системах это делается
>созданием одного-двух файлов, при некотором желании, можно
>наваять скрипт на тикле, который будет делать такое ажно
>с графическим интерфейсом.
ты когда винду в последний раз видел? есть в ней такое, хоть и криво реализовано.
>Это ты что сейчас имеешь в виду и зачем оно нужно?
видимо http://csg.trinhall.cam.ac.uk/tips/ntp/winxp это
видимо http://csg.trinhall.cam.ac.uk/tips/ntp/winxp это
Он так криво описал, что я уж было решил, он хочет, чтобы в винде какой-то сервер слушал на каком-то порту, и снаружи ему можно было сказать "а ну синхронизуйся".
Даже в голову не могло прийти, что он имеет в виду банальную синхронизацию руками.
Даже в голову не могло прийти, что он имеет в виду банальную синхронизацию руками.
>синхронизацию руками.
почему руками-то? оно раз в неделю в вашей венде само синхронизируется.
почему руками-то? оно раз в неделю в вашей венде само синхронизируется.
>> Почему тогда в операционных системах не боятся оставлять
> В операционных системах оставляют наружу открытыми так мало
> служб, как только возможно.
Ещё раз, ответь чётко и внятно: ПОЧЕМУ не боятся оставлять named и ntpd?
Их можно было бы вообще не поднимать: часы выставлять руками, а
пользователи пускай через внешние серверы свои адреса узнают.
И ещё, что самое главное: ПОЧЕМУ не боятся запускать тот же
named на 127.0.0.1?
---
Q43: А какое предназначение у винды?
A43: bsod
> В операционных системах оставляют наружу открытыми так мало
> служб, как только возможно.
Ещё раз, ответь чётко и внятно: ПОЧЕМУ не боятся оставлять named и ntpd?
Их можно было бы вообще не поднимать: часы выставлять руками, а
пользователи пускай через внешние серверы свои адреса узнают.
И ещё, что самое главное: ПОЧЕМУ не боятся запускать тот же
named на 127.0.0.1?
---
Q43: А какое предназначение у винды?
A43: bsod
Ещё раз, ответь чётко и внятно: ПОЧЕМУ не боятся оставлять named и ntpd?Ещё раз - те, кого я знаю, оставляют только то, что необходимо.
Из семи наших серверов named стоит только на двух, если мне не изменяет память. Эти два действительно должны работать как dns-серверы, на них обслуживается некоторое количество доменов.
Я, конечно, не знаю, может быть, у тебя всё по другому и серверов у тебя там сейчас сотня стоит, на все случаи жизни.
$ sudo nmap -A `cat notes/ip `
Starting Nmap 4.76 ( http://nmap.org ) at 2009-05-04 01:33 MSD
Interesting ports on *******
Not shown: 988 closed ports
PORT STATE SERVICE VERSION
21/tcp open ftp ProFTPD 1.3.0rc1
22/tcp open ssh OpenSSH 3.6.1p2 (protocol 1.99)
23/tcp open telnet IRIX telnetd 6.X
25/tcp filtered smtp
53/tcp open domain ISC BIND unknown
80/tcp open http Apache httpd 1.3.31 ALT Linux/alt10) PHP/4.4.6 with Suhosin-Patch mod_ssl/2.8.19 OpenSSL/0.9.7d)
111/tcp open rpcbind
139/tcp open netbios-ssn Samba smbd
443/tcp open ssl/http Apache httpd 1.3.31 ALT Linux/alt10) PHP/4.4.6 with Suhosin-Patch mod_ssl/2.8.19 OpenSSL/0.9.7d)
445/tcp open netbios-ssn Samba smbd
1521/tcp filtered oracle
3306/tcp open mysql MySQL (unauthorized)
Device type: WAP|general purpose|broadband router|printer|server appliance|storage-misc
Running (JUST GUESSING) : Linux 2.4.X|2.6.X (96% FON Linux 2.4.X (91% Linksys embedded (89% Lexmark embedded (89% Toshiba Linux 2.4.X (88% Adaptec embedded (88%)
Aggressive OS guesses: OpenWrt 0.9 - 7.09 (Linux 2.4.30 - 2.4.34) (96% OpenWrt 7.09 (Linux 2.6.22) (96% Linux 2.6.19 - 2.6.21 (94% Linux 2.6.21 (Slackware 12.0) (94% OpenWrt 7.09 (Linux 2.6.17 - 2.6.21) (94% Linux 2.6.22 (Fedora 7) (92% Linux 2.6.21 (Debian, x86) (92% Linux 2.6.20.6 (92% FON La Fonera WAP (OpenWrt, Linux 2.4.32) (91% FON La Fonera WAP running OpenWrt w/Linux kernel 2.4.32 (91%)
No exact OS matches for host (test conditions non-ideal).
Network Distance: 9 hops
Service Info: OSs: Unix, IRIX
TRACEROUTE (using port 80/tcp)
HOP RTT ADDRESS
-----------cut-------------
OS and Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 24.61 seconds
cat notes/ipКакой давности?
Скорее всего, это айпишник моего провайдера. Гораздо менее вероятно - айпишник офисного гейта. И совсем невероятно, чтобы это был мой нынешний айпишник - там по tcp только один порт открыт.
ЗЫ: Ну точно:
ALT LinuxК чему тогда ты вообще этот листинг привёл? Или думаешь, я дома альтом пользуюсь?
К чему тогда ты вообще этот листинг привёл?Ну просто ты тут на форуме как-то раз очень испугался, когда кто-то его заметил, я решил записать
Из твоего листинга как бы очевидно, что это не непосредственно мой айпи.
Просто из айпишника можно не только возможность к взлому компа получить.
Просто из айпишника можно не только возможность к взлому компа получить.
Из твоего листинга как бы очевидно, что это не непосредственно мой айпи.Просто показал тебе, что у меня есть на тебя выходы =) Не беспокойся в общем.
Только к
А мой провайдер - это один школьник, я уже говорил.
Я, конечно, не знаю, может быть, у тебя всё по другому и серверов у тебя там сейчас сотня стоит, на все случаи жизни.это не имеет отношения.
А мой провайдер - это один школьник, я уже говорил.
это не имеет отношения.Ну пусть не имеет, но при первом прочтении кто-нибудь подумает, что имеет. Ничего страшного.
>> Ещё раз, ответь чётко и внятно: ПОЧЕМУ не боятся оставлять named и ntpd?
> Ещё раз - те, кого я знаю, оставляют только то, что необходимо.
Восстанови второе предложение и _объясни_, _почему_ они
не заставили техподдержку прописать адреса DNS провайдера.
Если они боятся, что их взломают, почему не скинуть риск на других?
---
"Три раза, Ганс, три раза. Запомни, Ганс: три раза."
> Ещё раз - те, кого я знаю, оставляют только то, что необходимо.
Восстанови второе предложение и _объясни_, _почему_ они
не заставили техподдержку прописать адреса DNS провайдера.
Если они боятся, что их взломают, почему не скинуть риск на других?
---
"Три раза, Ганс, три раза. Запомни, Ганс: три раза."
_почему_ ониКто "они", какую техподдержку, какого провайдера? Ты о чём?
не заставили техподдержку прописать адреса DNS провайдера
Администраторы соответствующих систем.
Напомню, что ты утверждаешь, будто вешать BIND --- небезопасно,
пока умолчим про то, что подразумевается вешать его на 127.0.0.1.
Вот я и спрашиваю тебя: чем?
Если это настолько небезовасно, все пытались бы свалить
администрирование DNS на более высококлассных профессионалов.
Например, провайдеров. Тем более, что последние предлагают такие
услуги чуть ли не забесплатно. Однако, в действительности этого
не происходит. Объясняй, почему так.
---
"Истина грядёт --- её ничто не остановит!"
Напомню, что ты утверждаешь, будто вешать BIND --- небезопасно,
пока умолчим про то, что подразумевается вешать его на 127.0.0.1.
Вот я и спрашиваю тебя: чем?
Если это настолько небезовасно, все пытались бы свалить
администрирование DNS на более высококлассных профессионалов.
Например, провайдеров. Тем более, что последние предлагают такие
услуги чуть ли не забесплатно. Однако, в действительности этого
не происходит. Объясняй, почему так.
---
"Истина грядёт --- её ничто не остановит!"
Если это настолько небезовасно, все пытались бы свалитьЕсли ты про наши два сервера - откуда, по-твоему, провайдеры берут данные? То-то же.
администрирование DNS на более высококлассных профессионалов.
Например, провайдеров.
В случае с этими двумя серверами мы сами являемся профессионалами. В остальных случаях - нахуй не нужен bind на рабочем сервере.
Опиши ситуацию, когда твоей системе понадобится третий DNS.
В этом случае первые два должны не работать
В этом случае первые два должны не работать
> Если ты про наши два сервера - откуда, по-твоему,
> провайдеры берут данные?
Ты их сам в веб-формочку вводишь.
> То-то же.
---
...Я работаю антинаучным аферистом...
> провайдеры берут данные?
Ты их сам в веб-формочку вводишь.
> То-то же.
---
...Я работаю антинаучным аферистом...
> Опиши ситуацию, когда твоей системе понадобится третий DNS.
Моей системе DNS вообще не нужны, у меня работает собственный dnscache,
а вот у реальной "домохозяйки," человека с исключительно гуманитарными
образованием и профессией, почему-то работает вот так. У меня нет
никакого желания разбираться почему, Пенартур утверждает, что его,
желания, может не быть и это не должно приводить к катастрофическим
последствиям в виде неработающей сетки.
---
"Plug and Pray"
Моей системе DNS вообще не нужны, у меня работает собственный dnscache,
а вот у реальной "домохозяйки," человека с исключительно гуманитарными
образованием и профессией, почему-то работает вот так. У меня нет
никакого желания разбираться почему, Пенартур утверждает, что его,
желания, может не быть и это не должно приводить к катастрофическим
последствиям в виде неработающей сетки.
---
"Plug and Pray"
Ты их сам в веб-формочку вводишь.Правильно, я их ввожу в веб-формочку в панели управления своим доменом. Что дальше с этими данными происходит, куда они идут?
Вот и выходит:
В этом случае первые два должны не работать
>> Ты их сам в веб-формочку вводишь.
> Правильно, я их ввожу в веб-формочку
_Управления_серверами_DNS_провайдера_, а не "своим доменом."
> Что дальше с этими данными происходит, куда они идут?
Пихаются в базу имён авторитетного сервера на стороне провайдера.
Итого, если ты сам не потребуешь делегацию, оно остаётся у провайдера.
---
"Debian: You can never be sure."
> Правильно, я их ввожу в веб-формочку
_Управления_серверами_DNS_провайдера_, а не "своим доменом."
> Что дальше с этими данными происходит, куда они идут?
Пихаются в базу имён авторитетного сервера на стороне провайдера.
Итого, если ты сам не потребуешь делегацию, оно остаётся у провайдера.
---
"Debian: You can never be sure."
> Вот и выходит:
>> В этом случае первые два должны не работать
И что? Как ты считаешь, почему отдаётся несколько адресов?
---
"Vyroba umelych lidi, slecno, je tovarni tajemstvi."
>> В этом случае первые два должны не работать
И что? Как ты считаешь, почему отдаётся несколько адресов?
---
"Vyroba umelych lidi, slecno, je tovarni tajemstvi."
_Управления_серверами_DNS_провайдера_, а не "своим доменом."Ещё раз.
Человек купил у нас домен vasyapupkin.ru. Он хочет, чтобы у всех людей при входе на vasyapupkin.ru открывался его компьютер 200.200.200.200. Куда он вводит эти данные и куда они попадают после этого?
оно остаётся у провайдераКакого провайдера-то?
> Человек купил у нас домен vasyapupkin.ru. Он хочет, чтобы у
> всех людей при входе на vasyapupkin.ru открывался его
> компьютер 200.200.200.200. Куда он вводит эти данные и куда
> они попадают после этого?
Он вводит их в панель управления регистратора (читай --- провайдера
оттуда они попадают в базу данных сервера DNS этого самого регистратора.
В итоге, все запросы заканчиваются на NS "ru.", если только пользователь
не попросил назначить NS "vasyapupkin.ru." _его_ сервер.
Что, кстати, и происходит, запросы в "vasyapupkin.ru"
делегированы серверам ns1.spaceweb.ru и ns2.spaceweb.ru.
Потому что _так_попросили_. Сравни с yandex.ru и vesna.yandex.ru.
---
"Vyroba umelych lidi, slecno, je tovarni tajemstvi."
> всех людей при входе на vasyapupkin.ru открывался его
> компьютер 200.200.200.200. Куда он вводит эти данные и куда
> они попадают после этого?
Он вводит их в панель управления регистратора (читай --- провайдера
оттуда они попадают в базу данных сервера DNS этого самого регистратора.
В итоге, все запросы заканчиваются на NS "ru.", если только пользователь
не попросил назначить NS "vasyapupkin.ru." _его_ сервер.
Что, кстати, и происходит, запросы в "vasyapupkin.ru"
делегированы серверам ns1.spaceweb.ru и ns2.spaceweb.ru.
Потому что _так_попросили_. Сравни с yandex.ru и vesna.yandex.ru.
---
"Vyroba umelych lidi, slecno, je tovarni tajemstvi."
в базу данных сервера DNS этого самого регистратораВот-вот.
Понял теперь наконец, почему у нас на двух серверах стоит бинд?
В итоге, все запросы заканчиваются на NS "ru."NS "ru." обычно не отдаёт адреса конкретных доменов, если ты не в курсе. Она только говорит, к каким конкретным dns-серверам обратиться за информацией об этом домене.
Хотя я не в курсе, может быть, и есть такая услуга - поддержка домена на серверах ns.ripn.net, ns2.ripn.net и так далее. Не подскажешь, где её купить и сколько она стоит?
>> в базу данных сервера DNS этого самого регистратора
> Вот-вот.
> Понял теперь наконец, почему у нас на двух серверах стоит бинд?
Расскажи, почему вы не оставили это регистратору.
Ещё раз: vesna.yandex.ru не является SOA.
---
"Vyroba umelych lidi, slecno, je tovarni tajemstvi."
> Вот-вот.
> Понял теперь наконец, почему у нас на двух серверах стоит бинд?
Расскажи, почему вы не оставили это регистратору.
Ещё раз: vesna.yandex.ru не является SOA.
---
"Vyroba umelych lidi, slecno, je tovarni tajemstvi."
Расскажи, почему вы не оставили это регистратору.Потому что мы и есть регистратор.
А теперь возьми и посмотри, сколько народу берёт SOA на себя.
---
"Vyroba umelych lidi, slecno, je tovarni tajemstvi."
---
"Vyroba umelych lidi, slecno, je tovarni tajemstvi."
На себя - очень мало.
Довольно большое количество народу так и остаются на наших. Практически все остальные используют сервера своих хостеров.
Довольно большое количество народу так и остаются на наших. Практически все остальные используют сервера своих хостеров.
А те, которые забирают, они что, никак не могут оставить это вам?
---
"Верь сводке погоды, но доверяй --- интуиции.
Будь особенно бдителен, когда всё хорошо и нет поводов для тревоги."
---
"Верь сводке погоды, но доверяй --- интуиции.
Будь особенно бдителен, когда всё хорошо и нет поводов для тревоги."
А они по каким-нибудь причинам предпочитают своего хостера.
Например, если у хостера собственно хостинг и обслуживание домена на его днс-серверах неразрывно связаны.
Например, если у хостера собственно хостинг и обслуживание домена на его днс-серверах неразрывно связаны.
> А они по каким-нибудь причинам предпочитают своего хостера.
Почему хостеры не перекладывают риск на вас?
---
...Я работаю антинаучным аферистом...
Почему хостеры не перекладывают риск на вас?
---
...Я работаю антинаучным аферистом...
Почему хостеры не перекладывают риск на вас?Потому что это - зона ответственности хостера.
Например, ip-адрес сервера может поменяться - и что дальше, рассылать всем пользователям письма "у нас сменился ip-адрес, обратитесь к своему регистратору, чтобы он поменял зону"?
А если пользователь создал поддомен - то что лучше, чтобы этот поддомен сразу заработал, или чтобы ему ещё и к регистратору надо было идти и руками там добавлять соответствующую запись в зону?
А если вдруг, не приведи бог, стадо бешеных экскаваторов напало сразу на оба датацентра, где стоят dns-сервера? Так же хостер уменьшает вероятность возможного выхода сайта из строя - от серверов хостинга толку-то без dns-серверов всё равно нет.
> Потому что это - зона ответственности хостера.
Кто это установил?
> Например, ip-адрес сервера может поменяться - и что дальше,
Пойти и через панель регистратора поменять этот же самый адрес.
SOA при этом не изменяется.
> А если пользователь создал поддомен - то что лучше, чтобы этот
> поддомен сразу заработал, или чтобы ему ещё и к регистратору
> надо было идти и руками там добавлять соответствующую запись в
> зону?
Чем это отличается от случая, когда то же самое ты делаешь через
собственную панель? Более того: работать будет быстрее из-за
уменьшения цепочки запросов при поиске от корня.
> А если вдруг, не приведи бог, стадо бешеных экскаваторов
> напало сразу на оба датацентра, где стоят dns-сервера?
Я живо представляю себе стада экскаваторов, совершающих
одновременные нападения на опорные пункты рунетов в Москве,
Париже и Стокгольме.
> Так же хостер уменьшает вероятность возможного выхода сайта из
> строя - от серверов хостинга толку-то без dns-серверов всё
> равно нет.
Ты в курсе, что если сломать все семь NS зоны "ru." (захватить
стадами экскаваторов там или тактические ядерные удары нанести
твой домен не будет доступен? Даже если твой хостер выживет и
не потеряет связности.
---
"Расширь своё сознание!"
Кто это установил?
> Например, ip-адрес сервера может поменяться - и что дальше,
Пойти и через панель регистратора поменять этот же самый адрес.
SOA при этом не изменяется.
> А если пользователь создал поддомен - то что лучше, чтобы этот
> поддомен сразу заработал, или чтобы ему ещё и к регистратору
> надо было идти и руками там добавлять соответствующую запись в
> зону?
Чем это отличается от случая, когда то же самое ты делаешь через
собственную панель? Более того: работать будет быстрее из-за
уменьшения цепочки запросов при поиске от корня.
> А если вдруг, не приведи бог, стадо бешеных экскаваторов
> напало сразу на оба датацентра, где стоят dns-сервера?
$ dnsqr ns ru.
2 ru:
290 bytes, 1+7+0+7 records, response, noerror
query: 2 ru
answer: ru 67484 NS ns.ripn.net
answer: ru 67484 NS ns2.nic.fr
answer: ru 67484 NS ns2.ripn.net
answer: ru 67484 NS ns5.msk-ix.net
answer: ru 67484 NS ns9.ripn.net
answer: ru 67484 NS sunic.sunet.se
answer: ru 67484 NS e.dns.ripn.net
additional: e.dns.ripn.net 67484 A 193.232.142.17
additional: ns.ripn.net 67484 A 194.85.105.17
additional: ns2.nic.fr 75715 A 192.93.0.4
additional: ns2.ripn.net 67484 A 194.226.96.30
additional: ns5.msk-ix.net 67484 A 193.232.128.6
additional: ns9.ripn.net 67484 A 194.85.252.62
additional: sunic.sunet.se 76238 A 192.36.125.2
Я живо представляю себе стада экскаваторов, совершающих
одновременные нападения на опорные пункты рунетов в Москве,
Париже и Стокгольме.
> Так же хостер уменьшает вероятность возможного выхода сайта из
> строя - от серверов хостинга толку-то без dns-серверов всё
> равно нет.
Ты в курсе, что если сломать все семь NS зоны "ru." (захватить
стадами экскаваторов там или тактические ядерные удары нанести
твой домен не будет доступен? Даже если твой хостер выживет и
не потеряет связности.
---
"Расширь своё сознание!"
(c)
Они сошлись. Волна и камень,
Стихи и проза, лед и пламень
Не столь различны меж собой.
Сперва взаимной разнотой
Они друг другу были скучны;
Потом понравились; потом
Съезжались каждый день верхом,
И скоро стали неразлучны.
Так люди (первый каюсь я)
От делать нечего друзья.
Пойти и через панель регистратора поменять этот же самый адрес.То есть, каждый клиент хостера должен зайти в панель регистратора и руками там менять этот адрес?
В нынешней схеме никаких действий от клиентов вообще не требуется.
Более того: работать будет быстрее из-заРазмер цепочки не зависит от того, на серверах регистратора или хостера обслуживается домен. Это всегда ещё плюс одно звено от корневой зоны.
уменьшения цепочки запросов при поиске от корня.
Я живо представляю себе стада экскаваторов, совершающихЯ живо себе представляю, как регистратор доменов добавляет запись "www.vasyapupkin.ru IN A 200.200.200.200" на сервер ns.ripn.net.
одновременные нападения на опорные пункты рунетов в Москве,
Париже и Стокгольме.
И я тебя уже тут спрашивал - если ты знаешь способ сделать так, чтобы твой домен обслуживался на корневых серверах зоны - давай, поделись.
Наши сервера - не корневые сервера зоны. Корневая зона знает только "vasyapupkin.ru IN NS dns1.webdrive.ru" и "vasyapupkin.ru IN NS dns2.webdrive.ru". Какая разница, сервера это регистратора или хостера?
Ты в курсе, что если сломать все семь NS зоны "ru." (захватитьВ курсе. Но от этого никуда не деться; а от захвата двух серверов регистратора предохраниться можно.
стадами экскаваторов там или тактические ядерные удары нанести
твой домен не будет доступен?
Тем более, что разных регистраторов много, а если сайт открываться не будет, клиент пойдёт выносить мозги именно хостеру (если же упала вся корневая зона .ru, то клиенту, скорее всего, и некуда будет идти).
Такое ощущение, что ты вообще ничего не знаешь о том предмете, о котором споришь.
>> Пойти и через панель регистратора поменять этот же самый адрес.
> То есть, каждый клиент хостера должен зайти в панель
> регистратора и руками там менять этот адрес?
А в чём, собственно, проблема? Тебе предложить схему передачи
данных от хостера к регистратору? Хостеру это выгоднее, чем
держать свой named: named (ты сам утверждал это) небезопасен,
а https --- необходимость. Хостеру было бы разумнее сразу
передавать данные регистратору и держать named там.
Когда-то панелей не было, они разрабатывались по уже готовым
схемам, с учётом имеющихся рисков. Вот и получается, что риск
взлома BIND уже тогда был настолько несущественен, что его можно
было держать у себя.
> В нынешней схеме никаких действий от клиентов вообще не требуется.
А кто тогда прописывает адрес? Хостер? Чем админ хостера
отличается от клиента, когда вбивает пару "адрес --- имя"
в панель? Какая ему разница, чья это панель, хостерская или
регистраторская?
>> Более того: работать будет быстрее из-за
>> уменьшения цепочки запросов при поиске от корня.
> Размер цепочки не зависит от того, на серверах регистратора
> или хостера обслуживается домен. Это всегда ещё плюс одно
> звено от корневой зоны.
На примере vesna.yandex.ru:
1. Твоя схема: . -> ns ru. -> ns yandex.ru. -> ns vesna.yandex.ru. -> vesna.yandex.ru.
Итого --- 4 запроса.
2. Моя схема: . -> ns ru. -> ns yandex.ru. -> vesna.yandex.ru.
Итого --- 3 запроса.
Только из-за того, что запись "vesna.yandex.ru" находится
не в зоне хостера "vesna.yandex.ru", а в зоне регистратора "yandex.ru."
> Я живо себе представляю, как регистратор доменов добавляет
> запись "www.vasyapupkin.ru IN A 200.200.200.200" на сервер
> ns.ripn.net.
А в чём дело? SOA туда кто-то добавляет же?
> И я тебя уже тут спрашивал - если ты знаешь способ сделать так,
> чтобы твой домен обслуживался на корневых серверах зоны -
> давай, поделись.
Захватить власть в какой-нибудь африканской стране.
> Наши сервера - не корневые сервера зоны. Корневая зона знает
> только "vasyapupkin.ru IN NS dns1.webdrive.ru"
> и "vasyapupkin.ru IN NS dns2.webdrive.ru".
> Какая разница, сервера это регистратора или хостера?
Большая:
1. Есть разница в скорости доступа к информации.
2. Если запись расположена на сервере хостера,
то _хостер_ подвергает себя риску взлома BIND.
>> Ты в курсе, что если сломать все семь NS зоны "ru." (захватить
>> стадами экскаваторов там или тактические ядерные удары нанести
>> твой домен не будет доступен?
> В курсе. Но от этого никуда не деться; а от захвата двух
> серверов регистратора предохраниться можно.
Вот и примени вот эту твою логику к вопросу, где надёжнее
хранить записи: а) на семи NS "ru.", или б) на двух NS хостера.
---
"Расширь своё сознание!"
> То есть, каждый клиент хостера должен зайти в панель
> регистратора и руками там менять этот адрес?
А в чём, собственно, проблема? Тебе предложить схему передачи
данных от хостера к регистратору? Хостеру это выгоднее, чем
держать свой named: named (ты сам утверждал это) небезопасен,
а https --- необходимость. Хостеру было бы разумнее сразу
передавать данные регистратору и держать named там.
Когда-то панелей не было, они разрабатывались по уже готовым
схемам, с учётом имеющихся рисков. Вот и получается, что риск
взлома BIND уже тогда был настолько несущественен, что его можно
было держать у себя.
> В нынешней схеме никаких действий от клиентов вообще не требуется.
А кто тогда прописывает адрес? Хостер? Чем админ хостера
отличается от клиента, когда вбивает пару "адрес --- имя"
в панель? Какая ему разница, чья это панель, хостерская или
регистраторская?
>> Более того: работать будет быстрее из-за
>> уменьшения цепочки запросов при поиске от корня.
> Размер цепочки не зависит от того, на серверах регистратора
> или хостера обслуживается домен. Это всегда ещё плюс одно
> звено от корневой зоны.
На примере vesna.yandex.ru:
1. Твоя схема: . -> ns ru. -> ns yandex.ru. -> ns vesna.yandex.ru. -> vesna.yandex.ru.
Итого --- 4 запроса.
2. Моя схема: . -> ns ru. -> ns yandex.ru. -> vesna.yandex.ru.
Итого --- 3 запроса.
Только из-за того, что запись "vesna.yandex.ru" находится
не в зоне хостера "vesna.yandex.ru", а в зоне регистратора "yandex.ru."
> Я живо себе представляю, как регистратор доменов добавляет
> запись "www.vasyapupkin.ru IN A 200.200.200.200" на сервер
> ns.ripn.net.
А в чём дело? SOA туда кто-то добавляет же?
> И я тебя уже тут спрашивал - если ты знаешь способ сделать так,
> чтобы твой домен обслуживался на корневых серверах зоны -
> давай, поделись.
Захватить власть в какой-нибудь африканской стране.
> Наши сервера - не корневые сервера зоны. Корневая зона знает
> только "vasyapupkin.ru IN NS dns1.webdrive.ru"
> и "vasyapupkin.ru IN NS dns2.webdrive.ru".
> Какая разница, сервера это регистратора или хостера?
Большая:
1. Есть разница в скорости доступа к информации.
2. Если запись расположена на сервере хостера,
то _хостер_ подвергает себя риску взлома BIND.
>> Ты в курсе, что если сломать все семь NS зоны "ru." (захватить
>> стадами экскаваторов там или тактические ядерные удары нанести
>> твой домен не будет доступен?
> В курсе. Но от этого никуда не деться; а от захвата двух
> серверов регистратора предохраниться можно.
Вот и примени вот эту твою логику к вопросу, где надёжнее
хранить записи: а) на семи NS "ru.", или б) на двух NS хостера.
---
"Расширь своё сознание!"
Тебе предложить схему передачиПредложи. И не забудь, что эта схема должна работать со всеми хостерами и регистраторами.
данных от хостера к регистратору?
Фактически, тебе нужно создать новый протокол для обмена этими данными. И совершенно непонятно, для чего.
а https --- необходимостьДля хостера и named - необходимость.
А кто тогда прописывает адрес? Хостер?Клиент один раз говорит "хочу сменить dns-сервера своего домена с регистраторских на ns1.hoster.ru, ns2.hoster.ru". После этого при смене айпи-адреса или там создании нового поддомена хостер уже где-то у себя в конфигах бинда что-то прописывает.
На примере vesna.yandex.ru:Моя схема ничего не говорит о том, куда мы пойдём после ns.yandex.ru. Откуда ты вообще этот "ns vesna.yandex.ru" взял? Речь о том, "ns yandex.ru." - это днс-сервера регистратора или хостера.
1. Твоя схема: . -> ns ru. -> ns yandex.ru. -> ns vesna.yandex.ru. -> vesna.yandex.ru.
Итого --- 4 запроса.
2. Моя схема: . -> ns ru. -> ns yandex.ru. -> vesna.yandex.ru.
Итого --- 3 запроса.
1. Есть разница в скорости доступа к информации.Какая разница в скорости доступа к серверам регистратора и серверам хостера? Первые могут быть быстрее, могут быть медленнее, а могут вообще стоять в том же шкафу.
к вопросу, где надёжнееОткуда же ты выдумал такой выбор, если, даже по твоим собственным словам, добавить A-записи на свой домен можно только если
хранить записи: а) на семи NS "ru.", или б) на двух NS хостера.
Ты давай всё-таки определись, что с чем сравниваешь. Есть:
Захватить власть в какой-нибудь африканской стране.
0) Корневые сервера интернета (о них, я так понимаю, тут речи всё-таки не идёт
1) Корневые сервера конкретной зоны (например, ru которые говорят, на каких dns-серверах обслуживается конкретный домен vasyapupkin.ru
2а) Днс-сервера регистратора доменов; возможно, vasyapupkin.ru обслуживается на них
2б) Днс-сервера хостера сайта vasyapupkin.ru и subdomain.vasyapupkin.ru; возможно, vasyapupkin.ru обслуживается на них.
Так что ты тут сравниваешь? Из некоторых твоих фраз следует, что ты пытаешься сравнить 1 с 2б - что выглядит полнейшим бредом.
А если ты всё-таки сравниваешь 2а с 2б - больше не упоминай эти семь серверов зоны ru, раскиданных по всему миру, они тут ни при чём.
Вот ты лучше расскажи почему WinXP может не устанавливать сервера DNS выданные по DHCP?
Какие есть средства диагностики?
Все устанавливают, одна машина - нет.
Сервер тоже вендовый.
Какие есть средства диагностики?
Все устанавливают, одна машина - нет.
Сервер тоже вендовый.
почему WinXP может не устанавливать сервера DNS выданные по DHCP?Например, поэтому:
>> Тебе предложить схему передачи
>> данных от хостера к регистратору?
> Предложи. И не забудь, что эта схема должна работать со всеми
> хостерами и регистраторами.
> Фактически, тебе нужно создать новый протокол для обмена этими данными.
> И совершенно непонятно, для чего.
Зачем создавать новый протокол? ISC DHCPD делает как раз то, что надо.
>> а https --- необходимость
> Для хостера и named - необходимость.
Не доказано.
>> А кто тогда прописывает адрес? Хостер?
> Клиент один раз говорит "хочу сменить dns-сервера своего
> домена с регистраторских на ns1.hoster.ru, ns2.hoster.ru".
Ещё раз: весь этот разговор начался с того, что ты утверждал,
будто запускать named небезопасно. Тогда клиенту НЕ ВЫГОДНО
делать то, что ты утверждаешь чуть выше.
Во-первых, из-за того, что увеличивается риск взлома служб с его
записями. (В три с половиной раза!)
Во-вторых, из-за того, что увеличивается время доступа к записям.
Если клиент всё-таки делает так, как ты утверждаешь, то есть,
переносит SOA ближе к себе, то риск взлома _ничтожен_.
Потому что клиент готов мириться с увеличением его вполчетверта.
Остальное не добавляет ничего нового.
---
"Всю цепь силлогизмов не читал..."
>> данных от хостера к регистратору?
> Предложи. И не забудь, что эта схема должна работать со всеми
> хостерами и регистраторами.
> Фактически, тебе нужно создать новый протокол для обмена этими данными.
> И совершенно непонятно, для чего.
Зачем создавать новый протокол? ISC DHCPD делает как раз то, что надо.
>> а https --- необходимость
> Для хостера и named - необходимость.
Не доказано.
>> А кто тогда прописывает адрес? Хостер?
> Клиент один раз говорит "хочу сменить dns-сервера своего
> домена с регистраторских на ns1.hoster.ru, ns2.hoster.ru".
Ещё раз: весь этот разговор начался с того, что ты утверждал,
будто запускать named небезопасно. Тогда клиенту НЕ ВЫГОДНО
делать то, что ты утверждаешь чуть выше.
Во-первых, из-за того, что увеличивается риск взлома служб с его
записями. (В три с половиной раза!)
Во-вторых, из-за того, что увеличивается время доступа к записям.
Если клиент всё-таки делает так, как ты утверждаешь, то есть,
переносит SOA ближе к себе, то риск взлома _ничтожен_.
Потому что клиент готов мириться с увеличением его вполчетверта.
Остальное не добавляет ничего нового.
---
"Всю цепь силлогизмов не читал..."
DHCPD делает как раз то, что надоОн не делает то, что тебе надо. Он не имеет вообще никакого отношения к тому, о чём ты говоришь.
Кстати, совсем забыл - а как ты авторизацию собираешься делать? Вот сказал какой-то мелкий хостер регистратору, который о нём впервые слышит, "добавьте на свои днсы такую-то А-запись" - и как нам понять, что этот хостер действительно имеет право такие записи добавлять?
Какие-то совершенно непонятные костыли непонятно зачем.
весь этот разговор начался с того, что ты утверждал,Клиент (в большинстве случаев) у себя никакие named не запускает. Он просто выбирает между обслуживанием на серверах регистратора и серверах хостера.
будто запускать named небезопасно. Тогда клиенту НЕ ВЫГОДНО
делать то, что ты утверждаешь чуть выше
Во-первых, из-за того, что увеличивается риск взлома служб с егоКакие три с половиной раза? У регистратора два dns-сервера, у хостера два dns-сервера.
записями. (В три с половиной раза!)
Ещё раз повторю тебе - определись наконец, что и с чем ты сравниваешь. А то говоришь "А лучше Б, потому что то-то и то-то", когда тебе указывают на то, что это несёт кучу недостатков - оказывается, что ты сравниваешь уже В и Б; а когда тебе указывают на то, что это бред - возвращаешься назад к сравнению А и Б.
Без определения предмета спора сам спор не имеет никакого смысла.
Если клиент всё-таки делает так, как ты утверждаешь, то есть,Для тех, кто в танке. Хостер и регистратор - одинаково близки к клиенту. Хостер и регистратор одинаково далеки от корневой зоны.
переносит SOA ближе к себе, то риск взлома _ничтожен_.
Мы - регистратор. Часть наших клиентов обслуживается на наших днс-серверах, часть переходит на днс-серверы хостера. Ты тут говоришь "зачем же они переходят куда-то от вас, ведь семь корневых серверов что-то там". Какое отношение семь корневых серверов имеют к нам?
Нет.
/release /renew и _даже_ ребут не помогают.
Ещё идеи?
Особенно про средства диагностики интересно, логи какие-нибудь.
/release /renew и _даже_ ребут не помогают.
Ещё идеи?
Особенно про средства диагностики интересно, логи какие-нибудь.
не знаю почему он ещё не посоветовал обратиться в тех. поддержку. если винда не ворованная, то самый правильный вариант.
>> DHCPD делает как раз то, что надо
> Он _не_ делает то, что тебе надо.
> Кстати, совсем забыл - а как ты авторизацию собираешься делать?
Отсюда следует, что ты DHCPD не настраивал.
Там и авторизация есть. RTFM.
>> весь этот разговор начался с того, что ты утверждал,
>> будто запускать named небезопасно. Тогда клиенту НЕ ВЫГОДНО
>> делать то, что ты утверждаешь чуть выше
> Клиент (в большинстве случаев) у себя никакие named не запускает.
> Он просто выбирает между обслуживанием на серверах регистратора
> и серверах хостера.
Ему НЕ ВЫГОДНО переходить на хостера именно из-за уменьшения
числа дублирующих друг друга серверов. Или ты не согласен с тем,
что одновременно сломать два named проще, чем их же, но семь?
>> Во-первых, из-за того, что увеличивается риск взлома служб с его
>> записями. (В три с половиной раза!)
> Какие три с половиной раза? У регистратора два dns-сервера, у
> хостера два dns-сервера.
Пересчитай количество NS "ru."
Даже если этих серверов по два, тогда не выгодно и клиенту, из
соображений скорости, и хостеру, потому что проблема взлома
становится его проблемой, а не проблемой регистратора.
> Ещё раз повторю тебе - определись наконец, что и с чем ты сравниваешь.
Я тебе постоянно это объясняю: я оцениваю --- в _твоём_ приближении
о небезопасности BIND --- выгоду перемещения записей от регистратора
к хостеру.
Я утверждаю, что раз и клиент, и хостер переносят записи к себе,
то твоё предположение о небезопасности BIND --- ложно.
>> Если клиент всё-таки делает так, как ты утверждаешь, то есть,
>> переносит SOA ближе к себе, то риск взлома _ничтожен_.
> Для тех, кто в танке. Хостер и регистратор - одинаково близки
> к клиенту. Хостер и регистратор одинаково далеки от корневой зоны.
Тогда клиенту безразлично, где у него записи, а хостеру всё равно
не выгодно забирать записи себе.
---
"Vyroba umelych lidi, slecno, je tovarni tajemstvi."
> Он _не_ делает то, что тебе надо.
> Кстати, совсем забыл - а как ты авторизацию собираешься делать?
Отсюда следует, что ты DHCPD не настраивал.
Там и авторизация есть. RTFM.
>> весь этот разговор начался с того, что ты утверждал,
>> будто запускать named небезопасно. Тогда клиенту НЕ ВЫГОДНО
>> делать то, что ты утверждаешь чуть выше
> Клиент (в большинстве случаев) у себя никакие named не запускает.
> Он просто выбирает между обслуживанием на серверах регистратора
> и серверах хостера.
Ему НЕ ВЫГОДНО переходить на хостера именно из-за уменьшения
числа дублирующих друг друга серверов. Или ты не согласен с тем,
что одновременно сломать два named проще, чем их же, но семь?
>> Во-первых, из-за того, что увеличивается риск взлома служб с его
>> записями. (В три с половиной раза!)
> Какие три с половиной раза? У регистратора два dns-сервера, у
> хостера два dns-сервера.
Пересчитай количество NS "ru."
Даже если этих серверов по два, тогда не выгодно и клиенту, из
соображений скорости, и хостеру, потому что проблема взлома
становится его проблемой, а не проблемой регистратора.
> Ещё раз повторю тебе - определись наконец, что и с чем ты сравниваешь.
Я тебе постоянно это объясняю: я оцениваю --- в _твоём_ приближении
о небезопасности BIND --- выгоду перемещения записей от регистратора
к хостеру.
Я утверждаю, что раз и клиент, и хостер переносят записи к себе,
то твоё предположение о небезопасности BIND --- ложно.
>> Если клиент всё-таки делает так, как ты утверждаешь, то есть,
>> переносит SOA ближе к себе, то риск взлома _ничтожен_.
> Для тех, кто в танке. Хостер и регистратор - одинаково близки
> к клиенту. Хостер и регистратор одинаково далеки от корневой зоны.
Тогда клиенту безразлично, где у него записи, а хостеру всё равно
не выгодно забирать записи себе.
---
"Vyroba umelych lidi, slecno, je tovarni tajemstvi."
Особенно про средства диагностики интересно, логи какие-нибудь.Как минимум, у тебя на сервере есть логи.
Как ты это представляешь - забрать у пользователя ноутбук, удалить всю корпоративную информацию и отправить его в штаб в Штаты, чтобы они его переслали в МС?
Или ты думаешь такую проблему можно решить по телефону? Те мальчики-девочки которые сидят на телефоне умеют дебажить по телефону?
Я спросил про средства диагностики, а не куда мне послать пользователя.
Или ты думаешь такую проблему можно решить по телефону? Те мальчики-девочки которые сидят на телефоне умеют дебажить по телефону?
Я спросил про средства диагностики, а не куда мне послать пользователя.
И что я увижу на сервере?
Проблема-то, очевидно, на стороне клиента:
- клиент спрашивает
- сервер отвечает
- клиент принимает и устанавливает настройки
Проблема на третьем шаге. Настройки одинаковые на всех клиентах, но один список оставляет пустым.
Куда копать?
Проблема-то, очевидно, на стороне клиента:
- клиент спрашивает
- сервер отвечает
- клиент принимает и устанавливает настройки
Проблема на третьем шаге. Настройки одинаковые на всех клиентах, но один список оставляет пустым.
Куда копать?
Ему НЕ ВЫГОДНО переходить на хостера именно из-за уменьшения
числа дублирующих друг друга серверов. Или ты не согласен с тем,
что одновременно сломать два named проще, чем их же, но семь?
Пересчитай количество NS "ru."Ещё раз тебе говорю - определись, что и с чем сравниваешь.
Глупо как-то выглядят твои посты "зачем клиенты уходят с ваших двух серверов, ведь ваши семь серверов лучше, чем два хостера".
тогда не выгодно и клиенту, изСо скоростью всё, в общем случае, совершенно одинаково. Количество звеньев цепи одно и то же.
соображений скорости
и хостеру, потому что проблема взломаЕсли сайт не работает - клиент обращается к хостеру. Так что - проблема хостера в любом случае.
становится его проблемой, а не проблемой регистратора
перемещения записей от регистратораТак ты просто не понимаешь каких-то базовых вещей о том, о чём споришь?
к хостеру.
Регистратор и корневая зона - совершенно разные вещи. Регистратор стоит на ступень ниже корневой зоны. В контексте днс-серверов любые сервера стоят на ступень ниже корневой зоны.
Домен vasyapupkin.ru может обслуживаться на dns-серверах регистратора, или хостера, или даже на личных серверах васи пупкина - во всех трёх случаях это один шаг от всех этих семи серверов вроде ns.ripn.net. Сервера ns.ripn.net не хранят о себе информацию о том, какому ip-адресу соответствует www.vasyapupkin.ru (и даже просто vasyapupkin.ru они только говорят о том, к каким днс-серверам надо обращаться за этой информацией. Это могут быть днс-сервера регистратора, или хостера, или что-нибудь ещё - неважно.
Тогда клиенту безразлично, где у него записиДа. Поэтому довольно большое количество клиентов оставляют записи у регистратора (если, конечно, он предоставляет такую услугу бесплатно; и если хостер не требует переноса записей к себе).
а хостеру всё равно не выгодно забирать записи себе.Хостеру это выгодно, потому что:
1) Если сайт открываться не будет по причине лежащих днс-серверов - клиент всё равно обратится к нему, а не к тому, у кого он покупал домен.
2) Если у какого-то из серверов хостера поменяется айпи-адрес, и он разошлёт всем клиентам письма "у нас поменялся ip-адрес, ваш сайт перестал работать, зайдите в панель управления регистратора (мы не знаем, какой у вас регистратор и что это за панель) и где-то там (сами как-нибудь найдите) поменяйте ip-адрес с такого-то на такой-то", на следующий день количество его клиентов уменьшится в разы, если не на порядки.
3) Если панель хостера, при добавлении нового подсайта, выдаст сообщение "а теперь зайдите в панель управления регистратора (мы не знаем, какой у вас регистратор и что это за панель) и где-то там (сами как-нибудь найдите) добавьте такую-то A-запись" - в большинстве случаев это будет последний день пользования клиента его услугами.
И что я увижу на сервере?Например, то, что он этому клиенту отправил не то, что остальным.
Проблема-то, очевидно, на стороне клиентаЕсли тебе это очевидно - то ты, наверное, и проблему сам решить сможешь.
> Ещё раз тебе говорю - определись, что и с чем сравниваешь.
Тебе ещё раз повторить?
> Глупо как-то выглядят твои посты "зачем клиенты уходят с ваших
> двух серверов, ведь ваши семь серверов лучше, чем два хостера".
Я тебе говорю прямо противоположное: клиенты или хостеры забирают
записи с семи серверов "ru." на свои два-три сервера.
>> тогда не выгодно и клиенту, из соображений скорости
> Со скоростью всё, в общем случае, совершенно одинаково.
> Количество звеньев цепи одно и то же.
Если отбросить возможность хранения в "ru.", да.
>> и хостеру, потому что проблема взлома
>> становится его проблемой, а не проблемой регистратора
> Если сайт не работает - клиент обращается к хостеру.
> Так что - проблема хостера в любом случае.
Ты никогда с таким не сталкивался, что ли?
В этих случаях работник хостера звонит регистратору,
и после это уже головная боль регистратора.
Итог: меньше работы хостеру, то есть, выгода.
> Сервера ns.ripn.net не хранят
Даже в этом случае хостеру выгоднее хранить записи у регистратора:
риск взлома BIND точно такой же, но работы у хостера убавляется,
как за счёт делегирования работы регистратору, так и за счёт
специализации на собственно хостинге.
>> а хостеру всё равно не выгодно забирать записи себе.
> Хостеру это выгодно, потому что:
> 1) Если сайт открываться не будет по причине лежащих
> днс-серверов - клиент всё равно обратится к нему, а не к тому,
> у кого он покупал домен.
Ответственность по устранению ошибок DNS тогда ложится на хостера,
а не на регистратора. Это ОЧЕНЬ НЕ ВЫГОДНО. Особенно --- если
договором предусмотрена материальная ответственность за простой.
> 2) Если у какого-то из серверов хостера поменяется айпи-адрес,
> и он разошлёт всем клиентам письма "у нас поменялся ip-адрес,
> ваш сайт перестал работать, зайдите в панель управления
> регистратора (мы не знаем, какой у вас регистратор и что это
> за панель)
Это не проблема, поскольку хостер знает регистратора и это можно
проверить. Так что вмешательства клиента не требуется.
> 3) Если панель хостера, при добавлении нового подсайта, выдаст
> сообщение "а теперь зайдите в панель управления регистратора
> (мы не знаем, какой у вас регистратор и что это за панель)
Это гон, узнать NS не проблема, далее см. выше.
> в большинстве случаев это будет последний день пользования
> клиента его услугами.
То есть, ты таки не признаёшь, что named непробиваем настолько,
что никто не заморачивается особой его защитой или перекладыванием
ответственности (рисков) за взлом?
Всё, что ты пишешь, это оправдания, что любая мелочь важнее
опасности взлома named, из-за чего его выгоднее взять себе,
а не отдать в любые более надёжные руки.
---
"Разве было бы плохо перевернуть перевёрнутый мир?"
Тебе ещё раз повторить?
> Глупо как-то выглядят твои посты "зачем клиенты уходят с ваших
> двух серверов, ведь ваши семь серверов лучше, чем два хостера".
Я тебе говорю прямо противоположное: клиенты или хостеры забирают
записи с семи серверов "ru." на свои два-три сервера.
>> тогда не выгодно и клиенту, из соображений скорости
> Со скоростью всё, в общем случае, совершенно одинаково.
> Количество звеньев цепи одно и то же.
Если отбросить возможность хранения в "ru.", да.
>> и хостеру, потому что проблема взлома
>> становится его проблемой, а не проблемой регистратора
> Если сайт не работает - клиент обращается к хостеру.
> Так что - проблема хостера в любом случае.
Ты никогда с таким не сталкивался, что ли?
В этих случаях работник хостера звонит регистратору,
и после это уже головная боль регистратора.
Итог: меньше работы хостеру, то есть, выгода.
> Сервера ns.ripn.net не хранят
Даже в этом случае хостеру выгоднее хранить записи у регистратора:
риск взлома BIND точно такой же, но работы у хостера убавляется,
как за счёт делегирования работы регистратору, так и за счёт
специализации на собственно хостинге.
>> а хостеру всё равно не выгодно забирать записи себе.
> Хостеру это выгодно, потому что:
> 1) Если сайт открываться не будет по причине лежащих
> днс-серверов - клиент всё равно обратится к нему, а не к тому,
> у кого он покупал домен.
Ответственность по устранению ошибок DNS тогда ложится на хостера,
а не на регистратора. Это ОЧЕНЬ НЕ ВЫГОДНО. Особенно --- если
договором предусмотрена материальная ответственность за простой.
> 2) Если у какого-то из серверов хостера поменяется айпи-адрес,
> и он разошлёт всем клиентам письма "у нас поменялся ip-адрес,
> ваш сайт перестал работать, зайдите в панель управления
> регистратора (мы не знаем, какой у вас регистратор и что это
> за панель)
Это не проблема, поскольку хостер знает регистратора и это можно
проверить. Так что вмешательства клиента не требуется.
> 3) Если панель хостера, при добавлении нового подсайта, выдаст
> сообщение "а теперь зайдите в панель управления регистратора
> (мы не знаем, какой у вас регистратор и что это за панель)
Это гон, узнать NS не проблема, далее см. выше.
> в большинстве случаев это будет последний день пользования
> клиента его услугами.
То есть, ты таки не признаёшь, что named непробиваем настолько,
что никто не заморачивается особой его защитой или перекладыванием
ответственности (рисков) за взлом?
Всё, что ты пишешь, это оправдания, что любая мелочь важнее
опасности взлома named, из-за чего его выгоднее взять себе,
а не отдать в любые более надёжные руки.
---
"Разве было бы плохо перевернуть перевёрнутый мир?"
Тебе ещё раз повторить?Ты ещё ни разу не ответил на этот вопрос. Что повторять-то?
Ну хорошо, если ты думаешь, что ты уже ответил - повтори.
Если отбросить возможность хранения в "ru.", да.Наши два сервера - это никоим образом не "ru.".
И ты уже говорил, что надо захватить африканскую страну, чтобы хранить данные о своих доменах в хоть какой-то корневой зоне.
В этих случаях работник хостера звонит регистраторуТолько "в этих случаях" работнику хостеру ещё надо понять, что же это за днс-сервера такие, на которых обслуживается домен (а это совсем не обязательно именно регистратор, это может быть что угодно).
поскольку хостер знает регистратораЕсть тысячи мелких регистраторов и миллионы мелких хостеров. Что, все друг друга знают?
Это гон, узнать NS не проблема, далее см. выше.Ты знаешь, что vasyapupkin.ru обслуживается на ns1.somedns.ru и ns2.somedns.ru. При этом, самого сайта somedns.ru может и не быть, а управление происходит через superbestdnshosting.net - ты про это не знаешь.
любая мелочь важнееЭто не "любая мелочь". Это огромная куча серьёзных недостатков.
опасности взлома named
Да, большинство хостеров предпочитают иметь десять тысяч клиентов и самим думать об опасностях взлома named, чем переложить эту обязанность на регистратора, а самим сидеть с сотней клиентов (если у них хотя бы сотня наберётся, с таким-то геморроем для клиентов).
> Наши два сервера - это никоим образом не "ru.".
Хорошо, опровергай вторую альтернативу.
>> В этих случаях работник хостера звонит регистратору
> Только "в этих случаях" работнику хостеру ещё надо понять, что
> же это за днс-сервера такие, на которых обслуживается домен (а
> это совсем не обязательно именно регистратор, это может быть
> что угодно).
1. Если хостер не всегда забирает записи себе, это так и так придётся делать.
2. Это не так сложно сделать. Можно добавить это на панель.
>> поскольку хостер знает регистратора
> Есть тысячи мелких регистраторов и миллионы мелких хостеров.
> Что, все друг друга знают?
Насколько я понимаю, ни DNS, ни whois мы пока не отменяли.
>> любая мелочь важнее опасности взлома named
> Это не "любая мелочь". Это огромная куча серьёзных недостатков.
Вся эта куча состоит из технически и организационно разрешимых
вопросов, которые все были бы реализованы алгоритмически,
_если_бы_только_, как ты утверждаешь, существовал ощутимый
риск взлома named.
Так вот, этот риск не был существенен даже тогда,
когда named был, по сегодняшним меркам, дыряв как решето.
---
"...Но и без чтения мы разбирались в том,
в каком идти, в каком сражаться стане."
Хорошо, опровергай вторую альтернативу.
>> В этих случаях работник хостера звонит регистратору
> Только "в этих случаях" работнику хостеру ещё надо понять, что
> же это за днс-сервера такие, на которых обслуживается домен (а
> это совсем не обязательно именно регистратор, это может быть
> что угодно).
1. Если хостер не всегда забирает записи себе, это так и так придётся делать.
2. Это не так сложно сделать. Можно добавить это на панель.
>> поскольку хостер знает регистратора
> Есть тысячи мелких регистраторов и миллионы мелких хостеров.
> Что, все друг друга знают?
Насколько я понимаю, ни DNS, ни whois мы пока не отменяли.
>> любая мелочь важнее опасности взлома named
> Это не "любая мелочь". Это огромная куча серьёзных недостатков.
Вся эта куча состоит из технически и организационно разрешимых
вопросов, которые все были бы реализованы алгоритмически,
_если_бы_только_, как ты утверждаешь, существовал ощутимый
риск взлома named.
Так вот, этот риск не был существенен даже тогда,
когда named был, по сегодняшним меркам, дыряв как решето.
---
"...Но и без чтения мы разбирались в том,
в каком идти, в каком сражаться стане."
1. Если хостер не всегда забирает записи себе, это так и так придётся делать.Именно поэтому многие хостеры всегда забирают записи себе.
2. Это не так сложно сделать. Можно добавить это на панель.На какую панель, что добавить? Читай пост внимательнее.
Насколько я понимаю, ни DNS, ни whois мы пока не отменяли.Во-первых, если сервер обслуживается не на серверах хостера - это не значит, что он обслуживается на серверах регистратора. Так что от whois никакого толку.
Во-вторых - что толку от DNS? Это не поможет тебе понять, по какому телефону звонить, если они некорректно работают.
Вся эта куча состоит из технически и организационно разрешимыхМного конкретных хостеров боятся, что их named сломают. Это как-то поможет разработке стандарта на общение между хостерами и регистраторами (непонятно, нахрена нужное)?
вопросов, которые все были бы реализованы алгоритмически,
_если_бы_только_, как ты утверждаешь, существовал ощутимый
риск взлома named.
Для сообщества в целом риск одинаков, используются сервера регистраторов или хостеров. Так зачем что-то придумывать?
А если объединятся только хостеры, и только они придумают какой-то стандарт - толку-то, если регистраторы его не реализуют?
> Для сообщества в целом риск одинаков, используются сервера
> регистраторов или хостеров.
> Так зачем что-то придумывать?
Это всё означает, что риск пренебрежимо мал.
А тогда спрашивается: чем пользователю мешает его собственный DNS cache?
Это помогает с настройкой сети (я откровенно не понимаю, зачем
вбивать 8 двух-трёхзначных чисел, когда можно сказать "делай сам"
это уменьшает задержки и отвязывает от проблем серверов провайдера.
Кстати, там был ещё вопрос про то, как ты собираешься из сети
взломать BIND, работающий на 127.0.0.1. Ты на него будешь отвечать?
---
...Я работаю антинаучным аферистом...
> регистраторов или хостеров.
> Так зачем что-то придумывать?
Это всё означает, что риск пренебрежимо мал.
А тогда спрашивается: чем пользователю мешает его собственный DNS cache?
Это помогает с настройкой сети (я откровенно не понимаю, зачем
вбивать 8 двух-трёхзначных чисел, когда можно сказать "делай сам"
это уменьшает задержки и отвязывает от проблем серверов провайдера.
Кстати, там был ещё вопрос про то, как ты собираешься из сети
взломать BIND, работающий на 127.0.0.1. Ты на него будешь отвечать?
---
...Я работаю антинаучным аферистом...
Это всё означает, что риск пренебрежимо мал.Риск для кого?
Риск для конкретного хостера - велик. Риск для сообщества от каждого конкретного сервера - тоже велик, но ты не предлагаешь сообществу снизить этот риск, ты предлагаешь переложить его с одних членов сообщества на других - от этого риск, каким бы он ни был, не изменится.
отвязывает от проблем серверов провайдераТогда переформулируй вопрос с "почему в винде не ставится по умолчанию bind-сервер", а "почему эти идиоты, разрабатывающие устройство интернета, придумали всю эту хрень с провайдерскими серверами и кэшированием на них, а не просто сказали всем, чтобы они спрашивали корневые сервера".
>> Это всё означает, что риск пренебрежимо мал.
> Риск для кого?
Для клиента, для хостера и для регистратора --- для всех.
> ты не предлагаешь сообществу снизить этот риск, ты предлагаешь
> переложить его с одних членов сообщества на других - от этого
> риск, каким бы он ни был, не изменится.
Когда риск перекладывается на специалистов, он уменьшается.
Объяснять, почему?
>> отвязывает от проблем серверов провайдера
> Тогда переформулируй
Перечитай обсуждение, если памяти не хватает.
Оно идёт как раз от твоего упорного нежелания признать, что риск
взлома named настолько мал, что его можно использовать хоть на
любой машине.
---
...Я работаю антинаучным аферистом...
> Риск для кого?
Для клиента, для хостера и для регистратора --- для всех.
> ты не предлагаешь сообществу снизить этот риск, ты предлагаешь
> переложить его с одних членов сообщества на других - от этого
> риск, каким бы он ни был, не изменится.
Когда риск перекладывается на специалистов, он уменьшается.
Объяснять, почему?
>> отвязывает от проблем серверов провайдера
> Тогда переформулируй
Перечитай обсуждение, если памяти не хватает.
Оно идёт как раз от твоего упорного нежелания признать, что риск
взлома named настолько мал, что его можно использовать хоть на
любой машине.
---
...Я работаю антинаучным аферистом...
ipconfig /flushdns?
Когда риск перекладывается на специалистов, он уменьшаетсяКто сказал, что регистратор доменов - больший специалист по днс, чем хостер?
А при твоей схеме потребуются ещё и специалисты по протоколу общения между хостерами и регистраторами.
Для клиента, для хостера и для регистратора --- для всех.Риск велик для всех.
Но для клиента риск велик одинаково, не зависимо от того, у кого обслуживается домен - у хостера или регистратора. А хостеры, может быть, и хотели бы спихнуть управление днсами регистраторам, но для этого (если они не хотят растерять всех своих клиентов) придётся придумывать какие-то протоколы управления зонами доменов, которые хостятся у этих хостеров, общения между хостерами и регистраторами, а также принуждения регистраторов реализовывать эти протоколы.
Перечитай обсуждение, если памяти не хватает.У меня хватает памяти.
Ты тут только что меня пытался убедить в том, что днс-сервера провайдеров не нужны, потому что есть корневая зона. Вот с этого и надо было начинать.
Если бы все были согласны с тем, что днс-сервера провайдеров не нужны - их бы и не было. И по dhcp никакие dns-сервера не выдавались бы (кроме разве что для резолвинга локальных адресов). И все работали бы через корневую зону.
Только почему-то в реальности всё не так. А то, как работает винда - не причина, а следствие того, как устроен интернет. Винда вообще умела сама, из коробки, работать с сетью, когда появилась нынешняя схема работы днс-серверов?
Завтра -)
Ушёл пользователь с компом.
Ушёл пользователь с компом.
> У меня хватает памяти.
> Ты тут только что меня пытался убедить в том, что днс-сервера
> провайдеров не нужны, потому что есть корневая зона.
Я этого не говорил.
Я говорил ровно про то, что написано выше: для простых случаев,
когда пользователь хочет "интернету," надо включать локальный кеш,
а не пудрить ему мозг с провайдерскими адресами.
> Если бы все были согласны с тем, что днс-сервера провайдеров
> не нужны - их бы и не было.
Во времена WatTCP они и правда были нужны.
> Винда вообще умела сама, из коробки, работать с сетью,
> когда появилась нынешняя схема работы днс-серверов?
Ты хочешь, чтобы я нашёл RFC и посмотрел дату выпуска?
Найди и посмотри сам.
Сейчас это никого не волнует. Уже лет пять, по меньшей мере,
любая вменяемая машина может иметь набортный named.
---
"This user is BSD-compliant."
> Ты тут только что меня пытался убедить в том, что днс-сервера
> провайдеров не нужны, потому что есть корневая зона.
Я этого не говорил.
Я говорил ровно про то, что написано выше: для простых случаев,
когда пользователь хочет "интернету," надо включать локальный кеш,
а не пудрить ему мозг с провайдерскими адресами.
> Если бы все были согласны с тем, что днс-сервера провайдеров
> не нужны - их бы и не было.
Во времена WatTCP они и правда были нужны.
> Винда вообще умела сама, из коробки, работать с сетью,
> когда появилась нынешняя схема работы днс-серверов?
Ты хочешь, чтобы я нашёл RFC и посмотрел дату выпуска?
Найди и посмотри сам.
Сейчас это никого не волнует. Уже лет пять, по меньшей мере,
любая вменяемая машина может иметь набортный named.
---
"This user is BSD-compliant."
для простых случаев,который будет работать непосредственно с корневой зоной. А локальные провайдерские сервера не нужны.
когда пользователь хочет "интернету," надо включать локальный кеш
Из твоих слов именно так и выходит.
Сейчас это никого не волнует. Уже лет пять, по меньшей мере,А раньше - не могла, что ли?
любая вменяемая машина может иметь набортный named
По-твоему, единственное, из-за чего устроили всё это с провайдерскими серверами - то, что клиентские машины не могли иметь набортный named?
> который будет работать непосредственно с корневой зоной.
> А локальные провайдерские сервера не нужны.
Да, никому из моих знакомых не нужны ресурсы локальной сети,
они нисколько об этом не жалеют. Я не знаю, зачем им вообще
надо знать о существовании этих провайдерских DNS.
>> Сейчас это никого не волнует. Уже лет пять, по меньшей мере,
>> любая вменяемая машина может иметь набортный named
> А раньше - не могла, что ли?
Да, во времена KA9Q NOS и WatTCP не могла.
> По-твоему, единственное, из-за чего устроили всё это с
> провайдерскими серверами - то, что клиентские машины не могли
> иметь набортный named?
Изначально --- да. Это потом уже придумали PSN и "split horizon."
---
...Я работаю антинаучным аферистом...
> А локальные провайдерские сервера не нужны.
Да, никому из моих знакомых не нужны ресурсы локальной сети,
они нисколько об этом не жалеют. Я не знаю, зачем им вообще
надо знать о существовании этих провайдерских DNS.
>> Сейчас это никого не волнует. Уже лет пять, по меньшей мере,
>> любая вменяемая машина может иметь набортный named
> А раньше - не могла, что ли?
Да, во времена KA9Q NOS и WatTCP не могла.
> По-твоему, единственное, из-за чего устроили всё это с
> провайдерскими серверами - то, что клиентские машины не могли
> иметь набортный named?
Изначально --- да. Это потом уже придумали PSN и "split horizon."
---
...Я работаю антинаучным аферистом...
Я утверждаю, что раз и клиент, и хостер переносят записи к себе,т.е. если миллион мух ставит себе windows, то предположение о небезопасности windows - ложно?
то твоё предположение о небезопасности BIND --- ложно.
ок. запишу себе в блокнотик, и буду ссылаться на самого Контра-у
ps
может все-таки следует, что они имеют от переноса к себе больше плюсов, чем минусов, связанных с атакой на bind?
может все-таки следует, что они имеют от переноса к себе больше плюсов, чем минусов, связанных с атакой на bind?Я ему уже которую страницу пытаюсь это объяснить. Точнее, то, что от не-переноса к себе они поимели бы гораздо больше геморроя, совершенно несравнимого с потенциальной атакой на bind.
> может все-таки следует, что они имеют от переноса к себе
> больше плюсов, чем минусов, связанных с атакой на bind?
Я в курсе, что у тебя с логикой проблемы, поэтому отвечу только
один раз.
1. Пенартур утверждает, что запускать BIND на личной системе
очень небезопасно.
1а. Даже на 127.0.0.1.
2. Предположим, что (1) верно.
3. Тогда все те люди, которые запускают BIND по производственной
необходимости, подвергают себя существенному риску.
4. У этих людей из (3) есть возможность перекладывать
ответственность за риски так, чтобы эти риски уменьшались
за счёт:
4а. дублирования
4б. выполнения работы более узкими специалистами.
5. При этом перераспределении рисков возникают технические и
организационные трудности, которые известно, как решать.
6. Однако этот путь перераспределения рисков, никак не был
задействован.
7. Следовательно, эти риски с запуском named пренебрежимы
даже в масштабах предприятий.
8. ПРОТИВОРЕЧИЕ.
Не может быть так, чтобы риски были существенны для единичного
человека, но несущественны для многих.
Сам вывод сделаешь или учебник по матлогике откроешь?
---
"Vyroba umelych lidi, slecno, je tovarni tajemstvi."
> больше плюсов, чем минусов, связанных с атакой на bind?
Я в курсе, что у тебя с логикой проблемы, поэтому отвечу только
один раз.
1. Пенартур утверждает, что запускать BIND на личной системе
очень небезопасно.
1а. Даже на 127.0.0.1.
2. Предположим, что (1) верно.
3. Тогда все те люди, которые запускают BIND по производственной
необходимости, подвергают себя существенному риску.
4. У этих людей из (3) есть возможность перекладывать
ответственность за риски так, чтобы эти риски уменьшались
за счёт:
4а. дублирования
4б. выполнения работы более узкими специалистами.
5. При этом перераспределении рисков возникают технические и
организационные трудности, которые известно, как решать.
6. Однако этот путь перераспределения рисков, никак не был
задействован.
7. Следовательно, эти риски с запуском named пренебрежимы
даже в масштабах предприятий.
8. ПРОТИВОРЕЧИЕ.
Не может быть так, чтобы риски были существенны для единичного
человека, но несущественны для многих.
Сам вывод сделаешь или учебник по матлогике откроешь?
---
"Vyroba umelych lidi, slecno, je tovarni tajemstvi."
> Я ему уже которую страницу пытаюсь это объяснить.
Да блин, тогда объясни, как у тебя получается так, что риски
запуска named в масштабах предприятия ничтожны, а запустить
на локальной машине --- на 127.1 --- ты боишься.
---
"Юношеству занятий масса.
Грамматикам учим дурней и дур мы."
Да блин, тогда объясни, как у тебя получается так, что риски
запуска named в масштабах предприятия ничтожны, а запустить
на локальной машине --- на 127.1 --- ты боишься.
---
"Юношеству занятий масса.
Грамматикам учим дурней и дур мы."
как у тебя получается так, что рискиУ меня не получается, что они ничтожны. У меня получается только то, что они менее значимы, чем весь тот геморрой, который придётся нести в противном случае.
запуска named в масштабах предприятия ничтожны
Точнее, в масштабах одного конкретного хостера даже и геморроя-то не будет, он просто лишится своих клиентов. А в масштабах всего сообщества риски от этого named - величина постоянная, как ты их между разными предприятиями ни распределяй.
4. У этих людей из (3) есть возможность перекладыватьИ которые:
ответственность за риски так, чтобы эти риски уменьшались
за счёт:
4а. дублирования
4б. выполнения работы более узкими специалистами.
5. При этом перераспределении рисков возникают технические и
организационные трудности, которые известно, как решать.
1) Невозможно решить в рамках одного предприятия;
2) Можно решить в рамках всего сообщества - но в это сообщество входят и те, на чьи головы перекладывается ответственность; то есть, сообществу в целом никаких плюсов решение этих трудностей не даст.
> И которые:
> 1) Невозможно решить в рамках одного предприятия;
> 2) Можно решить в рамках всего сообщества - но в это
> сообщество входят и те, на чьи головы перекладывается
> ответственность.
Если бы BIND представлял такую проблему, то эти задачи пытались
бы решать. Ты можешь привести пример таких попыток?
Ты лучше скажи, ты с выводом согласен или нет?
---
"Я знаю правду! Все прежние правды --- прочь!"
> 1) Невозможно решить в рамках одного предприятия;
> 2) Можно решить в рамках всего сообщества - но в это
> сообщество входят и те, на чьи головы перекладывается
> ответственность.
Если бы BIND представлял такую проблему, то эти задачи пытались
бы решать. Ты можешь привести пример таких попыток?
Ты лучше скажи, ты с выводом согласен или нет?
---
"Я знаю правду! Все прежние правды --- прочь!"
то эти задачи пыталисьЕщё раз.
бы решать
Эти задачи:
1) Невозможно решить в рамках одного предприятия. Поэтому отдельные хостеры их и не пытаются решать, вне зависимость от проблем, которые для них предоставляет BIND - всё равно ничего не выйдет, это бессмысленно.
2) Можно решить в рамках всего сообщества - но в это сообщество входят и те, на чьи головы перекладывается ответственность; то есть, сообществу в целом никаких плюсов решение этих трудностей не даст. Поэтому сообщество в целом и не пытается их решать - вне зависимости от того, какую проблему представляет BIND для отдельных его членов, решение этой задачи только позволило бы ценой большого геморроя переложить проблему с одних членов сообщества на других.
Ты лучше скажи, ты с выводом согласен или нет?Нет.
И я тебе уже написал, с какого момента я не согласен с твоей цепочкой и почему.
оно разве не кеш очищает?
1. Пенартур утверждает, что запускать BIND на личной системемне кажется, что ты делишь мир на черное и белое.
очень небезопасно.
т.е. либо очень небезопасно, либо очень безопасно.
а как быть, если запускать BIND на личной системе?
1. просто(а не очень) небезопасно
2. чуть-чуть небезопасно.
3. скорее безопасно, но есть ненулевая вероятность, что опасно
и т.д.
будет ли для вариантов 1-3 твоя цепочка рассуждений заканчиваться противоречием?
будет ли противоречить вариантам 1-3 - утверждение "что если bind можно не ставить, то лучше не ставить"?
> а как быть, если запускать BIND на личной системе?
> 1. просто(а не очень) небезопасно
> 2. чуть-чуть небезопасно.
> 3. скорее безопасно, но есть ненулевая вероятность, что опасно и т.д.
Вот и расскажи, как у тебя получается, что один и тот же BIND в
корпоративной среде менее безопасен, чем дома.
И ещё, для тупых, я не просто так везде употреблял слово "риски,"
а не "безопасен."
---
"Всё определяется мерой, числом и весом."
> 1. просто(а не очень) небезопасно
> 2. чуть-чуть небезопасно.
> 3. скорее безопасно, но есть ненулевая вероятность, что опасно и т.д.
Вот и расскажи, как у тебя получается, что один и тот же BIND в
корпоративной среде менее безопасен, чем дома.
И ещё, для тупых, я не просто так везде употреблял слово "риски,"
а не "безопасен."
---
"Всё определяется мерой, числом и весом."
> Эти задачи:
> 1) Невозможно решить в рамках одного предприятия.
Если была бы потребность, то писали бы протоколы и договаривались,
но этого, как ты и сам утверждаешь, не произошло --- аргумент
в мою пользу.
> 2) Можно решить в рамках всего сообщества - но в это
> сообщество входят и те, на чьи головы перекладывается
> ответственность
В таких случаях пытаются договориться о разделении ответственности,
пишут какие-то протоколы, однако этого не происходило и не происходит,
что опять является аргументом в мою пользу: использование BIND не несёт
ощутимого риска.
>> Ты лучше скажи, ты с выводом согласен или нет?
> Нет.
> И я тебе уже написал, с какого момента я не согласен с твоей
> цепочкой и почему.
Я тебе не раз показал, что все твои мнимые опровержения ничего
не опровергают, а наоборот, доказывают, что использование BIND
не несёт какого-либо ощутимого риска.
---
"МЕТАН --- ТОПЛИВО XXI ВЕКА"
> 1) Невозможно решить в рамках одного предприятия.
Если была бы потребность, то писали бы протоколы и договаривались,
но этого, как ты и сам утверждаешь, не произошло --- аргумент
в мою пользу.
> 2) Можно решить в рамках всего сообщества - но в это
> сообщество входят и те, на чьи головы перекладывается
> ответственность
В таких случаях пытаются договориться о разделении ответственности,
пишут какие-то протоколы, однако этого не происходило и не происходит,
что опять является аргументом в мою пользу: использование BIND не несёт
ощутимого риска.
>> Ты лучше скажи, ты с выводом согласен или нет?
> Нет.
> И я тебе уже написал, с какого момента я не согласен с твоей
> цепочкой и почему.
Я тебе не раз показал, что все твои мнимые опровержения ничего
не опровергают, а наоборот, доказывают, что использование BIND
не несёт какого-либо ощутимого риска.
---
"МЕТАН --- ТОПЛИВО XXI ВЕКА"
В таких случаях пытаются договориться о разделении ответственности,О каком разделении ответственности?
пишут какие-то протоколы, однако этого не происходило и не происходитПотому что ценой огромного геморроя и каких-то кривых костылеобразных протоколов, не нужных ни для чего, кроме перекладывания ответственности с одной головы на другую - мы не получаем абсолютно ничего, кроме этой кривизны, которую надо поддерживать, и перекладывания ответственности (вместе с рисками) с одних членов сообщества на других.
В чём смысл этого, независимо от ответственности BIND?
Или ты думаешь, что, если бы BIND был очень опасным - все тут же начали разрабатывать эти костылеобразные протоколы? Так зачем? Какие преимущества это даёт сообществу, кроме кривых, не имеющих никакого смысла в реальном мире, протоколов и увеличения поверхности для потенциальных атак (плюс ещё одна служба у каждого регистратора)?
Я тебе не раз показал, что все твои мнимые опровержения ничегоЯ тебе не раз показал, что все твои рассуждения (точнее, только те из них, которые осмысленны; около половины твоих рассуждений в этом треде - бред человека, не имеющего никакого представления о предмете спора) ничего не говорят об опасности/безопасности BIND.
не опровергают, а наоборот, доказывают, что использование BIND
не несёт какого-либо ощутимого риска.
> Или ты думаешь, что, если бы BIND был очень опасным -
> все тут же начали разрабатывать эти костылеобразные протоколы?
Да! Стали бы. Можешь посмотреть на BCP 30 про защиту от спама,
SPF и прочие протоколы вокруг нашего любимого SMTP.
Остальной твой бред можно выкинуть, ты понятия не имеешь,
как организуются такие вещи.
---
"Vyroba umelych lidi, slecno, je tovarni tajemstvi."
> все тут же начали разрабатывать эти костылеобразные протоколы?
Да! Стали бы. Можешь посмотреть на BCP 30 про защиту от спама,
SPF и прочие протоколы вокруг нашего любимого SMTP.
Остальной твой бред можно выкинуть, ты понятия не имеешь,
как организуются такие вещи.
---
"Vyroba umelych lidi, slecno, je tovarni tajemstvi."
Остальной твой бред можно выкинуть, ты понятия не имеешь,И это говорит человек, который понятия не имеет о предмете спора и даже не имеет своей чёткой позиции в нём?
как организуются такие вещи.
гавнотема с совершенно левым сабжем превратилась в мега флудильню
ура кохтпа!
ура кохтпа!
Я тебе изложил и предмет спора и позицию в нём:
1. Windows не может даже правильно настроиться по DHCP.
2. MS не умеет правильно разрабатывать:
а) ни пользовательскую часть, потому что неверно определяет цели
пользователей, иначе бы они допускали запускать DNS cache;
б) ни системную часть, потому что их состема не может правильно
интерпретировать DHCP;
в) ни интерфейсную часть, потому что нет никаких, не говоря уже
о вменяемых, средств диагностики проблем с тем же DHCP.
Никаких из перечисленных недостатков нет в UNIX(TM который
легко используется той самой конкретной "домохозяйкой," про
которую ты так любишь говорить.
UNIX(TM) везде здесь, не NetBSD, которая ей никогда не была и не есть.
UNIX(TM) --- это MacOS X 10.сколько нужно.
Добро пожаловать в реальный мир твоих домохозяек.
А спор весь ведётся по поводу твоей частной глупости,
что запускать named якобы опасно. В этой глупости ты
упорно отказываешься признаться, потому что:
а) ты не разбираешься в рисках;
б) ты не разбираешься в безопасности (где ответ на вопросы про
BIND на 127.1?);
в) ты не разбираешься в организационных вопросах (у тебя
отсутствуют представления о том, как организуется рабочее
взаимодействие между организациями, если есть реальная
проблема).
---
"Vyroba umelych lidi, slecno, je tovarni tajemstvi."
1. Windows не может даже правильно настроиться по DHCP.
2. MS не умеет правильно разрабатывать:
а) ни пользовательскую часть, потому что неверно определяет цели
пользователей, иначе бы они допускали запускать DNS cache;
б) ни системную часть, потому что их состема не может правильно
интерпретировать DHCP;
в) ни интерфейсную часть, потому что нет никаких, не говоря уже
о вменяемых, средств диагностики проблем с тем же DHCP.
Никаких из перечисленных недостатков нет в UNIX(TM который
легко используется той самой конкретной "домохозяйкой," про
которую ты так любишь говорить.
UNIX(TM) везде здесь, не NetBSD, которая ей никогда не была и не есть.
UNIX(TM) --- это MacOS X 10.сколько нужно.
Добро пожаловать в реальный мир твоих домохозяек.
А спор весь ведётся по поводу твоей частной глупости,
что запускать named якобы опасно. В этой глупости ты
упорно отказываешься признаться, потому что:
а) ты не разбираешься в рисках;
б) ты не разбираешься в безопасности (где ответ на вопросы про
BIND на 127.1?);
в) ты не разбираешься в организационных вопросах (у тебя
отсутствуют представления о том, как организуется рабочее
взаимодействие между организациями, если есть реальная
проблема).
---
"Vyroba umelych lidi, slecno, je tovarni tajemstvi."
а) ни пользовательскую часть, потому что неверно определяет целиНеверно. Такие проблемы - у тебя одного, весь остальной мир спокойно работает с двумя DNS и радуется.
пользователей, иначе бы они допускали запускать DNS cache;
Добро пожаловать в реальный мир твоих домохозяек.В реальном мире домохозяек им пофигу на то, сколько там днс, им главное, чтобы на mail.ru зайти можно было. А если зайти почему-то нельзя - они звонят провайдеру и он чинит интернет. Результаты отличаются только в том случае, когда у провайдера кривые руки, и первые два из выданных им трёх днс лежат, а третий (и весь остальной интернет) - работает. В этом случае всё равно надо звонить провайдеру, а если он так ничего и не починит - перейти к другому, а если других нет - прописать два рабочих dns-сервера руками.
В этой глупости тыПотому что ты:
упорно отказываешься признаться, потому что
1) Так и не смог внятно сказать, почему ты считаешь это глупостью;
2) Показал полнейшее незнание предмета спора.
ты не разбираешься в рисках;Я разбираюсь в рисках. И я, в отличие от тебя, представляю, что мир не делится на две части "риски ничтожны" и "риски настолько огромны, что любой ценой надо не допустить использование BIND".
Для тебя же средних вариантов нет, и ты делаешь неверный логический переход "раз хостеры не пытаются изо всех сил, любой ценой, скинуть на кого-то другого ответственность за bind - значит, риски не так огромны, а значит, они ничтожны".
тебяЕщё раз тебе повторяю - реальной проблемы для сообщества здесь нет. Величина проблемы - абсолютный ноль, независимо от того, какую опасность представляет BIND для отдельных его членов.
отсутствуют представления о том, как организуется рабочее
взаимодействие между организациями, если есть реальная
проблема
От всех этих костылей к SMTP преимущества для сообщества очевидны - уменьшение количества спама. Какие, по-твоему, преимущества для сообщества несёт перекладывание BIND с одних его членов на других?
И повторю проигнорированный тобой вопрос:
Ты давай всё-таки определись, что с чем сравниваешь. Есть:
0) Корневые сервера интернета (о них, я так понимаю, тут речи всё-таки не идёт
1) Корневые сервера конкретной зоны (например, ru которые говорят, на каких dns-серверах обслуживается конкретный домен vasyapupkin.ru
2а) Днс-сервера регистратора доменов; возможно, vasyapupkin.ru обслуживается на них
2б) Днс-сервера хостера сайта vasyapupkin.ru и subdomain.vasyapupkin.ru; возможно, vasyapupkin.ru обслуживается на них.
> Неверно. Такие проблемы - у тебя одного,
Проблемы возникли не уменя, а у конкретного человека без
технического образования. Если бы винда прописала третий
адрес, этих проблем не возникло бы. Если бы у "домохозяйки"
была кнопка "just [censored] do it", её бы ткнули, и всё
заработало. А так --- пришлось меня просить.
> весь остальной мир спокойно работает с двумя DNS и радуется.
Весь какой мир? В твоём воображении?
>> Добро пожаловать в реальный мир твоих домохозяек.
> В реальном мире домохозяек им пофигу на то, сколько там днс,
> им главное, чтобы на mail.ru зайти можно было. А если зайти
> почему-то нельзя - они звонят провайдеру и он чинит интернет.
> Результаты отличаются только в том случае, когда у провайдера
> кривые руки, и первые два из выданных им трёх днс лежат, а
> третий (и весь остальной интернет) - работает.
Если бы система работала, ей не надо было бы звонить.
Более того, если бы работал локальный кеш, проблема не могла бы
возникнуть.
Вот и получается
>> В этой глупости ты упорно отказываешься признаться, потому что
> Потому что ты:
> 1) Так и не смог внятно сказать, почему ты считаешь это глупостью;
Я тебе показал, что весь мир, в том числе и корневые серверы,
работают на named без каких-либо проблем. Про случаи взлома
ничего не слышно. Более того, почти весь мир работает с named
так, как будто любая мелочь важнее рисков, связанных с его
использованием. Более того, если бы вообще существовали проблемы,
то они отразились бы во взаимоотношениях между вовлечёнными
организациями: хостерами, регистраторами, провайдерами,--- и
клиентами. Нет ни единого свидетельства, что named несёт
какой-либо риск. Вон, даже силлогизм тебе выстроили, а ты чушь
какую-то несёшь. Я понимаю, что мозг может отсутствовать, но
может постараешься его включить?
> 2) Показал полнейшее незнание предмета спора.
Это наглая ложь. См. выше.
> Я разбираюсь в рисках. И я, в отличие от тебя, представляю,
> что мир не делится на две части "риски ничтожны" и "риски
> настолько огромны, что любой ценой надо не допустить
> использование BIND". Для тебя же средних вариантов нет,
У меня _все_ переходные варианты учтены. Ты не можешь привести
ни единого свидетельства, что риск сколь-либо существенен,
потому что _это_не_так_.
>> тебя отсутствуют представления о том, как организуется
>> рабочее взаимодействие между организациями, если есть
>> реальная проблема
> Ещё раз тебе повторяю - реальной проблемы для сообщества здесь нет.
> Величина проблемы - абсолютный ноль, независимо от того, какую
> опасность представляет BIND для отдельных его членов.
Эти слова выражают то, что я тебе и доказываю:
что риск, связанный с BIND --- никакой.
Ты хотя бы в собственных показаниях можешь не путаться?
Так вот, из того, что он никакой и следует, что твои слова
"дело не в ресурсах, а в ещё одном сервере с ещё одной пачкой
потенциальных уязвимостей" --- необоснованное предубеждение.
>> И повторю проигнорированный тобой вопрос:
>> Ты давай всё-таки определись, что с чем сравниваешь. Есть:
>> 0) Корневые сервера интернета (о них, я так понимаю, тут речи
>> всё-таки не идёт
>> 1) Корневые сервера конкретной зоны (например, ru которые
>> говорят, на каких dns-серверах обслуживается конкретный домен
>> vasyapupkin.ru
>> 2а) Днс-сервера регистратора доменов; возможно,
>> vasyapupkin.ru обслуживается на них
>> 2б) Днс-сервера хостера сайта vasyapupkin.ru и subdomain.vasyapupkin.ru;
>> возможно, vasyapupkin.ru обслуживается на них.
1 и 2а, 2а и 2б, 1 и 2б.
---
"Vyroba umelych lidi, slecno, je tovarni tajemstvi."
Проблемы возникли не уменя, а у конкретного человека без
технического образования. Если бы винда прописала третий
адрес, этих проблем не возникло бы. Если бы у "домохозяйки"
была кнопка "just [censored] do it", её бы ткнули, и всё
заработало. А так --- пришлось меня просить.
> весь остальной мир спокойно работает с двумя DNS и радуется.
Весь какой мир? В твоём воображении?
>> Добро пожаловать в реальный мир твоих домохозяек.
> В реальном мире домохозяек им пофигу на то, сколько там днс,
> им главное, чтобы на mail.ru зайти можно было. А если зайти
> почему-то нельзя - они звонят провайдеру и он чинит интернет.
> Результаты отличаются только в том случае, когда у провайдера
> кривые руки, и первые два из выданных им трёх днс лежат, а
> третий (и весь остальной интернет) - работает.
Если бы система работала, ей не надо было бы звонить.
Более того, если бы работал локальный кеш, проблема не могла бы
возникнуть.
Вот и получается
>> В этой глупости ты упорно отказываешься признаться, потому что
> Потому что ты:
> 1) Так и не смог внятно сказать, почему ты считаешь это глупостью;
Я тебе показал, что весь мир, в том числе и корневые серверы,
работают на named без каких-либо проблем. Про случаи взлома
ничего не слышно. Более того, почти весь мир работает с named
так, как будто любая мелочь важнее рисков, связанных с его
использованием. Более того, если бы вообще существовали проблемы,
то они отразились бы во взаимоотношениях между вовлечёнными
организациями: хостерами, регистраторами, провайдерами,--- и
клиентами. Нет ни единого свидетельства, что named несёт
какой-либо риск. Вон, даже силлогизм тебе выстроили, а ты чушь
какую-то несёшь. Я понимаю, что мозг может отсутствовать, но
может постараешься его включить?
> 2) Показал полнейшее незнание предмета спора.
Это наглая ложь. См. выше.
> Я разбираюсь в рисках. И я, в отличие от тебя, представляю,
> что мир не делится на две части "риски ничтожны" и "риски
> настолько огромны, что любой ценой надо не допустить
> использование BIND". Для тебя же средних вариантов нет,
У меня _все_ переходные варианты учтены. Ты не можешь привести
ни единого свидетельства, что риск сколь-либо существенен,
потому что _это_не_так_.
>> тебя отсутствуют представления о том, как организуется
>> рабочее взаимодействие между организациями, если есть
>> реальная проблема
> Ещё раз тебе повторяю - реальной проблемы для сообщества здесь нет.
> Величина проблемы - абсолютный ноль, независимо от того, какую
> опасность представляет BIND для отдельных его членов.
Эти слова выражают то, что я тебе и доказываю:
что риск, связанный с BIND --- никакой.
Ты хотя бы в собственных показаниях можешь не путаться?
Так вот, из того, что он никакой и следует, что твои слова
"дело не в ресурсах, а в ещё одном сервере с ещё одной пачкой
потенциальных уязвимостей" --- необоснованное предубеждение.
>> И повторю проигнорированный тобой вопрос:
>> Ты давай всё-таки определись, что с чем сравниваешь. Есть:
>> 0) Корневые сервера интернета (о них, я так понимаю, тут речи
>> всё-таки не идёт
>> 1) Корневые сервера конкретной зоны (например, ru которые
>> говорят, на каких dns-серверах обслуживается конкретный домен
>> vasyapupkin.ru
>> 2а) Днс-сервера регистратора доменов; возможно,
>> vasyapupkin.ru обслуживается на них
>> 2б) Днс-сервера хостера сайта vasyapupkin.ru и subdomain.vasyapupkin.ru;
>> возможно, vasyapupkin.ru обслуживается на них.
1 и 2а, 2а и 2б, 1 и 2б.
---
"Vyroba umelych lidi, slecno, je tovarni tajemstvi."
Если бы система работала, ей не надо было бы звонить.Да. Если бы система у провайдера работала - ей не надо было бы звонить.
Но система у провайдера _не_ работает. Провайдер предоставляет три сервера, из которых два не работают. Причём не работают, видимо, у всех - то есть, у всех пользователей этого провайдера, сидящих под виндой, интернет не работает.
Что же за провайдер такой?
так, как будто любая мелочь важнее рисковОписанное тобой - не "любая мелочь".
Более того, если бы вообще существовали проблемы,Во-первых - с какой стати? Да даже если бы это была проблема вселенского масштаба - вряд ли отразилась бы.
то они отразились бы во взаимоотношениях между вовлечёнными
организациями: хостерами, регистраторами, провайдерами,--- и
клиентами.
Во-вторых - каким образом она должна была бы отразиться, по-твоему? Регистраторы сказали бы "у нас тут риска что-то мало, а давайте мы ещё новый протокол придумаем, чтобы и клиентов хостеров нам своим BIND поддерживать, и ещё один протокол открыть"?
> Величина проблемы - абсолютный ноль, независимо от того, какуюТы действительно не умеешь читать или только прикидываешься?
> опасность представляет BIND для отдельных его членов.
Эти слова выражают то, что я тебе и доказываю:
что риск, связанный с BIND --- никакой.
Риск, связанный с BIND, для конкретного члена сообщества, использующего BIND - может быть сколь угодно большим, один этот член ничего не изменит.
Риск, связанный с BIND, для всего сообщества - может быть сколь угодно большим, но ты его не уменьшишь, переведя ответственность с одного члена сообщества на другого.
1 и 2а ... 1 и 2б.А теперь объясни мне, в каких случаях у пользователя есть выбор между хранением своих A-записей на корневых серверах зоны (те самые семь ns.ripn.net) и на серверах регистратора/хостера.
Ты сам говорил, что для того, чтобы получить доступ к корневой зоне - надо захватить африканскую страну. Ну да, у каждого васи пупкина в кармане лежит по десятку африканских стран.
Вот и опять подтверждается, что ты тут с умным видом рассуждаешь о том, о чём не имеешь ни малейшего понятия.
> Провайдер предоставляет три сервера, из которых два не
> работают. Причём не работают, видимо, у всех
Откуда это следует?
Я этого не говорил, я не работаю в её провайдере и могу вообще
ничего не знать про него.
> у всех пользователей этого провайдера, сидящих под виндой,
> интернет не работает.
Система рабочая, UNIX(TM) той же владелицы работает без проблем.
> Во-первых - с какой стати? Да даже если бы это была проблема
> вселенского масштаба - вряд ли отразилась бы.
Ну да? У тебя есть замечательный пример SMTP.
Ты хочешь сказать, что к неправильно настроенным серверам не
применяется административных мер принудительного характера?
> Во-вторых - каким образом она должна была бы отразиться,
> по-твоему?
Как угодно. Про серьёзные проблемы с BIND писали бы на всех
углах, но --- не пишут.
>>> Величина проблемы - абсолютный ноль, независимо от того, какую
>>> опасность представляет BIND для отдельных его членов.
>> Эти слова выражают то, что я тебе и доказываю:
>> что риск, связанный с BIND --- никакой.
> Ты действительно не умеешь читать или только прикидываешься?
> Риск, связанный с BIND, для конкретного члена сообщества,
> использующего BIND - может быть сколь угодно большим, один
> этот член ничего не изменит.
Ты определись со своими методами аргументации: то ты пишешь, что
"обезумевшие хомячки" в клочья разорвут, то твои миллионы мух
ничего не решают.
> А теперь объясни мне, в каких случаях у пользователя есть
> выбор между хранением своих A-записей на корневых серверах
Причём здесь пользователь, если эта нить разговора про
организации, вовлечённые в построение этих ваших интернетов?
---
"Унивеpситет pазвивает все способности, в том числе --- глупость."
> работают. Причём не работают, видимо, у всех
Откуда это следует?
Я этого не говорил, я не работаю в её провайдере и могу вообще
ничего не знать про него.
> у всех пользователей этого провайдера, сидящих под виндой,
> интернет не работает.
Система рабочая, UNIX(TM) той же владелицы работает без проблем.
> Во-первых - с какой стати? Да даже если бы это была проблема
> вселенского масштаба - вряд ли отразилась бы.
Ну да? У тебя есть замечательный пример SMTP.
Ты хочешь сказать, что к неправильно настроенным серверам не
применяется административных мер принудительного характера?
> Во-вторых - каким образом она должна была бы отразиться,
> по-твоему?
Как угодно. Про серьёзные проблемы с BIND писали бы на всех
углах, но --- не пишут.
>>> Величина проблемы - абсолютный ноль, независимо от того, какую
>>> опасность представляет BIND для отдельных его членов.
>> Эти слова выражают то, что я тебе и доказываю:
>> что риск, связанный с BIND --- никакой.
> Ты действительно не умеешь читать или только прикидываешься?
> Риск, связанный с BIND, для конкретного члена сообщества,
> использующего BIND - может быть сколь угодно большим, один
> этот член ничего не изменит.
Ты определись со своими методами аргументации: то ты пишешь, что
"обезумевшие хомячки" в клочья разорвут, то твои миллионы мух
ничего не решают.
> А теперь объясни мне, в каких случаях у пользователя есть
> выбор между хранением своих A-записей на корневых серверах
Причём здесь пользователь, если эта нить разговора про
организации, вовлечённые в построение этих ваших интернетов?
---
"Унивеpситет pазвивает все способности, в том числе --- глупость."
пенартур, твои аргументы на уровне гуманитария. Я почитал кохтпу - у него всё логично и понятно. А ты просто срёшь. Иди нахуй.
дада, всё очень логично
а кто-нить знает на каком языке написано ядро кохтпы?
а кто-нить знает на каком языке написано ядро кохтпы?
лисп
а можно где-нить скачать, хочу на локальной тачке поиздеваццо 
Откуда это следует?Оттуда, что для тебя вызвало проблемы то, что винда использовала только два сервера из этих трёх.
> у всех пользователей этого провайдера, сидящих под виндой,Ты разучился изъясняться связно?
> интернет не работает.
Система рабочая, UNIX(TM) той же владелицы работает без проблем.
У тебя есть замечательный пример SMTP.Ещё раз повторяю - в случае с SMTP решение проблемы что-то даёт сообществу. В случае с BIND, независимо от величины проблемы (и если она имеет вселенский масштаб, и если её вообще нет) её решение не даёт абсолютно ничего сообществу в целом. Сообщество ничего не получает от того, что оно перекладывает проблему с одних своих членов на других.
ты пишешь, что"Обезумевшие хомячки", если хостер заставит их всё делать руками, уйдут к другому хостеру. Естественный отбор привёл к тому, что хостеры держат зону у себя.
"обезумевшие хомячки" в клочья разорвут
А на какие меры, по-твоему, способны обезумевшие провайдеры по отношению к регистраторам?
Причём здесь пользователь, если эта нить разговора проНить разговора - не про организации.
организации, вовлечённые в построение этих ваших интернетов?
Ещё раз. В каком случае имеет смысл непосредственное сравнение 1 и 2а/2б? Это всё равно, что напрямую сравнивать пакет молока и стадо коров - совершенно бессмысленное занятие.
>> Откуда это следует?
> Оттуда, что для тебя вызвало проблемы то, что винда
> использовала только два сервера из этих трёх.
Откуда следует, что они не работают "у всех?"
Они могут просто быть заняты работой, ты не в курсе?
UDP может теряться, ты тоже не в курсе?
Потери зависят от того, где именно в сетке ты сидишь. Тоже не в курсе?
>>> у всех пользователей этого провайдера, сидящих под виндой,
>>> интернет не работает.
>> Система рабочая, UNIX(TM) той же владелицы работает без проблем.
> Ты разучился изъясняться связно?
Что тебе здесь непонятно? Рядом лежат два ноута, ассоциированы
с одной и той же точкой, один на UNIX(TM другой на винде.
UNIX(TM) работает, винда нет. Краткое исследование вопроса
вскрывает, что на самом деле сеть есть, просто виндовая состема
не прописала третий DNS. Отсюда следует, что проблемы в винде,
а не в провайдере или настройках коммутационного оборудования.
>> У тебя есть замечательный пример SMTP.
> Ещё раз повторяю - в случае с SMTP решение проблемы что-то
> даёт сообществу.
Да, потому что проблема с SMTP реальная, а не иллюзорная,
как в случае с BIND.
> В случае с BIND, независимо от величины проблемы
Если сломать 7 NS "ru.", у тебя встанет весь рунет,
если сломать 14 корневых NS, встанет всё, кроме PSN.
> А на какие меры, по-твоему, способны обезумевшие провайдеры по
> отношению к регистраторам?
Нарушение контракта влечёт материальную ответственность.
---
"Vyroba umelych lidi, slecno, je tovarni tajemstvi."
> Оттуда, что для тебя вызвало проблемы то, что винда
> использовала только два сервера из этих трёх.
Откуда следует, что они не работают "у всех?"
Они могут просто быть заняты работой, ты не в курсе?
UDP может теряться, ты тоже не в курсе?
Потери зависят от того, где именно в сетке ты сидишь. Тоже не в курсе?
>>> у всех пользователей этого провайдера, сидящих под виндой,
>>> интернет не работает.
>> Система рабочая, UNIX(TM) той же владелицы работает без проблем.
> Ты разучился изъясняться связно?
Что тебе здесь непонятно? Рядом лежат два ноута, ассоциированы
с одной и той же точкой, один на UNIX(TM другой на винде.
UNIX(TM) работает, винда нет. Краткое исследование вопроса
вскрывает, что на самом деле сеть есть, просто виндовая состема
не прописала третий DNS. Отсюда следует, что проблемы в винде,
а не в провайдере или настройках коммутационного оборудования.
>> У тебя есть замечательный пример SMTP.
> Ещё раз повторяю - в случае с SMTP решение проблемы что-то
> даёт сообществу.
Да, потому что проблема с SMTP реальная, а не иллюзорная,
как в случае с BIND.
> В случае с BIND, независимо от величины проблемы
Если сломать 7 NS "ru.", у тебя встанет весь рунет,
если сломать 14 корневых NS, встанет всё, кроме PSN.
> А на какие меры, по-твоему, способны обезумевшие провайдеры по
> отношению к регистраторам?
Нарушение контракта влечёт материальную ответственность.
---
"Vyroba umelych lidi, slecno, je tovarni tajemstvi."
>>> у всех пользователей этого провайдера, сидящих под виндой,Что не отменяет того факта, что:
>>> интернет не работает.
>> Система рабочая, UNIX(TM) той же владелицы работает без проблем.
> Ты разучился изъясняться связно?
Что тебе здесь непонятно? Рядом лежат два ноута, ассоциированы
с одной и той же точкой, один на UNIX(TM другой на винде.
UNIX(TM) работает, винда нет. Краткое исследование вопроса
вскрывает, что на самом деле сеть есть, просто виндовая состема
не прописала третий DNS. Отсюда следует, что проблемы в винде,
а не в провайдере или настройках коммутационного оборудования.
у всех пользователей этого провайдера, сидящих под виндой, интернет не работает.
Да, потому что проблема с SMTP реальная, а не иллюзорная, как в случае с BIND.Нет, не поэтому.
Ещё раз повторяю - _независимо_ от величины проблемы с BIND, такое её решение, какое предлагаешь ты, сообществу в целом не даст ничего. От того, что ты переложил деньги из левого кармана в правый, их количество у тебя не увеличится. Ты можешь даже изобрести суперперекладывалку денег между карманами, работающую на батарейках, которая все деньги, которые попадают в левый карман, будет перекладывать в правый; а когда ты будешь засовывать руку в левый карман, она будет доставать деньги из правого (зашитого) и подкладывать в левый. У этой перекладывалки будет только один минус - если батарейки сядут, ты вообще до денег не доберёшься, пока их не заменишь.
Но количество денег в твоих карманах от создания этого устройства не увеличится. И практическая ценность такого устройства равна абсолютному нулю, вне зависимости от того, сколько у тебя денег в карманах.
Если сломать 7 NS "ru.", у тебя встанет весь рунет,Допустим (у тебя же есть воображение? BIND очень уязвим, все хостеры и регистраторы собрались и под твоим чутким руководством разработали этот замечательный
если сломать 14 корневых NS, встанет всё, кроме PSN.
Какое тогда отношение это твоё "если сломать 7 NS "ru."" имеет к "провайдеры и регистраторы не разрабатывают совместно описанные выше костыли"?
Нарушение контракта влечёт материальную ответственность.А, так у нас уже хостеры заключают договора с регистраторами? И в этих договорах написано, что регистратор обязан держать записи у себя?
Речь шла о том, что обезумевшие провайдеры не могут заставить сообщество изобрести описанный выше
Не стоит изобретать лишних сущностей и костылей там, где они не нужны.
> Что не отменяет того факта, что:
p> у всех пользователей этого провайдера, сидящих под виндой,
p> интернет не работает.
Это вообще не факт, это твоё предположение.
И пока оно не доказано, его следует считать ложным.
> Ещё раз повторяю - _независимо_ от величины проблемы с BIND
Ты пишешь бред и не читаешь разъяснения.
Если бы существовали какие-нибудь проблемы с BIND, про них
писали бы на каждом углу и их пытались бы как-нибудь решать.
Но --- _не_ пишут и _не_ решают.
Это означает, что проблемы есть только у тебя в голове, а не в BIND.
>> Если сломать 7 NS "ru.", у тебя встанет весь рунет,
>> если сломать 14 корневых NS, встанет всё, кроме PSN.
> Допустим (у тебя же есть воображение? BIND очень уязвим,
> все хостеры и регистраторы собрались
Уже этого достаточно, чтобы признать, что BIND достаточно уязвим.
Ещё раз: достаточно простого факта признания наличия проблем
и попыток их как-то решать. Как решать --- не важно. Достаточно
решать как-нибудь и даже просто писать.
_Нет_ ни того, ни другого.
А значит и проблема с named существует только у тебя в голове.
---
"Дебилы, несмотря на замедленность и конкретность мышления,
низкий уровень суждений, узкий кругозор, бедный запас слов
и слабую память, способны к приобретению некоторых знаний
и профессиональных навыков."
p> у всех пользователей этого провайдера, сидящих под виндой,
p> интернет не работает.
Это вообще не факт, это твоё предположение.
И пока оно не доказано, его следует считать ложным.
> Ещё раз повторяю - _независимо_ от величины проблемы с BIND
Ты пишешь бред и не читаешь разъяснения.
Если бы существовали какие-нибудь проблемы с BIND, про них
писали бы на каждом углу и их пытались бы как-нибудь решать.
Но --- _не_ пишут и _не_ решают.
Это означает, что проблемы есть только у тебя в голове, а не в BIND.
>> Если сломать 7 NS "ru.", у тебя встанет весь рунет,
>> если сломать 14 корневых NS, встанет всё, кроме PSN.
> Допустим (у тебя же есть воображение? BIND очень уязвим,
> все хостеры и регистраторы собрались
Уже этого достаточно, чтобы признать, что BIND достаточно уязвим.
Ещё раз: достаточно простого факта признания наличия проблем
и попыток их как-то решать. Как решать --- не важно. Достаточно
решать как-нибудь и даже просто писать.
_Нет_ ни того, ни другого.
А значит и проблема с named существует только у тебя в голове.
---
"Дебилы, несмотря на замедленность и конкретность мышления,
низкий уровень суждений, узкий кругозор, бедный запас слов
и слабую память, способны к приобретению некоторых знаний
и профессиональных навыков."
Если бы существовали какие-нибудь проблемы с BIND, про нихЕсть одна большая проблема с BIND. А именно - работающий BIND (как и любая другая служба) - большая потенциальная дырка.
писали бы на каждом углу и их пытались бы как-нибудь решать.
Ещё раз: достаточно простого факта признания наличия проблемЕщё раз.
и попыток их как-то решать
У тебя отрицание факта признания наличия проблем хостеров.
А попыток их решать нет, потому что в рамках нынешней системы решить их невозможно и бессмысленно. У меня в кармане мало денег - это проблема. Но я не изобретаю перекладывалку денег из левого кармана в правый, потому что это бессмысленно и ни капли не поможет решить проблему.
А значит и проблема с named существует только у тебя в голове.В твоей голове проблема с named существует только у меня в голове. А в реальности проблема с named существует (как и с любым другим сервисом просто ты отказываешься её замечать и говоришь "2*2=4, небо сегодня безоблачное, а по коридору не бегает голая секретарша - значит, проблем с named нет. Если бы они были, все бы рвали на себе волосы, а секретарша в отчаянии бегала бы по коридору в голом виде".
> Есть одна большая проблема с BIND. А именно - работающий BIND
> (как и любая другая служба) - большая потенциальная дырка.
На примере корневых серверов легко увидеть, что это наглая ложь.
Никакой большой потенциальной дырки нет даже тогда, когда BIND
слушает внешний адрес, а не 127.1.
И да, если винда пробрасывает пакеты из сети на 127.1, тем хуже
для неё. UNIX(TM) так не делает.
> У тебя отрицание факта признания наличия проблем хостеров.
Да, и этого достаточно, чтобы утверждать, что все твои проблемы
с BIND вымышлены.
> В твоей голове проблема с named существует только у меня в голове.
> А в реальности проблема с named существует (как и с любым другим
> сервисом)
Сломай какой-нибудь корневой сервер, они достаточно нагружены,
чтобы увеличить вероятность нештатного режима. Докажи, что ты
не лжёшь. У меня есть к этому все основания, поскольку проблем
с BIND на практике не было уже очень давно, а все находимые
сейчас уязвимости отыскиваются путём анализа кода, примеров
эксплуатации уязвимостей давно нет.
> Если бы они были, все бы рвали на себе волосы, а секретарша в
> отчаянии бегала бы по коридору в голом виде".
Да, потому что, если бы проблемы на самом деле были, время от
времени на техподдержку обрушивался шквал звонков, а сам демон
приходилось бы перезапускать. Но ничего такого не происходит.
---
"Narrowness of experience leads to narrowness of imagination."
> (как и любая другая служба) - большая потенциальная дырка.
На примере корневых серверов легко увидеть, что это наглая ложь.
Никакой большой потенциальной дырки нет даже тогда, когда BIND
слушает внешний адрес, а не 127.1.
И да, если винда пробрасывает пакеты из сети на 127.1, тем хуже
для неё. UNIX(TM) так не делает.
> У тебя отрицание факта признания наличия проблем хостеров.
Да, и этого достаточно, чтобы утверждать, что все твои проблемы
с BIND вымышлены.
> В твоей голове проблема с named существует только у меня в голове.
> А в реальности проблема с named существует (как и с любым другим
> сервисом)
Сломай какой-нибудь корневой сервер, они достаточно нагружены,
чтобы увеличить вероятность нештатного режима. Докажи, что ты
не лжёшь. У меня есть к этому все основания, поскольку проблем
с BIND на практике не было уже очень давно, а все находимые
сейчас уязвимости отыскиваются путём анализа кода, примеров
эксплуатации уязвимостей давно нет.
> Если бы они были, все бы рвали на себе волосы, а секретарша в
> отчаянии бегала бы по коридору в голом виде".
Да, потому что, если бы проблемы на самом деле были, время от
времени на техподдержку обрушивался шквал звонков, а сам демон
приходилось бы перезапускать. Но ничего такого не происходит.
---
"Narrowness of experience leads to narrowness of imagination."
На примере корневых серверов легко увидеть, что это наглая ложь.Сходи что ли в словарь и посмотри значение слова "потенциальный".
Никакой большой потенциальной дырки нет
А на примере корневых серверов увидеть вообще ничего нельзя - там не тот уровень поддержки. Да, там прекрасно осознают все риски и проблемы, связанные с поддержкой BIND - и там есть соответствующие специалисты, призванные эти проблемы как-то решать. У простого домашнего пользователя этих специалистов нет.
Да, и этого достаточно, чтобы утверждать, что все твои проблемыТебе того, что творится у тебя в голове - достаточно для того, чтобы что-то утверждать.
с BIND вымышлены.
Но реальная жизнь от твоей головы не зависит. Проблемы с BIND никуда не денутся от того, что какой-то там КОНТРА на форуме МГУ скажет "я отрицаю наличие проблем у хостеров".
Сломай какой-нибудь корневой серверПовторно отправляю тебя в словарь
Да, потому что, если бы проблемы на самом деле были, время отПочему ты думаешь, что такого не бывает?
времени на техподдержку обрушивался шквал звонков, а сам демон
приходилось бы перезапускать.
Или ты считаешь, что у хостеров вообще всегда всё идеально, а техподдержка там только в носу ковыряет и отвечает на глупые вопросы блондинок?
> Сходи что ли в словарь и посмотри значение слова "потенциальный".
Если потенциальная проблема существует, должна быть возможность
обращения её в реальную. Покажи такую возможность.
> А на примере корневых серверов увидеть вообще ничего нельзя -
> там не тот уровень поддержки.
Не нравятся корневые серверы, приводи отчёты CERT или
аналогичных организаций.
> У простого домашнего пользователя этих специалистов нет.
BIND у меня домашнего является тем же самым ISC BIND, который
стоит почти везде. Или ты утверждаешь, что BIND начинает
работать как-то по-особому, если у него есть SOA netbsd.org?
>> Да, и этого достаточно, чтобы утверждать, что все твои проблемы
>> с BIND вымышлены.
> Тебе того, что творится у тебя в голове - достаточно для того,
> чтобы что-то утверждать.
> Но реальная жизнь от твоей головы не зависит.
> Проблемы с BIND никуда не денутся от того,
Но и не появятся. Вот и покажи, где вообще с BIND есть какие-то
серьёзные проблемы.
> Почему ты думаешь, что такого не бывает?
Сколько случаев взлома BIND ты видел?
---
<<Сколько ни повторяй: "Халва, халва,"--- во рту сладко не станет.>>
Если потенциальная проблема существует, должна быть возможность
обращения её в реальную. Покажи такую возможность.
> А на примере корневых серверов увидеть вообще ничего нельзя -
> там не тот уровень поддержки.
Не нравятся корневые серверы, приводи отчёты CERT или
аналогичных организаций.
> У простого домашнего пользователя этих специалистов нет.
BIND у меня домашнего является тем же самым ISC BIND, который
стоит почти везде. Или ты утверждаешь, что BIND начинает
работать как-то по-особому, если у него есть SOA netbsd.org?
>> Да, и этого достаточно, чтобы утверждать, что все твои проблемы
>> с BIND вымышлены.
> Тебе того, что творится у тебя в голове - достаточно для того,
> чтобы что-то утверждать.
> Но реальная жизнь от твоей головы не зависит.
> Проблемы с BIND никуда не денутся от того,
Но и не появятся. Вот и покажи, где вообще с BIND есть какие-то
серьёзные проблемы.
> Почему ты думаешь, что такого не бывает?
Сколько случаев взлома BIND ты видел?
---
<<Сколько ни повторяй: "Халва, халва,"--- во рту сладко не станет.>>
Мне лень отвечать на твой бред, но я всё-таки напишу этот пост, чтобы последнее слово осталось за мной.
Q38: а по каким, собственно, правилам, тут ведутся дискуссии?
формальной логикой ведь и не пахнет...
A38: http://golovolomka.hobby.ru/humour/flogic.shtml
---
"Я знаю правду! Все прежние правды --- прочь!"
формальной логикой ведь и не пахнет...
A38: http://golovolomka.hobby.ru/humour/flogic.shtml
---
"Я знаю правду! Все прежние правды --- прочь!"
Ну-ну.
Q38: а по каким, собственно, правилам, тут ведутся дискуссии?не указывать кодировку страницы, расчитывая что юзверя один фиг винда - плохо.
формальной логикой ведь и не пахнет...
A38: http://golovolomka.hobby.ru/humour/flogic.shtml
Оставить комментарий
Ivan8209
Вот только не выставляет третий адрес DNS.Соседний UNIX(TM) --- выставляет.
---
Q21: что такое Win2k?
A21: состема.