forum.opennet.ru - "DNS Push-уведомления получили статус предложенного стандарта" (73)

"DNS Push-уведомления получили статус предложенного стандарта"

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"DNS Push-уведомления получили статус предложенного стандарта"	+1 +/–
Сообщение от opennews (??), 01-Июл-20, 22:11
Комитет IETF (Internet Engineering Task Force), занимающийся развитием протоколов и архитектуры интернета, завершил формирование RFC для механизма "DNS Push Notifications" и опубликовал связанную с ним спецификацию под идентификатором RFC 8765. RFC получил статус "Предложенного стандарта", после чего начнётся работа по приданию RFC статуса чернового стандарта (Draft Standard), фактически означающего полную стабилизацию протокола и учёт всех высказанных замечаний... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=53276
Ответить \| Правка \| Cообщить модератору

Оглавление

Кто-нибудь понимает, для чего это задумано для каких вариантов использования Я, Аноним (1), 22:11 , 01-Июл-20, (1) +9

Для service discovery, например Consul DNS, kube-dns и прочие , Аноним (3), 22:13 , 01-Июл-20, (3) +6

Чет мне кажется, тут было проще сделать свое решение, а не пропихивать что-то в , Аноним (1), 23:22 , 01-Июл-20, (15)

Похоже, я не верно понял задачу этого нововведения Оно задумано, чтобы клиент мо, Аноним (1), 23:45 , 01-Июл-20, (17) +3

Не обязательно всё вязать к авторитативному Подписки в каждой зоне могут обслуж, koct9i (?), 09:38 , 02-Июл-20, (44)

Бородатые хипстеры со смузи уже до написания RFC дотянулись Всё П ц Дожилис, zurapa (ok), 09:12 , 02-Июл-20, (36) –5

В бомбардировщиках USAF уже есть В автобусы попозже добавят K8S это операционн, anonymous (??), 09:49 , 02-Июл-20, (48) +1

Я правильно понимаю что матрица ИИ на этом работать будут , Аноним (64), 17:21 , 02-Июл-20, (64)

Им multicast DNS уже не хватает , Онаним (?), 09:36 , 02-Июл-20, (41)

Зачем сpать трафиком в сеть, если можно не cpать трафиком в сеть , Аноним (3), 12:13 , 02-Июл-20, (52) +5

Это нужно для отслеживания трекинга, подглядывания, шпионства за открытыми сай, Ноним (?), 22:49 , 01-Июл-20, (6) +6

Для вкладок сайта его владелец может открыть веб сокет с клиента на свой сервер , Аноним (1), 23:04 , 01-Июл-20, (8) +1

Это не для сайтов, это для владельцев DNS серверов , Ноним (?), 01:50 , 02-Июл-20, (25)

чтобы быстрее актуализировались записи dns очевидно , Я (??), 23:11 , 01-Июл-20, (9)

отрубите кеширование на клиенте и делов то, Sw00p aka Jerom (?), 23:20 , 01-Июл-20, (12) +1

Если в роли клиента выступает кэширующий DNS-сервер крупного провайдера - _каж, YetAnotherOnanym (ok), 01:52 , 02-Июл-20, (26) +1

Рекламу пихать - это же очевидно Будет пушить каждую минуту новый IP для агрегат, 1 (??), 09:06 , 02-Июл-20, (35) +2
Если копнуть rfc, то в секции motivation в rfc8765 написано, что цель -- заменит, Ordu (ok), 10:06 , 02-Июл-20, (49) +4
что б истечения TTL не ждать для запроса , xm (ok), 18:31 , 02-Июл-20, (67)

Давно пора, а то DNS пора здавать в музей в рубрику говноархитектурка 70х Подн, Аноним (-), 22:11 , 01-Июл-20, (2) –17

И как мы ходим к DoH По ip или по DNS имени , shadowcaster (?), 23:12 , 01-Июл-20, (10) +4

ходим по незнанию основ и технологий , Аноним (14), 23:22 , 01-Июл-20, (14) +7
конечно же по статической записи в зашифрованном etc hosts, который по крону ра, бублички (?), 01:45 , 02-Июл-20, (24)

быть неучем наверное, бублички (?), 01:30 , 02-Июл-20, (20) +2

further updates to these records, it unsubscribes ага - место для фейспал, Михрютка (ok), 22:30 , 01-Июл-20, (4) +4

IETF в очередной раз пробил дно - Не увидеть такой косяк могут только йунные п, . (?), 02:43 , 02-Июл-20, (28)
А в чём проблема , bergentroll (ok), 05:35 , 02-Июл-20, (29)

Исчерпаны ресурсов dns-сервера на отслеживание записей, которые никогда на нем н, Аноним (30), 06:46 , 02-Июл-20, (30)

Но ведь наверняка в реализациях будет лимит на количество подписок от клиента А, bergentroll (ok), 08:39 , 02-Июл-20, (31)

The best of which is disabling ability to subscribe at all , Аноним (51), 10:40 , 02-Июл-20, (51) +1

вангую новое поколение амплификейшон дудос атак ну-ну, посмотрим , онанимуз (?), 22:47 , 01-Июл-20, (5)

А как ты сделаешь пуш по UDP oO, Ананимус (?), 22:57 , 01-Июл-20, (7) –1

Так же как по TCP В чём вопрос , Аноним (19), 00:10 , 02-Июл-20, (19)

В NAT , Онаним (?), 08:42 , 02-Июл-20, (33)

Думаете, UDP NAT 8212 это непосильная задача , Аноним (58), 14:14 , 02-Июл-20, (58)

Почему же Везде сплошь и рядом Но для потоков и быстрых ответов Таймауты коро, Онаним (?), 21:27 , 02-Июл-20, (68)

на мой взгляд куда-более интересные возможности пока лишь теоретические открыв, бублички (?), 02:35 , 02-Июл-20, (27)

Ещё будет очень интересно посмотреть на дебаг кода, написанного из расчёта что н, RomanCh (ok), 14:13 , 02-Июл-20, (57) +1

А потом туда ещё и SSL, вот тогда заживём , brt (ok), 11:45 , 03-Июл-20, (70)

Да вроде ж и раньше первичные сервера умели уведомлять сервера вторичные об обно, rvs2016 (ok), 23:13 , 01-Июл-20, (11) –4

