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. "DNS Push-уведомления получили статус предложенного стандарта" +9 +/–

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

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

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

3. "DNS Push-уведомления получили статус предложенного стандарта" +6 +/–

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

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

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

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

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

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

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

17. "DNS Push-уведомления получили статус предложенного стандарта" +3 +/–

Сообщение от Аноним (1), 01-Июл-20, 23:45

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

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

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

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

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

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

36. "DNS Push-уведомления получили статус предложенного стандарта" –5 +/–

Сообщение от zurapa (ok), 02-Июл-20, 09:12

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

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

48. "DNS Push-уведомления получили статус предложенного стандарта" +1 +/–

Сообщение от anonymous (??), 02-Июл-20, 09:49

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

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

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

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

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

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

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

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

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

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

52. "DNS Push-уведомления получили статус предложенного стандарта" +5 +/–

Сообщение от Аноним (3), 02-Июл-20, 12:13

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

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

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

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

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

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

8. "DNS Push-уведомления получили статус предложенного стандарта" +1 +/–

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

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

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

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

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

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

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

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

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

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

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

12. "DNS Push-уведомления получили статус предложенного стандарта" +1 +/–

Сообщение от Sw00p aka Jerom (?), 01-Июл-20, 23:20

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

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

26. "DNS Push-уведомления получили статус предложенного стандарта" +1 +/–

Сообщение от YetAnotherOnanym (ok), 02-Июл-20, 01:52

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

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

35. "DNS Push-уведомления получили статус предложенного стандарта" +2 +/–

Сообщение от 1 (??), 02-Июл-20, 09:06

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

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

49. "DNS Push-уведомления получили статус предложенного стандарта" +4 +/–

Сообщение от Ordu (ok), 02-Июл-20, 10:06

Если копнуть 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.

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

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

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

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

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

2. "DNS Push-уведомления получили статус предложенного стандарта" –17 +/–

Сообщение от Аноним (-), 01-Июл-20, 22:11

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

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

10. "DNS Push-уведомления получили статус предложенного стандарта" +4 +/–

Сообщение от shadowcaster (?), 01-Июл-20, 23:12

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

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

14. "DNS Push-уведомления получили статус предложенного стандарта" +7 +/–

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

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

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

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

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

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

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

20. "DNS Push-уведомления получили статус предложенного стандарта" +2 +/–

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

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

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

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

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

>>>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. "DNS Push-уведомления получили статус предложенного стандарта" +/–

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

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

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

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

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

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

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

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

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

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

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

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

Сообщение от 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ообщить модератору

51. "DNS Push-уведомления получили статус предложенного стандарта" +1 +/–

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

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

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

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

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

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

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

7. "DNS Push-уведомления получили статус предложенного стандарта" –1 +/–

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

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

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

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

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

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

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

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

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

В NAT.

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

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

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

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

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

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

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

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

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

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

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

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

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

57. "DNS Push-уведомления получили статус предложенного стандарта" +1 +/–

Сообщение от RomanCh (ok), 02-Июл-20, 14:13

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

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

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

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

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

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

11. "DNS Push-уведомления получили статус предложенного стандарта" –4 +/–

Сообщение от rvs2016 (ok), 01-Июл-20, 23:13

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

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

13. "DNS Push-уведомления получили статус предложенного стандарта" –1 +/–

Сообщение от marios (ok), 01-Июл-20, 23:21

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

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

16. "DNS Push-уведомления получили статус предложенного стандарта" +2 +/–

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

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

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

60. "DNS Push-уведомления получили статус предложенного стандарта" –2 +/–

Сообщение от rvs2016 (ok), 02-Июл-20, 15:53

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

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

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

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

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

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

18. "DNS Push-уведомления получили статус предложенного стандарта" +3 +/–

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

59. "DNS Push-уведомления получили статус предложенного стандарта" –1 +/–

Сообщение от rvs2016 (ok), 02-Июл-20, 15:50

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

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

22. "DNS Push-уведомления получили статус предложенного стандарта" +3 +/–

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

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

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

61. "DNS Push-уведомления получили статус предложенного стандарта" –2 +/–

Сообщение от rvs2016 (ok), 02-Июл-20, 16:16

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

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

66. "DNS Push-уведомления получили статус предложенного стандарта" +1 +/–

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

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

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

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

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

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

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

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

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

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

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

32. "DNS Push-уведомления получили статус предложенного стандарта" +1 +/–

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

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

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

34. "DNS Push-уведомления получили статус предложенного стандарта" +2 +/–

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

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

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

38. "DNS Push-уведомления получили статус предложенного стандарта" +1 +/–

Сообщение от zurapa (ok), 02-Июл-20, 09:25

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

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

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

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

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

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

55. "DNS Push-уведомления получили статус предложенного стандарта" –1 +/–

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

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

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

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

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

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

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

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

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

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

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

39. "DNS Push-уведомления получили статус предложенного стандарта" –1 +/–

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

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

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

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

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

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

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

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

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

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

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

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

