ахуенная аналогия. во всех современных начальных курсах аля CCNA/HCNA/etc osi присутствует просто как сноска на одной страничке, где пол страницы занимает изображение с корреляцией уровней dod(tcp/ip)/osi. Так что ее нахуй знать не надо, знать нужно dod, а точнее ее реализацию tcp/ip. А то что инженер знает как раз эту корреляцию между уровнями tcp/ip и osi, вовсе не значит что он знает модель osi. Не заглядывая в гугол можешь назвать пару L3 протоколов OSI?

osi справочная модель и к реальности отношения не имеет, не надо ее осиливать.

It's like they're all still there. You feel it, too, don't you?

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

Нет вождя кроме Рил и Кока генерал её...

ебать мой хуй, неужели это кто-то читает?

Ну хуй знает на счет "не фартануло".

куда ни плюнь, везде ебучие яровые.

я не совсем понял к чему тут локальные сети. а какой контроль даст управление NS`ами, авторитетными за корень (точнее управление делегированием TLD "ru" на корневых NS`ах) понятно из теории работы DNS. Если на пальцах:
vmware.com.
"." - корневая зона.
"com" - TLD (Top Level Domain).
"vmware" - SLD (Second Level Domain).
при использовании FQDN (Full Qualified Domain Name, полное доменное имя) крайняя правая точка опускается, но подразумевается:
C:\Users\kagerro>ping vmware.com
Обмен пакетами с vmware.com [107.154.105.19] с 32 байтами данных:
Ответ от 107.154.105.19: число байт=32 время=243мс TTL=49

C:\Users\kagerro>ping vmware.com.
Обмен пакетами с vmware.com [107.154.105.19] с 32 байтами данных:
Ответ от 107.154.105.19: число байт=32 время=238мс TTL=49

Сервера, авторитетные за корень, делегируют права на хранение TLD другим NS, по скольку TLD являются суб зонами для корня. Сервера, авторитетные за TLD в свою очередь делегируют права на хранение SLD другим серверам (т.к. LSD это суб зоны для TLD).
Что имеем:

это NS, хранящие корневую зону:
C:\Users\kagerro>nslookup -type=ns .
╤хЁтхЁ: google-public-dns-a.google.com
Address: 8.8.8.8

Не заслуживающий доверия ответ:
(root) nameserver = k.root-servers.net
(root) nameserver = j.root-servers.net
(root) nameserver = e.root-servers.net
(root) nameserver = d.root-servers.net
(root) nameserver = l.root-servers.net
(root) nameserver = b.root-servers.net
(root) nameserver = f.root-servers.net
(root) nameserver = a.root-servers.net
(root) nameserver = m.root-servers.net
(root) nameserver = h.root-servers.net
(root) nameserver = i.root-servers.net
(root) nameserver = g.root-servers.net
(root) nameserver = c.root-servers.net

a.root-servers.net internet address = 198.41.0.4
a.root-servers.net AAAA IPv6 address = 2001:503:ba3e::2:30
b.root-servers.net internet address = 192.228.79.201
b.root-servers.net AAAA IPv6 address = 2001:500:84::b
c.root-servers.net internet address = 192.33.4.12
c.root-servers.net AAAA IPv6 address = 2001:500:2::c
d.root-servers.net internet address = 199.7.91.13
d.root-servers.net AAAA IPv6 address = 2001:500:2d::d
e.root-servers.net internet address = 192.203.230.10
e.root-servers.net AAAA IPv6 address = 2001:500:a8::e
g.root-servers.net internet address = 192.112.36.4
g.root-servers.net AAAA IPv6 address = 2001:500:12::d0d
h.root-servers.net internet address = 198.97.190.53

это NS, хранящие "com." TLD:
C:\Users\kagerro>nslookup -type=ns com.
╤хЁтхЁ: google-public-dns-a.google.com
Address: 8.8.8.8

Не заслуживающий доверия ответ:
com nameserver = h.gtld-servers.net
com nameserver = b.gtld-servers.net
com nameserver = f.gtld-servers.net
com nameserver = e.gtld-servers.net
com nameserver = i.gtld-servers.net
com nameserver = m.gtld-servers.net
com nameserver = d.gtld-servers.net
com nameserver = g.gtld-servers.net
com nameserver = a.gtld-servers.net
com nameserver = j.gtld-servers.net
com nameserver = l.gtld-servers.net
com nameserver = c.gtld-servers.net
com nameserver = k.gtld-servers.net