Зачем спрашиваешь, если всё ясно написано, marios (ok), 23:21 , 01-Июл-20, (13) –1
Где и когда клиенту нужно всю обногвлённую зону , Sw00p aka Jerom (?), 23:25 , 01-Июл-20, (16) +2

Какая ещё обногвлённая зона Я писал про зону обновлённую Если результат написа, rvs2016 (ok), 15:53 , 02-Июл-20, (60) –2

Мой комент вовсе не про синтакситечкую ошибку не придираюсь , а про то, где и к, Sw00p aka Jerom (?), 16:29 , 02-Июл-20, (63)

здравствуйте я решил стать вашим вторичным нейм сервером, присылайте мне плез вс, Михрютка (ok), 23:55 , 01-Июл-20, (18) +3

Сделай все нужные записи в отдельной зоне 4-го уровня и отдавай ее всем желающим, Аноним (1), 01:34 , 02-Июл-20, (21)

Ну, разве что добавляется возможность подписки на единственную запись типаcassan, Аноним (1), 01:44 , 02-Июл-20, (23)

Стандартизирован ведь , Sw00p aka Jerom (?), 13:53 , 02-Июл-20, (54)

Типичный namespace svc cluster local может содержать сотни и тысячи RR, не круто, Аноним (58), 14:12 , 02-Июл-20, (56)

Не получится Требуется ещё моё согласие А его нет , rvs2016 (ok), 15:50 , 02-Июл-20, (59) –1

твой любимый ноутбук или телефон здесь - клиент , на запрос opennet ru получает, бублички (?), 01:41 , 02-Июл-20, (22) +3

Ноутбук или телефон получает только адрес имени в ответ на запрос к серверу имён, rvs2016 (ok), 16:16 , 02-Июл-20, (61) –2

ты до сих пор не нашёл в статье слово клиент этот вот новый предложенный стан, бублички (?), 17:44 , 02-Июл-20, (66) +1

Хочешь весь интернет во вторичные сервера своего домена записать Прикладывал Уб, Аноним (69), 03:15 , 03-Июл-20, (69)

Ну ладно Прикладывал - Но зато только они и получают уведомления А не весь и, rvs2016 (ok), 16:46 , 03-Июл-20, (71)

Само по себе это расширение - УЖЕ атака, клиенты могут начать забивать DNS-серве, Онаним (?), 08:41 , 02-Июл-20, (32) +1
И вообще, если честно, не понятно, на хрена это вообще нужно , Онаним (?), 08:43 , 02-Июл-20, (34) +2

А нужно это для того, чтобы не планировать, а делать, как девочки - взбрело в го, zurapa (ok), 09:25 , 02-Июл-20, (38) +1

Тупоголовые уроды Зачем перекладывать нагрузку на авторитативные сервера Это что, zurapa (ok), 09:21 , 02-Июл-20, (37)

А вы, с вашей логикой 171 не нужно мне 8212 не нужно никому 187 , конечно,, Аноним (58), 14:06 , 02-Июл-20, (55) –1
Ну эти ж настройки - по желанию Обязательства нет Те поинты , которым ты не д, rvs2016 (ok), 16:19 , 02-Июл-20, (62)

Коню пятую ногу тоже можно пришить Это опционально и бегать ему мешать не будет, zurapa (ok), 12:30 , 07-Июл-20, (72)

Ну в целом то здравая идея, и там в стандарте написано же для чего это, не кто н, Аноним (39), 09:26 , 02-Июл-20, (39) –1

Ну и для чего же, ну вот реально Я два раза Motivation перечитал нашёл пару н, Онаним (?), 09:31 , 02-Июл-20, (40)

Не, я кажется придумал Поскольку если этот хлам внедрить, любой мало-мальски жи, Онаним (?), 09:38 , 02-Июл-20, (42)
The Domain Name System DNS was designed to return matching records efficient, Аноним (39), 09:38 , 02-Июл-20, (43)

Окей, посыл понял А цель По-хорошему в пределах своей инфраструктуры можно дела, Онаним (?), 09:44 , 02-Июл-20, (45) +1

По-хорошему в пределах своей инфраструктуры можно делать поллинг хоть каждую се, Аноним (39), 10:29 , 02-Июл-20, (50)

То же самое Можешь ждать вечность, сервер отвечать не обязан Да и коннект може, Аноним (51), 12:40 , 02-Июл-20, (53)

У Apple цель была простая - у них устройства могут роумиться из сети в сеть, при, nuclight (??), 00:15 , 18-Ноя-20, (73)

А, чёрт, я самое-то главное проглядел S CheshireApple Inc Этим всё неймётся, бо, Онаним (?), 09:46 , 02-Июл-20, (46) +3

По-моему, единственные beep , умудрившиеся на мультикаст критичные части клиент, Онаним (?), 09:48 , 02-Июл-20, (47)

Есть браузер без пушей как класса , Аноним (64), 17:23 , 02-Июл-20, (65)

Сообщения [Сортировка по ответам | RSS]

1. Сообщение от Аноним (1), 01-Июл-20, 22:11 +9 +/–

Кто-нибудь понимает, для чего это задумано (для каких вариантов использования)?
Я вообще не представляю себе, как каждый кеширующий DNS, получив запись,  на время TTL будет устанавливать соединение с авторитативным DNS для получения уведомлений по подписке. И так с каждым авторитативным DNS, от которого получена запись на время ее TTL.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #3, #6, #9, #35, #49, #67

2. Сообщение от Аноним (-), 01-Июл-20, 22:11 –17 +/–

Давно пора, а то DNS пора здавать в музей в рубрику "говноархитектурка 70х".
Поднял себе на AWS DoH сервер с блеклистами, очередями и событиями по крону, очень удобно.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #10, #20

3. Сообщение от Аноним (3), 01-Июл-20, 22:13 +6 +/–

> Кто-нибудь понимает, для чего это задумано (для каких вариантов использования)?
Для service discovery, например. Consul DNS, kube-dns и прочие.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #15, #36, #41

4. Сообщение от Михрютка (ok), 01-Июл-20, 22:30 +4 +/–

>>>When the client loses interest in receiving
   further updates to these records, it unsubscribes.