Сообщение от Аноним (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.
Ну тобишь, если у нас есть реально часто меняющиеся данные. Это удобно, много чего экономит, трафик, нервы, время отклика.

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

45. "DNS Push-уведомления получили статус предложенного стандарта" +1 +/–

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

46. "DNS Push-уведомления получили статус предложенного стандарта" +3 +/–

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

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

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

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

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

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

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

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

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

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

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

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

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

Партнёры:

Хостинг:

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

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

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


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


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


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


	44. "DNS Push-уведомления получили статус предложенного стандарта"	+/–
	Сообщение от koct9i (?), 02-Июл-20, 09:38
	Не обязательно всё вязать к авторитативному. Подписки в каждой зоне могут обслуживать отдельные сервера указанные в SRV записи. А кэширующий DNS аналогично может подписаться на обновления и анонсировать себя как обслуживающего подписки.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	36. "DNS Push-уведомления получили статус предложенного стандарта"	–5 +/–
	Сообщение от zurapa (ok), 02-Июл-20, 09:12
	Бородатые хипстеры со смузи уже до написания RFC дотянулись. Всё! П***ц! Дожились! Скоро автобусы будем переделывать под кубернетис.
	Ответить \| Правка \| К родителю #3 \| Наверх \| Cообщить модератору


	48. "DNS Push-уведомления получили статус предложенного стандарта"	+1 +/–
	Сообщение от anonymous (??), 02-Июл-20, 09:49
	В бомбардировщиках USAF уже есть. В автобусы попозже добавят. K8S это операционная система для кластера. Как только пара десятков устройств начинает совместно работать в общей закрытой сети, уже можно задумываться. В автобусах - маршрут, камеры, валидатор билетов, гейт для связи через сотовые сети, климат и статистика от abs/движка нужна. Всё на атмеге8 не реализуешь.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	64. "DNS Push-уведомления получили статус предложенного стандарта"	+/–
	Сообщение от Аноним (64), 02-Июл-20, 17:21
	Я правильно понимаю что матрица ИИ на этом работать будут?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	41. "DNS Push-уведомления получили статус предложенного стандарта"	+/–
	Сообщение от Онаним (?), 02-Июл-20, 09:36
	Им multicast DNS уже не хватает?
	Ответить \| Правка \| К родителю #3 \| Наверх \| Cообщить модератору


	52. "DNS Push-уведомления получили статус предложенного стандарта"	+5 +/–
	Сообщение от Аноним (3), 02-Июл-20, 12:13
	Зачем сpать трафиком в сеть, если можно не cpать трафиком в сеть?
	Ответить \| Правка \| Наверх \| Cообщить модератору


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


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


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


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


	12. "DNS Push-уведомления получили статус предложенного стандарта"	+1 +/–
	Сообщение от Sw00p aka Jerom (?), 01-Июл-20, 23:20
	отрубите кеширование на клиенте и делов то
	Ответить \| Правка \| Наверх \| Cообщить модератору


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


	35. "DNS Push-уведомления получили статус предложенного стандарта"	+2 +/–
	Сообщение от 1 (??), 02-Июл-20, 09:06
	Рекламу пихать - это же очевидно. Будет пушить каждую минуту новый IP для агрегатора рекламы.
	Ответить \| Правка \| К родителю #1 \| Наверх \| Cообщить модератору


	49. "DNS Push-уведомления получили статус предложенного стандарта"	+4 +/–
	Сообщение от Ordu (ok), 02-Июл-20, 10:06
	Если копнуть 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.
	Ответить \| Правка \| К родителю #1 \| Наверх \| Cообщить модератору


	67. "DNS Push-уведомления получили статус предложенного стандарта"	+/–
	Сообщение от xm (ok), 02-Июл-20, 18:31
	что б истечения TTL не ждать для запроса.
	Ответить \| Правка \| К родителю #1 \| Наверх \| Cообщить модератору

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


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


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


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


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

4. "DNS Push-уведомления получили статус предложенного стандарта"	+4 +/–
Сообщение от Михрютка (ok), 01-Июл-20, 22:30
>>>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. "DNS Push-уведомления получили статус предложенного стандарта"	+/–
	Сообщение от . (?), 02-Июл-20, 02:43
	IETF в очередной раз пробил дно. :-( Не увидеть такой косяк могут только йунные поняши как парой постов сверху... А ведь дятел (С) то может и залететь в этот мир, разрушив его в хлам. А знаете ... и поделом! Больше аду! :-\
	Ответить \| Правка \| Наверх \| Cообщить модератору


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


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


	31. "DNS Push-уведомления получили статус предложенного стандарта"	+/–
	Сообщение от 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ообщить модератору


	51. "DNS Push-уведомления получили статус предложенного стандарта"	+1 +/–
	Сообщение от Аноним (51), 02-Июл-20, 10:40
	> Servers may employ various techniques to limit subscriptions to a manageable level The best of which is disabling ability to subscribe at all.
	Ответить \| Правка \| Наверх \| Cообщить модератору