a.gtld-servers.net internet address = 192.5.6.30
a.gtld-servers.net AAAA IPv6 address = 2001:503:a83e::2:30
b.gtld-servers.net internet address = 192.33.14.30
b.gtld-servers.net AAAA IPv6 address = 2001:503:231d::2:30
c.gtld-servers.net internet address = 192.26.92.30
d.gtld-servers.net internet address = 192.31.80.30
e.gtld-servers.net internet address = 192.12.94.30
f.gtld-servers.net internet address = 192.35.51.30
g.gtld-servers.net internet address = 192.42.93.30
h.gtld-servers.net internet address = 192.54.112.30
i.gtld-servers.net internet address = 192.43.172.30
j.gtld-servers.net internet address = 192.48.79.30
k.gtld-servers.net internet address = 192.52.178.30
l.gtld-servers.net internet address = 192.41.162.30
m.gtld-servers.net internet address = 192.55.83.30


это NS, хранящие "vmware" SLD:
C:\Users\kagerro>nslookup -type=ns vmware.com.
╤хЁтхЁ: google-public-dns-a.google.com
Address: 8.8.8.8

Не заслуживающий доверия ответ:
vmware.com nameserver = ns2.p14.dynect.net
vmware.com nameserver = ns3.p14.dynect.net
vmware.com nameserver = ns1.p14.dynect.net
vmware.com nameserver = ns4.p14.dynect.net

ns1.p14.dynect.net internet address = 208.78.70.14
ns2.p14.dynect.net internet address = 204.13.250.14
ns3.p14.dynect.net internet address = 208.78.71.14
ns4.p14.dynect.net internet address = 204.13.251.14


На примере рекурсивного запроса. Скажем, у тебя на машине указан в качестве DNS сервера гугловый DNS. Ты спросил у него, кто такой communities.vmware.com. Он в свою очередь выполняет рекурсивный запрос (маловероятно, конечно, что он будет это делать, но для примера предположим что так и есть):
ты -> 8.8.8.8 "кто такой communities.vmwarecom.?"
8.8.8.8 -> a.root-servers.net "кто такой communities.vmware.com.?"
a.root-servers.net. -> 8.8.8.8 "я хз, но вот у меня есть ответственный за зону com., спроси его:a.gtld-servers.net."
8.8.8.8 -> a.gtld-servers.net. "кто такой communities.vmware.com.?"
a.gtld-servers.net. -> 8.8.8.8 "я хз, но вот у меня есть ответственный за зону vmware.com., спроси его:ns2.p14.dynect.net."
8.8.8.8 -> ns2.p14.dynect.net. "кто такой communities.vmware.com.?"
ns2.p14.dynect.net. -> 8.8.8.8 "95.100.3.51"
8.8.8.8 -> ты "95.100.3.51"

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

По понятной логике, если ты имеешь доступ к делегированию TLD "ru" (чего они, вероятно, хотят добиться), то можешь легко делегировать эту TLD паре своих домашних NS на бинде 9 (лол),
и дальше делегировать все SLD суб ru кому угодно, таким образом контролируя, куда люди попадут. Предположим, сегодня люди идут на rospozor.ru по 213.189.197.47, а завтра по 213.189.197.49 (а там, например, искаженная копия портала), и мало кто заметит что адрес изменился.
Здесь, конечно, опущена такая штука как ssl сертификат, выданный для реального поратала каким-нибудь тафтом, и его злоумышленнику нужно будет подделать (или что-то еще придумать), но это уже совсем другая история.

Пример работы NS и рекурсивного запроса описаны крайне примерно и на пальцах, хочешь конкретики - пились в RFC 1034/1035 или на zytrax.com в разделе bind.

При отсутствии доступа к делегированию TLD, можно, конечно, пытаться травить dns кэш, но это слишком еба и сложно для наших ахуенных политиков. Хм, кстати емнип держатели TLD "ru" все еще не используют DNSSEC.