ага
>>>A client may SUBSCRIBE to records that are unknown to the server at    the time of the request (providing that the name falls within one of    the zone(s) the server is responsible for), and this is not an error.
>>>The server MUST NOT return NXDOMAIN in this case.  The server MUST    accept these requests and send Push Notifications if and when    matching records are found in the future.
[ ] <- место для фейспалма

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #28, #29

5. Сообщение от онанимуз (?), 01-Июл-20, 22:47 +/–

вангую новое поколение амплификейшон дудос атак.
> только с использованием транспорта TCP
ну-ну, посмотрим.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #7, #27, #70

6. Сообщение от Ноним (?), 01-Июл-20, 22:49 +6 +/–

Это нужно для отслеживания (трекинга, подглядывания, шпионства) за открытыми сайтами/вкладками, т.к. на период открытия вкладки ваш кеширующий сервер будет подписываться на нотификейшены за определенный сайт и отписываться когда вкладка будет закрыта и соотв. нотификейшены больше не нужны будут

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #8

7. Сообщение от Ананимус (?), 01-Июл-20, 22:57 –1 +/–

> ну-ну, посмотрим.
А как ты сделаешь пуш по UDP? oO

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #19

8. Сообщение от Аноним (1), 01-Июл-20, 23:04 +1 +/–

Для вкладок сайта его владелец может открыть веб сокет с клиента на свой сервер. Идти в обход через DNS смысла нет.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #25

9. Сообщение от Я (??), 01-Июл-20, 23:11 +/–

чтобы быстрее актуализировались записи dns очевидно..

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #12

10. Сообщение от shadowcaster (?), 01-Июл-20, 23:12 +4 +/–

И как мы ходим к DoH? По ip или по DNS имени? :)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #14, #24

11. Сообщение от rvs2016 (ok), 01-Июл-20, 23:13 –4 +/–

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

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #13, #16, #18, #22, #69

12. Сообщение от Sw00p aka Jerom (?), 01-Июл-20, 23:20 +1 +/–

отрубите кеширование на клиенте и делов то

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #26

13. Сообщение от marios (ok), 01-Июл-20, 23:21 –1 +/–

Зачем спрашиваешь, если всё ясно написано

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11

14. Сообщение от Аноним (14), 01-Июл-20, 23:22 +7 +/–

ходим по незнанию основ и технологий

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

15. Сообщение от Аноним (1), 01-Июл-20, 23:22 +/–

Чет мне кажется, тут было проще сделать свое решение, а не пропихивать что-то в RFC как стандарт.
Kube-DNS вполне может держать соединение к kube-API и сбрасывать свой кеш при изменении конфигурации сервиса, прописанного в DNS (о чем его и уведомит Kube API по своему протоколу). В таком случае вносить изменения в протокол сильно проще. Также можно сделать каждый kube-DNS авторитативным в домене кубернейтса и тогда он будет регулярно получать трансфер зоны с мастера со всеми изменениями.
Такое стандартное решение может быть полезно, когда информация об изменениях приходит не из одного источника (kube API), тогда стандартный способ сброса кеша DNS определенно полезен. Ведь по сути предложенный протокол нужен для сброса кеша на клиенте.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #17

16. Сообщение от Sw00p aka Jerom (?), 01-Июл-20, 23:25 +2 +/–

>Или в их изобретении радость в том, что по подписке можно будет получать не сразу всю обногвлённую зону, а только нужные клиенту части зоны? А зачем? И была халва... Вот же расчленители... Ну усовершенствовали бы старый механизм да и всё. А то изобретают новый велосипед типа с нуля...
Где и когда клиенту нужно "всю обногвлённую зону"?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #60

17. Сообщение от Аноним (1), 01-Июл-20, 23:45 +3 +/–

Похоже, я не верно понял задачу этого нововведения.
Оно задумано, чтобы клиент мог подписаться на обновления конкретных записей, т.е. это уменьшенный аналог трансфера зоны на вторичный сервер. Любой клиент в результате становится таким вторичным сервером для конкретных записей. Тут даже кеширующий сервер ни при чем. Это нужно конкретному клиенту-пользователю. Т.е. клиент приходит на авторитативный сервер и подписывается на обновления конкретных записей. Когда они изменяются, клиент на это реагирует. Это никак не связано с кешем DNS, он вообще в этом не участвует. Это такой способ уведомить клиента об изменении конфигурации, например, некоего сервиса, через авторитативный DNS.
P.S. Я почему-то подумал, что kube-DNS - это кеширующий локальный DNS на каждой ноде.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #44

18. Сообщение от Михрютка (ok), 01-Июл-20, 23:55 +3 +/–

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #21, #59

19. Сообщение от Аноним (19), 02-Июл-20, 00:10 +/–

Так же как по TCP? В чём вопрос?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #33

20. Сообщение от бублички (?), 02-Июл-20, 01:30 +2 +/–

> очень удобно.
быть неучем? наверное

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

21. Сообщение от Аноним (1), 02-Июл-20, 01:34 +/–

Сделай все нужные записи в отдельной зоне 4-го уровня и отдавай ее всем желающим. По сути данный RFC именно это и стандартизирует, только без выделения записей в отдельный домен. Однако, в реальности они все-таки будут в отдельном домене, потому что придется как-то настраивать разрешения на отдачу этих данных, а это проще будет сделать для домена целиком. Да и использоваться это будет для записей в домене namespace.svc.cluster.local.
Так что на практике нет никакой разницы, между разрешением трасфера зоны всем желающим и данным RFC.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #23, #56

22. Сообщение от бублички (?), 02-Июл-20, 01:41 +3 +/–

твой любимый ноутбук или телефон (здесь - клиент), на запрос opennet.ru получает всю зону .ru или всю зону opennet.ru? или быть может он получает её по частям? каким образом определяется необходимая часть? или быть может всё-таки твой клиент получает в ответ лишь определённую запись из этой зоны? ты тёплое с мягким путаешь. одно дело клиент с его элементарными запросами (A, AAAA, MX, NS, PTR и т.п.), другое дело - сервер с его ролями (master/slave) и уведомлением (slave-серверов) об изменениях в определённых зонах (на master-сервере) и возможностью передачи такой зоны целиком или по частям для обновления

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #61

23. Сообщение от Аноним (1), 02-Июл-20, 01:44 +/–

Ну, разве что добавляется возможность подписки на единственную запись типа
cassandra.namespace.svc.cluster.local.
вместо всей зоны.
Еще, возможно, протокол трансфера зоны не стандартизирован, а тут потребовалось стандартизировать решение.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #54

24. Сообщение от бублички (?), 02-Июл-20, 01:45 +/–

конечно же по статической записи в зашифрованном /etc/hosts, который по крону расшифровывается :D

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

25. Сообщение от Ноним (?), 02-Июл-20, 01:50 +/–

Это не для сайтов, это для владельцев DNS серверов.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8

26. Сообщение от YetAnotherOnanym (ok), 02-Июл-20, 01:52 +1 +/–

Если в роли "клиента" выступает кэширующий DNS-сервер крупного провайдера - _каждый_ запрос от абонента он будет переспрашивать у авторитетного сервера. Вот счастья-то будет DNS-серверам какого-нибудь Гугла.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

27. Сообщение от бублички (?), 02-Июл-20, 02:35 +/–

на мой взгляд куда-более интересные возможности (пока лишь теоретические) открываются если удастся вдруг выдавать себя за сервер и рассылать обновления каким-нибудь кривым клиентам (скажем в необновляемых прошивках телефонов и домашних рутеров). кроме всякого рода фальсификации с записями (что будут приводить к утечке данных а так-же служить вектором для осуществления атак) не будет лишним упомянуть о возможных и пока ещё лишь теоретических RCE при переполнении буфера в коде клиента

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #57

28. Сообщение от . (?), 02-Июл-20, 02:43 +/–

IETF в очередной раз пробил дно. :-(
Не увидеть такой косяк могут только йунные поняши как парой постов сверху...
А ведь дятел (С) то может и залететь в этот мир, разрушив его в хлам.
А знаете ... и поделом! Больше аду! :-\

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

29. Сообщение от bergentroll (ok), 02-Июл-20, 05:35 +/–

А в чём проблема?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #30

30. Сообщение от Аноним (30), 02-Июл-20, 06:46 +/–

Исчерпаны ресурсов dns-сервера на отслеживание записей, которые никогда на нем не появятся. Причём, можно (и даже эффективнее) атаку проводить не поднимая самому рекурсор, а задалбывая через публичные.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #31

31. Сообщение от bergentroll (ok), 02-Июл-20, 08:39 +/–

> Исчерпаны ресурсов dns-сервера на отслеживание записей, которые никогда на нем не появятся.
> Причём, можно (и даже эффективнее) атаку проводить не поднимая самому рекурсор,
> а задалбывая через публичные.
Но ведь наверняка в реализациях будет лимит на количество подписок от клиента. А может быть и время жизни для таких подписок сделают.
> 4.  State Considerations
> ...After a client establishes a session to a DNS server, each subscription is individually accepted or rejected.  Servers may employ various techniques to limit subscriptions to a manageable level...

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30 Ответы: #51

32. Сообщение от Онаним (?), 02-Июл-20, 08:41 +1 +/–

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

Ответить | Правка | Наверх | Cообщить модератору

33. Сообщение от Онаним (?), 02-Июл-20, 08:42 +/–

В NAT.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #58

34. Сообщение от Онаним (?), 02-Июл-20, 08:43 +2 +/–

И вообще, если честно, не понятно, на хрена это вообще нужно.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #38

35. Сообщение от 1 (??), 02-Июл-20, 09:06 +2 +/–

Рекламу пихать - это же очевидно.
Будет пушить каждую минуту новый IP для агрегатора рекламы.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

36. Сообщение от zurapa (ok), 02-Июл-20, 09:12 –5 +/–

Бородатые хипстеры со смузи уже до написания RFC дотянулись. Всё! П***ц! Дожились!
Скоро автобусы будем переделывать под кубернетис.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #48

37. Сообщение от zurapa (ok), 02-Июл-20, 09:21 +/–

Тупоголовые уроды!
Зачем перекладывать нагрузку на авторитативные сервера?
Это что получается сейчас, я сделал свою доску объявлений, и каждый дружок на ней, чтобы не читать обновления оставляет свой телефончик, чтобы я каждого обзванивал и рассказывал о том, что я придумал сделать? (это иносказательно на пальцах) Какой смысл в этом? Это же явная глупость!

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #55, #62

38. Сообщение от zurapa (ok), 02-Июл-20, 09:25 +1 +/–

А нужно это для того, чтобы не планировать, а делать, как девочки - взбрело в голову - сделала, показала жопу, все, кто подписался это увидели тут же из первых рядов.
Это как соц сеть, только для админов.
Раньше нужно было заранее планировать изменения, делать их, рассчитывать, чтобы не получилось белого пятна, когда у тебя люди не получают доступ к ресурсу, по причине неверных расчётов, или ошибок, или прыщавых пацанов "за рулём".
Сейчас будет х**к, х**к и в продакшн.
Другое дело, если это посчитают общепризнанным стандартом и новой парадигмой работы DNS-серверов, то это жопа полная. Я лично на этот маразм никогда не подпишусь. Буду жить в своём ламповом локальном пространстве.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34

39. Сообщение от Аноним (39), 02-Июл-20, 09:26 –1 +/–

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

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #40

40. Сообщение от Онаним (?), 02-Июл-20, 09:31 +/–

Ну и для чего же, ну вот реально?
Я два раза Motivation перечитал... нашёл пару невнятных отсылок к ябблу и multicast DNS, но ради чего это всё городить - не объясняется от слова "совсем". Не могу придумать ни одной существующей проблемы, ради которой это уродство стоит внедрять.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39 Ответы: #42, #43

41. Сообщение от Онаним (?), 02-Июл-20, 09:36 +/–

Им multicast DNS уже не хватает?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #52

42. Сообщение от Онаним (?), 02-Июл-20, 09:38 +/–

Не, я кажется придумал. Поскольку если этот хлам внедрить, любой мало-мальски жирный ботнетный дудосер сможет выбрать не огороженный от этого хлама DNS-сервер навскидку и зафлудить его "подписками". Заодно можно услугу по "защите DNS-серверов от дудос-атак" предлагать за мзду малую. Профит!

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40

43. Сообщение от Аноним (39), 02-Июл-20, 09:38 +/–

The Domain Name System (DNS) was designed to return matching records
   efficiently for queries for data that are relatively static.  When
   those records change frequently, DNS is still efficient at returning
   the updated results when polled, as long as the polling rate is not
   too high.  But, there exists no mechanism for a client to be
   asynchronously notified when these changes occur.  This document
   defines a mechanism for a client to be notified of such changes to
   DNS records, called DNS Push Notifications.
Ну тобишь, если у нас есть реально часто меняющиеся данные. Это удобно, много чего экономит, трафик, нервы, время отклика.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40 Ответы: #45

44. Сообщение от koct9i (?), 02-Июл-20, 09:38 +/–

Не обязательно всё вязать к авторитативному. Подписки в каждой зоне могут обслуживать отдельные сервера указанные в SRV записи. А кэширующий DNS аналогично может подписаться на обновления и анонсировать себя как обслуживающего подписки.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17

45. Сообщение от Онаним (?), 02-Июл-20, 09:44 +1 +/–

Окей, посыл понял. А цель?
По-хорошему в пределах своей инфраструктуры можно делать поллинг хоть каждую секунду, нагрузка по сути та же, даже меньше - накладные расходы у TCP не так малы.
Каков юзкейс в реальности, где TTL кешей находится в диапазоне нескольких минут?
Кому конкретно не хватает стандартного UDP-поллинга, примеры в студию?
Какие проблемы решает данный посыл, и зачем городить огород, если всё и так прекрасно работает?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43 Ответы: #50, #73

46. Сообщение от Онаним (?), 02-Июл-20, 09:46 +3 +/–

А, чёрт, я самое-то главное проглядел.
S. Cheshire
Apple Inc.
Этим всё неймётся, бонжуров мало.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #47

47. Сообщение от Онаним (?), 02-Июл-20, 09:48 +/–

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46

48. Сообщение от anonymous (??), 02-Июл-20, 09:49 +1 +/–

В бомбардировщиках USAF уже есть. В автобусы попозже добавят. K8S это операционная система для кластера. Как только пара десятков устройств начинает совместно работать в общей закрытой сети, уже можно задумываться. В автобусах - маршрут, камеры, валидатор билетов, гейт для связи через сотовые сети, климат и статистика от abs/движка нужна. Всё на атмеге8 не реализуешь.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36 Ответы: #64

49. Сообщение от Ordu (ok), 02-Июл-20, 10:06 +4 +/–

Если копнуть rfc, то в секции motivation в rfc8765 написано, что цель -- заменить UDP-вариант DNS Push (rfc8764), который использовала Apple, а в rfc8764 написано:
   In dynamic environments, DNS-based Service Discovery [RFC6763]
   benefits significantly from clients being able to learn about changes
   to DNS information via a mechanism that is both more timely and more
   efficient than simple polling.  Such a mechanism enables "live
   browses" that (a) learn when a new instance of a service appears, (b)
   learn when an existing service instance disappears from the network,
   and (c) allows clients to monitor status changes to a service
   instance (e.g., printer ink levels).  Multicast DNS [RFC6762]
   supports this natively.  When a device on the network publishes or
   deletes Multicast DNS records, these changes are multicast to other
   hosts on the network.
   This document defines an Apple extension to unicast DNS that enables
   a client to issue long-lived queries that allow a unicast DNS server
   to notify clients about changes to DNS data.  This is a more scalable
   and practical solution than can be achieved by polling of the name
   server, because a low polling rate could leave the client with stale
   information, while a high polling rate would have an adverse impact
   on the network and server.
Если вкратце, то есть разные способы узнавать о том, что есть в сети, есть даже способы уведомлять клиентов, но у них есть недостатки, типа мультикаста. rfc8764 же их устраняет юникастом.
Но, возвращаясь к первому rfc, у rfc8764 тоже есть недостатки (UDP), и rfc8765 их устраняет, задавая способ делать то же самое через TCP.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

50. Сообщение от Аноним (39), 02-Июл-20, 10:29 +/–

"По-хорошему в пределах своей инфраструктуры можно делать поллинг хоть каждую секунду, нагрузка по сути та же, даже меньше"
Как то сомнительно это, да не удобно с UPD работать. Там таймеры пускать, ждать пока придет ответ. Гадать что произошло если ответа нет. Опять пускать таймеры посылать запрос, опять гадать.
С TCP в разы проще, законектился и ждешь. Пускаешь пинг раз в сколькото. Все четко ясно и понятно.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45 Ответы: #53

51. Сообщение от Аноним (51), 02-Июл-20, 10:40 +1 +/–

> Servers may employ various techniques to limit subscriptions to a manageable level
The best of which is disabling ability to subscribe at all.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31

52. Сообщение от Аноним (3), 02-Июл-20, 12:13 +5 +/–

Зачем сpать трафиком в сеть, если можно не cpать трафиком в сеть?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41

53. Сообщение от Аноним (51), 02-Июл-20, 12:40 +/–

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50

54. Сообщение от Sw00p aka Jerom (?), 02-Июл-20, 13:53 +/–

>Еще, возможно, протокол трансфера зоны не стандартизирован, а тут потребовалось стандартизировать решение.
Стандартизирован ведь.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23

55. Сообщение от Аноним (58), 02-Июл-20, 14:06 –1 +/–

> Тyпоголовые урoды!
А вы, с вашей логикой «не нужно мне — не нужно никому», конечно, умный.
Умнее хлебушка, несомненно.
> Это что получается сейчас, я сделал свою доску объявлений, и каждый дружок на ней, чтобы не читать обновления оставляет свой телефончик, чтобы я каждого обзванивал и рассказывал о том, что я придумал сделать?
Идите-ка вы к разработчикам (ядра, например), которые общаются через почтовые рассылки, скажите им, что их способ общения абсурден и не нужен.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37

56. Сообщение от Аноним (58), 02-Июл-20, 14:12 +/–

> Сделай все нужные записи в отдельной зоне 4-го уровня и отдавай ее всем желающим.
Типичный namespace.svc.cluster.local может содержать сотни и тысячи RR, не круто каждый раз столько по сети гонять.
Ну и реализовывать в клиенте функциональность авторитативного слейва — такое себе. Опять же, ему придётся парсить всю зону ради одной-двух записей.
Перекладывать нагрузку с сервера на клиент — неплохое решение, но только при условии, что за ресурсы клиента вы не платите. В противном случае не просто получаем умножение нагрузки пропорционально числу клиентов, но и страдаем от него.
> Однако, в реальности они все-таки будут в отдельном домене, потому что придется как-то настраивать разрешения на отдачу этих данных, а это проще будет сделать для домена целиком.
Почему?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21

57. Сообщение от RomanCh (ok), 02-Июл-20, 14:13 +1 +/–

Ещё будет очень интересно посмотреть на дебаг кода, написанного из расчёта что не может быть NXDomain.
И не важно, пользователь опечатался тут, программист когда что-то фундаментальное захардкодил, или админ, который что-то с этим настраивал. Всё взлетело, подключилось, нигде ни одной ошибки нет, но всё висит! Почему? Потому что вместо server00.local.domain кто-то написал servet00.local.domain, DNS клиент пошёл и подписался на него, и ждёт до бесконечности.
Enjoy your happy debugging!

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27

58. Сообщение от Аноним (58), 02-Июл-20, 14:14 +/–

Думаете, UDP NAT — это непосильная задача?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33 Ответы: #68

59. Сообщение от rvs2016 (ok), 02-Июл-20, 15:50 –1 +/–

> здравствуйте!
> я решил стать вашим вторичным нейм сервером,
> присылайте мне плез все обновления вашей зоны.
Не получится. Требуется ещё моё согласие. А его нет.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18

60. Сообщение от rvs2016 (ok), 02-Июл-20, 15:53 –2 +/–

>>Или в их изобретении радость в том, что по подписке можно будет получать не сразу всю обногвлённую зону, а только нужные клиенту части зоны? А зачем? И была халва... Вот же расчленители... Ну усовершенствовали бы старый механизм да и всё. А то изобретают новый велосипед типа с нуля...
> Где и когда клиенту нужно "всю обногвлённую зону"?
Какая ещё обногвлённая зона? Я писал про зону обновлённую. Если результат написания получился другим, исправьте его в уме во время чтения автоматически и не заостряйте на этом внимание.
Зона обновлённая клиенту нужна тогда, когда он желает её получить. Дадут ему эту зону или нет - это уже другой вопрос.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #63

61. Сообщение от rvs2016 (ok), 02-Июл-20, 16:16 –2 +/–

> твой любимый ноутбук или телефон (здесь - клиент), на запрос opennet.ru получает
> всю зону .ru или всю зону opennet.ru? или быть может он
> получает её по частям? каким образом определяется необходимая часть? или быть
> может всё-таки твой клиент получает в ответ лишь определённую запись из
> этой зоны?
Ноутбук или телефон получает только адрес имени в ответ на запрос к серверу имён, указанному любым способом (ручным или автоматическим) в настройках ноутбука или телефона. Это, конечно, не вся зонаЮ а только адрес опеннета. Но у сервера имён, с которого получает простой ответ ноутбук или телефон может храниться и вся зона.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #66

62. Сообщение от rvs2016 (ok), 02-Июл-20, 16:19 +/–

> каждого обзванивал и рассказывал о том, что я придумал сделать? (это
> иносказательно на пальцах) Какой смысл в этом? Это же явная глупость!
Ну эти ж настройки - по желанию. Обязательства нет. Те "поинты", которым ты не дозвонишься (из тех кому обновления нужны) - дозвонятся на твою "ноду" сами и выгребут из неё весь новый, поедназначенный для них, "нетмайл" тоже сами. :-)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37 Ответы: #72

63. Сообщение от Sw00p aka Jerom (?), 02-Июл-20, 16:29 +/–

> Какая ещё обногвлённая зона? Я писал про зону обновлённую. Если результат написания
> получился другим, исправьте его в уме во время чтения автоматически и
> не заостряйте на этом внимание.
Мой комент вовсе не про синтакситечкую ошибку (не придираюсь), а про то, где и когда клиенту необходима вся зона (и делаее ее обновления), если ему по большей части необходим резолв некоторых записей в которых уже предусмотрен тот самый режим обновления по TTL?
> Зона обновлённая клиенту нужна тогда, когда он желает её получить.
Не принимаю за ответ, ибо не всегда мы получаем того, чего желаем. По большей части мы можем только добиваться желаемого.
Требует ли рядовой солдат полномочий генерала? - Думаю, нет, а желает ли каждый солдат стать генералом? Думаю, да.
> Дадут ему эту зону или нет - это уже другой вопрос.
Вернемся на землю, вопрос был конкретный без условностей, "если бы да кабы".

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60

64. Сообщение от Аноним (64), 02-Июл-20, 17:21 +/–

Я правильно понимаю что матрица ИИ на этом работать будут?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48

65. Сообщение от Аноним (64), 02-Июл-20, 17:23 +/–

Есть браузер без пушей как класса?

Ответить | Правка | Наверх | Cообщить модератору

66. Сообщение от бублички (?), 02-Июл-20, 17:44 +1 +/–

>> твой любимый ноутбук или телефон (здесь - клиент), на запрос opennet.ru получает
>> всю зону .ru или всю зону opennet.ru? или быть может он
>> получает её по частям? каким образом определяется необходимая часть? или быть
>> может всё-таки твой клиент получает в ответ лишь определённую запись из
>> этой зоны?
> Ноутбук или телефон получает только адрес имени в ответ на запрос к
> серверу имён, указанному любым способом (ручным или автоматическим) в настройках ноутбука
> или телефона. Это, конечно, не вся зонаЮ а только адрес опеннета.
> Но у сервера имён, с которого получает простой ответ ноутбук или
> телефон может храниться и вся зона.
ты до сих пор не нашёл в статье слово "клиент"? этот вот новый предложенный стандарт push-уведомлений разработан для клиентов. понимаешь? поэтому всё что ты там выше написал про веками доступные уведомления об изменениях зон и передачу таковых по частям или целиком - просто не по теме, потому что это доступно лишь для серверов. грубо говоря, master-сервер уведомляет slave-сервер, slave-сервер шлёт запрос и master-сервер отдаёт ему обновлённую зону (AXFR или IXFR). здесь же речь идёт о push-обновлениях конкретных записей со стороны сервера клиенту, а не зон целиком. считать slave-сервер (как и caching resolver или просто forwarder) клиентом - грубая ошибка. клиентом может быть например javascript  работающий в броузере или некая (ещё быть может даже не разработанная) name resolution система на уровне OS, что будет принимать такие push-уведомления. включи мозг и перестань путать сервер с клиентом

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #61

67. Сообщение от xm (ok), 02-Июл-20, 18:31 +/–

что б истечения TTL не ждать для запроса.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

68. Сообщение от Онаним (?), 02-Июл-20, 21:27 +/–

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58

69. Сообщение от Аноним (69), 03-Июл-20, 03:15 +/–

> Да вроде ж и раньше первичные сервера умели уведомлять сервера вторичные об обновлениях зон у себя.
Хочешь весь интернет во вторичные сервера своего домена записать?
> и я даже руку для таких дел к первичному серверу не прикладывал
Прикладывал. Убери из зоны NS-записи вторичных серверов, и вся магия куда-то пропадёт...

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #71

70. Сообщение от brt (ok), 03-Июл-20, 11:45 +/–

А потом туда ещё и SSL, вот тогда заживём!

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

71. Сообщение от rvs2016 (ok), 03-Июл-20, 16:46 +/–

>> Да вроде ж и раньше первичные сервера умели уведомлять сервера вторичные об обновлениях зон у себя.
> Хочешь весь интернет во вторичные сервера своего домена записать?
>> и я даже руку для таких дел к первичному серверу не прикладывал
> Прикладывал. Убери из зоны NS-записи вторичных серверов, и вся магия куда-то пропадёт...
Ну ладно. Прикладывал. :-)
Но зато только они и получают уведомления. А не весь интернет. :-)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #69

72. Сообщение от zurapa (ok), 07-Июл-20, 12:30 +/–

Коню пятую ногу тоже можно пришить. Это опционально и бегать ему мешать не будет. Но зато на ходу от волков сможет отбиваться, и, если одна нога устане, другая может её подменить.... Пошёл RFC для коней писать. Пока не опередили.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #62

73. Сообщение от nuclight (??), 18-Ноя-20, 00:15 +/–

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2025 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. Сообщение от Аноним (1), 01-Июл-20, 22:11	+9 +/–
Кто-нибудь понимает, для чего это задумано (для каких вариантов использования)? Я вообще не представляю себе, как каждый кеширующий DNS, получив запись, на время TTL будет устанавливать соединение с авторитативным DNS для получения уведомлений по подписке. И так с каждым авторитативным DNS, от которого получена запись на время ее TTL.
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #3, #6, #9, #35, #49, #67

2. Сообщение от Аноним (-), 01-Июл-20, 22:11	–17 +/–
Давно пора, а то DNS пора здавать в музей в рубрику "говноархитектурка 70х". Поднял себе на AWS DoH сервер с блеклистами, очередями и событиями по крону, очень удобно.
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #10, #20

3. Сообщение от Аноним (3), 01-Июл-20, 22:13	+6 +/–
> Кто-нибудь понимает, для чего это задумано (для каких вариантов использования)? Для service discovery, например. Consul DNS, kube-dns и прочие.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #1 Ответы: #15, #36, #41

4. Сообщение от Михрютка (ok), 01-Июл-20, 22:30	+4 +/–
>>>When the client loses interest in receiving further updates to these records, it unsubscribes. ага >>>A client may SUBSCRIBE to records that are unknown to the server at the time of the request (providing that the name falls within one of the zone(s) the server is responsible for), and this is not an error. >>>The server MUST NOT return NXDOMAIN in this case. The server MUST accept these requests and send Push Notifications if and when matching records are found in the future. [ ] <- место для фейспалма
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #28, #29

5. Сообщение от онанимуз (?), 01-Июл-20, 22:47	+/–
вангую новое поколение амплификейшон дудос атак. > только с использованием транспорта TCP ну-ну, посмотрим.
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #7, #27, #70

6. Сообщение от Ноним (?), 01-Июл-20, 22:49	+6 +/–
Это нужно для отслеживания (трекинга, подглядывания, шпионства) за открытыми сайтами/вкладками, т.к. на период открытия вкладки ваш кеширующий сервер будет подписываться на нотификейшены за определенный сайт и отписываться когда вкладка будет закрыта и соотв. нотификейшены больше не нужны будут
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #1 Ответы: #8

7. Сообщение от Ананимус (?), 01-Июл-20, 22:57	–1 +/–
> ну-ну, посмотрим. А как ты сделаешь пуш по UDP? oO
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #5 Ответы: #19

8. Сообщение от Аноним (1), 01-Июл-20, 23:04	+1 +/–
Для вкладок сайта его владелец может открыть веб сокет с клиента на свой сервер. Идти в обход через DNS смысла нет.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #6 Ответы: #25

9. Сообщение от Я (??), 01-Июл-20, 23:11	+/–
чтобы быстрее актуализировались записи dns очевидно..
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #1 Ответы: #12

10. Сообщение от shadowcaster (?), 01-Июл-20, 23:12	+4 +/–
И как мы ходим к DoH? По ip или по DNS имени? :)
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #2 Ответы: #14, #24

11. Сообщение от rvs2016 (ok), 01-Июл-20, 23:13	–4 +/–
> сервер будет сам отправлять клиенту уведомления > об изменении указанных записей Да вроде ж и раньше первичные сервера умели уведомлять сервера вторичные об обновлениях зон у себя. У меня они до сих пор именно так и делают и я даже руку для таких дел к первичному серверу не прикладывал - сам умеет без рукоприкладства даже. А они это сейчас, оказывается, изобрели... Ну надо же... 🤔 Или в их изобретении радость в том, что по подписке можно будет получать не сразу всю обногвлённую зону, а только нужные клиенту части зоны? А зачем? И была халва... Вот же расчленители... Ну усовершенствовали бы старый механизм да и всё. А то изобретают новый велосипед типа с нуля...
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #13, #16, #18, #22, #69

12. Сообщение от Sw00p aka Jerom (?), 01-Июл-20, 23:20	+1 +/–
отрубите кеширование на клиенте и делов то
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #9 Ответы: #26

13. Сообщение от marios (ok), 01-Июл-20, 23:21	–1 +/–
Зачем спрашиваешь, если всё ясно написано
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #11

14. Сообщение от Аноним (14), 01-Июл-20, 23:22	+7 +/–
ходим по незнанию основ и технологий
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #10

15. Сообщение от Аноним (1), 01-Июл-20, 23:22	+/–
Чет мне кажется, тут было проще сделать свое решение, а не пропихивать что-то в RFC как стандарт. Kube-DNS вполне может держать соединение к kube-API и сбрасывать свой кеш при изменении конфигурации сервиса, прописанного в DNS (о чем его и уведомит Kube API по своему протоколу). В таком случае вносить изменения в протокол сильно проще. Также можно сделать каждый kube-DNS авторитативным в домене кубернейтса и тогда он будет регулярно получать трансфер зоны с мастера со всеми изменениями. Такое стандартное решение может быть полезно, когда информация об изменениях приходит не из одного источника (kube API), тогда стандартный способ сброса кеша DNS определенно полезен. Ведь по сути предложенный протокол нужен для сброса кеша на клиенте.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #3 Ответы: #17

16. Сообщение от Sw00p aka Jerom (?), 01-Июл-20, 23:25	+2 +/–
>Или в их изобретении радость в том, что по подписке можно будет получать не сразу всю обногвлённую зону, а только нужные клиенту части зоны? А зачем? И была халва... Вот же расчленители... Ну усовершенствовали бы старый механизм да и всё. А то изобретают новый велосипед типа с нуля... Где и когда клиенту нужно "всю обногвлённую зону"?
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #11 Ответы: #60

17. Сообщение от Аноним (1), 01-Июл-20, 23:45	+3 +/–
Похоже, я не верно понял задачу этого нововведения. Оно задумано, чтобы клиент мог подписаться на обновления конкретных записей, т.е. это уменьшенный аналог трансфера зоны на вторичный сервер. Любой клиент в результате становится таким вторичным сервером для конкретных записей. Тут даже кеширующий сервер ни при чем. Это нужно конкретному клиенту-пользователю. Т.е. клиент приходит на авторитативный сервер и подписывается на обновления конкретных записей. Когда они изменяются, клиент на это реагирует. Это никак не связано с кешем DNS, он вообще в этом не участвует. Это такой способ уведомить клиента об изменении конфигурации, например, некоего сервиса, через авторитативный DNS. P.S. Я почему-то подумал, что kube-DNS - это кеширующий локальный DNS на каждой ноде.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #15 Ответы: #44

18. Сообщение от Михрютка (ok), 01-Июл-20, 23:55	+3 +/–
здравствуйте! я решил стать вашим вторичным нейм сервером, присылайте мне плез все обновления вашей зоны.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #11 Ответы: #21, #59

19. Сообщение от Аноним (19), 02-Июл-20, 00:10	+/–
Так же как по TCP? В чём вопрос?
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #7 Ответы: #33

20. Сообщение от бублички (?), 02-Июл-20, 01:30	+2 +/–
> очень удобно. быть неучем? наверное
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #2

21. Сообщение от Аноним (1), 02-Июл-20, 01:34	+/–
Сделай все нужные записи в отдельной зоне 4-го уровня и отдавай ее всем желающим. По сути данный RFC именно это и стандартизирует, только без выделения записей в отдельный домен. Однако, в реальности они все-таки будут в отдельном домене, потому что придется как-то настраивать разрешения на отдачу этих данных, а это проще будет сделать для домена целиком. Да и использоваться это будет для записей в домене namespace.svc.cluster.local. Так что на практике нет никакой разницы, между разрешением трасфера зоны всем желающим и данным RFC.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #18 Ответы: #23, #56

22. Сообщение от бублички (?), 02-Июл-20, 01:41	+3 +/–
твой любимый ноутбук или телефон (здесь - клиент), на запрос opennet.ru получает всю зону .ru или всю зону opennet.ru? или быть может он получает её по частям? каким образом определяется необходимая часть? или быть может всё-таки твой клиент получает в ответ лишь определённую запись из этой зоны? ты тёплое с мягким путаешь. одно дело клиент с его элементарными запросами (A, AAAA, MX, NS, PTR и т.п.), другое дело - сервер с его ролями (master/slave) и уведомлением (slave-серверов) об изменениях в определённых зонах (на master-сервере) и возможностью передачи такой зоны целиком или по частям для обновления
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #11 Ответы: #61

23. Сообщение от Аноним (1), 02-Июл-20, 01:44	+/–
Ну, разве что добавляется возможность подписки на единственную запись типа cassandra.namespace.svc.cluster.local. вместо всей зоны. Еще, возможно, протокол трансфера зоны не стандартизирован, а тут потребовалось стандартизировать решение.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #21 Ответы: #54

24. Сообщение от бублички (?), 02-Июл-20, 01:45	+/–
конечно же по статической записи в зашифрованном /etc/hosts, который по крону расшифровывается :D
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #10

25. Сообщение от Ноним (?), 02-Июл-20, 01:50	+/–
Это не для сайтов, это для владельцев DNS серверов.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #8

26. Сообщение от YetAnotherOnanym (ok), 02-Июл-20, 01:52	+1 +/–
Если в роли "клиента" выступает кэширующий DNS-сервер крупного провайдера - _каждый_ запрос от абонента он будет переспрашивать у авторитетного сервера. Вот счастья-то будет DNS-серверам какого-нибудь Гугла.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #12

27. Сообщение от бублички (?), 02-Июл-20, 02:35	+/–
на мой взгляд куда-более интересные возможности (пока лишь теоретические) открываются если удастся вдруг выдавать себя за сервер и рассылать обновления каким-нибудь кривым клиентам (скажем в необновляемых прошивках телефонов и домашних рутеров). кроме всякого рода фальсификации с записями (что будут приводить к утечке данных а так-же служить вектором для осуществления атак) не будет лишним упомянуть о возможных и пока ещё лишь теоретических RCE при переполнении буфера в коде клиента
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #5 Ответы: #57

28. Сообщение от . (?), 02-Июл-20, 02:43	+/–
IETF в очередной раз пробил дно. :-( Не увидеть такой косяк могут только йунные поняши как парой постов сверху... А ведь дятел (С) то может и залететь в этот мир, разрушив его в хлам. А знаете ... и поделом! Больше аду! :-\
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #4

29. Сообщение от bergentroll (ok), 02-Июл-20, 05:35	+/–
А в чём проблема?
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #4 Ответы: #30

30. Сообщение от Аноним (30), 02-Июл-20, 06:46	+/–
Исчерпаны ресурсов dns-сервера на отслеживание записей, которые никогда на нем не появятся. Причём, можно (и даже эффективнее) атаку проводить не поднимая самому рекурсор, а задалбывая через публичные.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #29 Ответы: #31