The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

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

01.07.2020 22:00

Комитет IETF (Internet Engineering Task Force), занимающийся развитием протоколов и архитектуры интернета, завершил формирование RFC для механизма "DNS Push Notifications" и опубликовал связанную с ним спецификацию под идентификатором RFC 8765. RFC получил статус "Предложенного стандарта", после чего начнётся работа по приданию RFC статуса чернового стандарта (Draft Standard), фактически означающего полную стабилизацию протокола и учёт всех высказанных замечаний.

Механизм "DNS Push Notification" даёт возможность клиенту в асинхронном режиме получать уведомления от DNS-сервера об изменении DNS-записей, без необходимости их периодического опроса. Push-уведомления обрабатываются только с использованием транспорта TCP с защитой канала связи при помощи "TLS over TCP". Авторитативный DNS-сервер может принимать TCP-соединения от клиентов DNS Push Notification, отправляющих запросы на подписку на определённые имена и типы DNS-записей. После приёма запроса на подписку сервер будет сам отправлять клиенту уведомления об изменении указанных записей.

Клиент определяет наличие поддержки DNS Push Notification через отправку обычного DNS-запроса, проверяющего существование SRV-записи "_dns-push-tls._tcp.имя_зоны", которая указывает на DNS-серверы, обслуживающие подписки. Клиент также может подписаться на несуществующую запись, и сервер должен уведомить клиента, если она появится в будущем. Уведомления отправляются только при наличии установленного с сервером TCP-соединения и не рассчитаны на отслеживание 24 часа в день 7 дней в неделю - подписка должна отменяться при неактивности (например, при переходе устройства в ждущий режим) и использоваться только при прямой необходимости в отслеживании изменений в live-режиме. Через установленный для Push-уведомлений TCP-канал также могут отправляться и обычные DNS-запросы.

  1. Главная ссылка к новости (https://www.rfc-editor.org/pip...)
  2. OpenNews: Выпуск nginx 1.13.9 c поддержкой технологии HTTP/2 Server Push
  3. OpenNews: Крупнейшие DNS-сервисы и серверы прекратят поддержку проблемных реализаций DNS
  4. OpenNews: Релиз PowerDNS Recursor 4.2 и инициатива DNS flag day 2020
  5. OpenNews: Выпуск DNS-сервера BIND 9.16.0
  6. OpenNews: Атака NXNSAttack, затрагивающая все DNS-резолверы
Лицензия: CC-BY
Тип: К сведению
Короткая ссылка: https://opennet.ru/53276-dns
Ключевые слова: dns, push
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (71) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 22:11, 01/07/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +9 +/
    Кто-нибудь понимает, для чего это задумано (для каких вариантов использования)?

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

     
     
  • 2.3, Аноним (3), 22:13, 01/07/2020 [^] [^^] [^^^] [ответить]  
  • +6 +/
    > Кто-нибудь понимает, для чего это задумано (для каких вариантов использования)?

    Для service discovery, например. Consul DNS, kube-dns и прочие.

     
     
  • 3.15, Аноним (1), 23:22, 01/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Чет мне кажется, тут было проще сделать свое решение, а не пропихивать что-то в RFC как стандарт.

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

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

     
     
  • 4.17, Аноним (1), 23:45, 01/07/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Похоже, я не верно понял задачу этого нововведения.

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

    P.S. Я почему-то подумал, что kube-DNS - это кеширующий локальный DNS на каждой ноде.

     
     
  • 5.44, koct9i (?), 09:38, 02/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Не обязательно всё вязать к авторитативному. Подписки в каждой зоне могут обслуживать отдельные сервера указанные в SRV записи. А кэширующий DNS аналогично может подписаться на обновления и анонсировать себя как обслуживающего подписки.
     
  • 3.36, zurapa (ok), 09:12, 02/07/2020 [^] [^^] [^^^] [ответить]  
  • –5 +/
    Бородатые хипстеры со смузи уже до написания RFC дотянулись. Всё! П***ц! Дожились!
    Скоро автобусы будем переделывать под кубернетис.
     
     
  • 4.48, anonymous (??), 09:49, 02/07/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    В бомбардировщиках USAF уже есть. В автобусы попозже добавят. K8S это операционная система для кластера. Как только пара десятков устройств начинает совместно работать в общей закрытой сети, уже можно задумываться. В автобусах - маршрут, камеры, валидатор билетов, гейт для связи через сотовые сети, климат и статистика от abs/движка нужна. Всё на атмеге8 не реализуешь.
     
     
  • 5.64, Аноним (64), 17:21, 02/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Я правильно понимаю что матрица ИИ на этом работать будут?
     
  • 3.41, Онаним (?), 09:36, 02/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Им multicast DNS уже не хватает?
     
     
  • 4.52, Аноним (3), 12:13, 02/07/2020 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Зачем сpать трафиком в сеть, если можно не cpать трафиком в сеть?
     
  • 2.6, Ноним (?), 22:49, 01/07/2020 [^] [^^] [^^^] [ответить]  
  • +6 +/
    Это нужно для отслеживания (трекинга, подглядывания, шпионства) за открытыми сайтами/вкладками, т.к. на период открытия вкладки ваш кеширующий сервер будет подписываться на нотификейшены за определенный сайт и отписываться когда вкладка будет закрыта и соотв. нотификейшены больше не нужны будут
     
     
  • 3.8, Аноним (1), 23:04, 01/07/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Для вкладок сайта его владелец может открыть веб сокет с клиента на свой сервер. Идти в обход через DNS смысла нет.
     
     
  • 4.25, Ноним (?), 01:50, 02/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Это не для сайтов, это для владельцев DNS серверов.
     
  • 2.9, Я (??), 23:11, 01/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    чтобы быстрее актуализировались записи dns очевидно..
     
     
  • 3.12, Sw00p aka Jerom (?), 23:20, 01/07/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    отрубите кеширование на клиенте и делов то
     
     
  • 4.26, YetAnotherOnanym (ok), 01:52, 02/07/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Если в роли "клиента" выступает кэширующий DNS-сервер крупного провайдера - _каждый_ запрос от абонента он будет переспрашивать у авторитетного сервера. Вот счастья-то будет DNS-серверам какого-нибудь Гугла.
     
  • 2.35, 1 (??), 09:06, 02/07/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Рекламу пихать - это же очевидно.

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

     
  • 2.49, Ordu (ok), 10:06, 02/07/2020 [^] [^^] [^^^] [ответить]  
  • +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.

     
  • 2.67, xm (ok), 18:31, 02/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    что б истечения TTL не ждать для запроса.
     

  • 1.2, Аноним (-), 22:11, 01/07/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –17 +/
    Давно пора, а то DNS пора здавать в музей в рубрику "говноархитектурка 70х".

    Поднял себе на AWS DoH сервер с блеклистами, очередями и событиями по крону, очень удобно.

     
     
  • 2.10, shadowcaster (?), 23:12, 01/07/2020 [^] [^^] [^^^] [ответить]  
  • +4 +/
    И как мы ходим к DoH? По ip или по DNS имени? :)
     
     
  • 3.14, Аноним (14), 23:22, 01/07/2020 [^] [^^] [^^^] [ответить]  
  • +6 +/
    ходим по незнанию основ и технологий
     
  • 3.24, бублички (?), 01:45, 02/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    конечно же по статической записи в зашифрованном /etc/hosts, который по крону расшифровывается :D
     
  • 2.20, бублички (?), 01:30, 02/07/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > очень удобно.

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

     

  • 1.4, Михрютка (ok), 22:30, 01/07/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +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.

    [ ] <- место для фейспалма

     
     
  • 2.28, . (?), 02:43, 02/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    IETF в очередной раз пробил дно. :-(
    Не увидеть такой косяк могут только йунные поняши как парой постов сверху...
    А ведь дятел (С) то может и залететь в этот мир, разрушив его в хлам.
    А знаете ... и поделом! Больше аду! :-\
     
  • 2.29, bergentroll (ok), 05:35, 02/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    А в чём проблема?
     
     
  • 3.30, Аноним (30), 06:46, 02/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Исчерпаны ресурсов dns-сервера на отслеживание записей, которые никогда на нем не появятся. Причём, можно (и даже эффективнее) атаку проводить не поднимая самому рекурсор, а задалбывая через публичные.
     
     
  • 4.31, bergentroll (ok), 08:39, 02/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Исчерпаны ресурсов 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...

     
     
  • 5.51, Аноним (51), 10:40, 02/07/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Servers may employ various techniques to limit subscriptions to a manageable level

    The best of which is disabling ability to subscribe at all.

     

  • 1.5, онанимуз (?), 22:47, 01/07/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    вангую новое поколение амплификейшон дудос атак.

    > только с использованием транспорта TCP

    ну-ну, посмотрим.

     
     
  • 2.7, Ананимус (?), 22:57, 01/07/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > ну-ну, посмотрим.

    А как ты сделаешь пуш по UDP? oO

     
     
  • 3.19, Аноним (19), 00:10, 02/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Так же как по TCP? В чём вопрос?
     
     
  • 4.33, Онаним (?), 08:42, 02/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    В NAT.
     
     
  • 5.58, Аноним (58), 14:14, 02/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Думаете, UDP NAT — это непосильная задача?
     
     
  • 6.68, Онаним (?), 21:27, 02/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Почему же? Везде сплошь и рядом. Но для потоков и быстрых ответов. Таймауты коротенькие. К моменту вашего пуша минут через эннадцать, если не кипэлайвить, трансляция уже закроется. А если кипэлайвить - то какой смысл?
     
  • 2.27, бублички (?), 02:35, 02/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    на мой взгляд куда-более интересные возможности (пока лишь теоретические) открываются если удастся вдруг выдавать себя за сервер и рассылать обновления каким-нибудь кривым клиентам (скажем в необновляемых прошивках телефонов и домашних рутеров). кроме всякого рода фальсификации с записями (что будут приводить к утечке данных а так-же служить вектором для осуществления атак) не будет лишним упомянуть о возможных и пока ещё лишь теоретических RCE при переполнении буфера в коде клиента
     
     
  • 3.57, RomanCh (ok), 14:13, 02/07/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ещё будет очень интересно посмотреть на дебаг кода, написанного из расчёта что не может быть NXDomain.
    И не важно, пользователь опечатался тут, программист когда что-то фундаментальное захардкодил, или админ, который что-то с этим настраивал. Всё взлетело, подключилось, нигде ни одной ошибки нет, но всё висит! Почему? Потому что вместо server00.local.domain кто-то написал servet00.local.domain, DNS клиент пошёл и подписался на него, и ждёт до бесконечности.

    Enjoy your happy debugging!

     
  • 2.70, brt (ok), 11:45, 03/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    А потом туда ещё и SSL, вот тогда заживём!
     

  • 1.11, rvs2016 (ok), 23:13, 01/07/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    > сервер будет сам отправлять клиенту уведомления
    > об изменении указанных записей

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

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

     
     
  • 2.13, marios (ok), 23:21, 01/07/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Зачем спрашиваешь, если всё ясно написано
     
  • 2.16, Sw00p aka Jerom (?), 23:25, 01/07/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >Или в их изобретении радость в том, что по подписке можно будет получать не сразу всю обногвлённую зону, а только нужные клиенту части зоны? А зачем? И была халва... Вот же расчленители... Ну усовершенствовали бы старый механизм да и всё. А то изобретают новый велосипед типа с нуля...

    Где и когда клиенту нужно "всю обногвлённую зону"?

     
     
  • 3.60, rvs2016 (ok), 15:53, 02/07/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >>Или в их изобретении радость в том, что по подписке можно будет получать не сразу всю обногвлённую зону, а только нужные клиенту части зоны? А зачем? И была халва... Вот же расчленители... Ну усовершенствовали бы старый механизм да и всё. А то изобретают новый велосипед типа с нуля...
    > Где и когда клиенту нужно "всю обногвлённую зону"?

    Какая ещё обногвлённая зона? Я писал про зону обновлённую. Если результат написания получился другим, исправьте его в уме во время чтения автоматически и не заостряйте на этом внимание.

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

     
     
  • 4.63, Sw00p aka Jerom (?), 16:29, 02/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Какая ещё обногвлённая зона? Я писал про зону обновлённую. Если результат написания
    > получился другим, исправьте его в уме во время чтения автоматически и
    > не заостряйте на этом внимание.

    Мой комент вовсе не про синтакситечкую ошибку (не придираюсь), а про то, где и когда клиенту необходима вся зона (и делаее ее обновления), если ему по большей части необходим резолв некоторых записей в которых уже предусмотрен тот самый режим обновления по TTL?  

    > Зона обновлённая клиенту нужна тогда, когда он желает её получить.

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

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

    > Дадут ему эту зону или нет - это уже другой вопрос.

    Вернемся на землю, вопрос был конкретный без условностей, "если бы да кабы".


     
  • 2.18, Михрютка (ok), 23:55, 01/07/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    здравствуйте!

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

     
     
  • 3.21, Аноним (1), 01:34, 02/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Сделай все нужные записи в отдельной зоне 4-го уровня и отдавай ее всем желающим. По сути данный RFC именно это и стандартизирует, только без выделения записей в отдельный домен. Однако, в реальности они все-таки будут в отдельном домене, потому что придется как-то настраивать разрешения на отдачу этих данных, а это проще будет сделать для домена целиком. Да и использоваться это будет для записей в домене namespace.svc.cluster.local.

    Так что на практике нет никакой разницы, между разрешением трасфера зоны всем желающим и данным RFC.

     
     
  • 4.23, Аноним (1), 01:44, 02/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Ну, разве что добавляется возможность подписки на единственную запись типа

    cassandra.namespace.svc.cluster.local.

    вместо всей зоны.

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

     
     
  • 5.54, Sw00p aka Jerom (?), 13:53, 02/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    >Еще, возможно, протокол трансфера зоны не стандартизирован, а тут потребовалось стандартизировать решение.

    Стандартизирован ведь.

     
  • 4.56, Аноним (58), 14:12, 02/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Сделай все нужные записи в отдельной зоне 4-го уровня и отдавай ее всем желающим.

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

    Перекладывать нагрузку с сервера на клиент — неплохое решение, но только при условии, что за ресурсы клиента вы не платите. В противном случае не просто получаем умножение нагрузки пропорционально числу клиентов, но и страдаем от него.

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

    Почему?

     
  • 3.59, rvs2016 (ok), 15:50, 02/07/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > здравствуйте!
    > я решил стать вашим вторичным нейм сервером,
    > присылайте мне плез все обновления вашей зоны.

    Не получится. Требуется ещё моё согласие. А его нет.

     
  • 2.22, бублички (?), 01:41, 02/07/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    твой любимый ноутбук или телефон (здесь - клиент), на запрос opennet.ru получает всю зону .ru или всю зону opennet.ru? или быть может он получает её по частям? каким образом определяется необходимая часть? или быть может всё-таки твой клиент получает в ответ лишь определённую запись из этой зоны? ты тёплое с мягким путаешь. одно дело клиент с его элементарными запросами (A, AAAA, MX, NS, PTR и т.п.), другое дело - сервер с его ролями (master/slave) и уведомлением (slave-серверов) об изменениях в определённых зонах (на master-сервере) и возможностью передачи такой зоны целиком или по частям для обновления
     
     
  • 3.61, rvs2016 (ok), 16:16, 02/07/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > твой любимый ноутбук или телефон (здесь - клиент), на запрос opennet.ru получает
    > всю зону .ru или всю зону opennet.ru? или быть может он
    > получает её по частям? каким образом определяется необходимая часть? или быть
    > может всё-таки твой клиент получает в ответ лишь определённую запись из
    > этой зоны?

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

     
     
  • 4.66, бублички (?), 17:44, 02/07/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> твой любимый ноутбук или телефон (здесь - клиент), на запрос opennet.ru получает
    >> всю зону .ru или всю зону opennet.ru? или быть может он
    >> получает её по частям? каким образом определяется необходимая часть? или быть
    >> может всё-таки твой клиент получает в ответ лишь определённую запись из
    >> этой зоны?
    > Ноутбук или телефон получает только адрес имени в ответ на запрос к
    > серверу имён, указанному любым способом (ручным или автоматическим) в настройках ноутбука
    > или телефона. Это, конечно, не вся зонаЮ а только адрес опеннета.
    > Но у сервера имён, с которого получает простой ответ ноутбук или
    > телефон может храниться и вся зона.

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

     
  • 2.69, Аноним (69), 03:15, 03/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Да вроде ж и раньше первичные сервера умели уведомлять сервера вторичные об обновлениях зон у себя.

    Хочешь весь интернет во вторичные сервера своего домена записать?

    > и я даже руку для таких дел к первичному серверу не прикладывал

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

     
     
  • 3.71, rvs2016 (ok), 16:46, 03/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    >> Да вроде ж и раньше первичные сервера умели уведомлять сервера вторичные об обновлениях зон у себя.
    > Хочешь весь интернет во вторичные сервера своего домена записать?
    >> и я даже руку для таких дел к первичному серверу не прикладывал
    > Прикладывал. Убери из зоны NS-записи вторичных серверов, и вся магия куда-то пропадёт...

    Ну ладно. Прикладывал. :-)
    Но зато только они и получают уведомления. А не весь интернет. :-)

     

  • 1.32, Онаним (?), 08:41, 02/07/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Само по себе это расширение - УЖЕ атака, клиенты могут начать забивать DNS-серверы длинноживущими подключениями. Поэтому вангую, что это расширение будет поддерживаться, как обычно, полутора клаудфлейрами, которым ресурсов деть некуда.
     
  • 1.34, Онаним (?), 08:43, 02/07/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    И вообще, если честно, не понятно, на хрена это вообще нужно.
     
     
  • 2.38, zurapa (ok), 09:25, 02/07/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А нужно это для того, чтобы не планировать, а делать, как девочки - взбрело в голову - сделала, показала жопу, все, кто подписался это увидели тут же из первых рядов.
    Это как соц сеть, только для админов.

    Раньше нужно было заранее планировать изменения, делать их, рассчитывать, чтобы не получилось белого пятна, когда у тебя люди не получают доступ к ресурсу, по причине неверных расчётов, или ошибок, или прыщавых пацанов "за рулём".

    Сейчас будет х**к, х**к и в продакшн.

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

     

  • 1.37, zurapa (ok), 09:21, 02/07/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Тупоголовые уроды!
    Зачем перекладывать нагрузку на авторитативные сервера?
    Это что получается сейчас, я сделал свою доску объявлений, и каждый дружок на ней, чтобы не читать обновления оставляет свой телефончик, чтобы я каждого обзванивал и рассказывал о том, что я придумал сделать? (это иносказательно на пальцах) Какой смысл в этом? Это же явная глупость!
     
     
  • 2.55, Аноним (58), 14:06, 02/07/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Тyпоголовые урoды!

    А вы, с вашей логикой «не нужно мне — не нужно никому», конечно, умный.
    Умнее хлебушка, несомненно.

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

    Идите-ка вы к разработчикам (ядра, например), которые общаются через почтовые рассылки, скажите им, что их способ общения абсурден и не нужен.

     
  • 2.62, rvs2016 (ok), 16:19, 02/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > каждого обзванивал и рассказывал о том, что я придумал сделать? (это
    > иносказательно на пальцах) Какой смысл в этом? Это же явная глупость!

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

     
     
  • 3.72, zurapa (ok), 12:30, 07/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Коню пятую ногу тоже можно пришить. Это опционально и бегать ему мешать не будет. Но зато на ходу от волков сможет отбиваться, и, если одна нога устане, другая может её подменить.... Пошёл RFC для коней писать. Пока не опередили.
     

  • 1.39, Аноним (39), 09:26, 02/07/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Ну в целом то здравая идея, и там в стандарте написано же для чего это, не кто не предлагает делать такое на обычном DNS сервере.


     
     
  • 2.40, Онаним (?), 09:31, 02/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Ну и для чего же, ну вот реально?
    Я два раза Motivation перечитал... нашёл пару невнятных отсылок к ябблу и multicast DNS, но ради чего это всё городить - не объясняется от слова "совсем". Не могу придумать ни одной существующей проблемы, ради которой это уродство стоит внедрять.
     
     
  • 3.42, Онаним (?), 09:38, 02/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Не, я кажется придумал. Поскольку если этот хлам внедрить, любой мало-мальски жирный ботнетный дудосер сможет выбрать не огороженный от этого хлама DNS-сервер навскидку и зафлудить его "подписками". Заодно можно услугу по "защите DNS-серверов от дудос-атак" предлагать за мзду малую. Профит!
     
  • 3.43, Аноним (39), 09:38, 02/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    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.

    Ну тобишь, если у нас есть реально часто меняющиеся данные. Это удобно, много чего экономит, трафик, нервы, время отклика.

     
     
  • 4.45, Онаним (?), 09:44, 02/07/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Окей, посыл понял. А цель?

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

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

     
     
  • 5.50, Аноним (39), 10:29, 02/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    "По-хорошему в пределах своей инфраструктуры можно делать поллинг хоть каждую секунду, нагрузка по сути та же, даже меньше"

    Как то сомнительно это, да не удобно с UPD работать. Там таймеры пускать, ждать пока придет ответ. Гадать что произошло если ответа нет. Опять пускать таймеры посылать запрос, опять гадать.

    С TCP в разы проще, законектился и ждешь. Пускаешь пинг раз в сколькото. Все четко ясно и понятно.

     
     
  • 6.53, Аноним (51), 12:40, 02/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    То же самое. Можешь ждать вечность, сервер отвечать не обязан. Да и коннект может сбросить. Всё это отрабатывать - ну его нафиг. Запрос с таймаутом реализуется куда проще.
     

  • 1.46, Онаним (?), 09:46, 02/07/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    А, чёрт, я самое-то главное проглядел.

    S. Cheshire
    Apple Inc.

    Этим всё неймётся, бонжуров мало.

     
     
  • 2.47, Онаним (?), 09:48, 02/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    По-моему, единственные <beep>, умудрившиеся на мультикаст критичные части клиентских приложений завязать, в итоге у них те же принтеры в распределённых сетях работают через пень-колоду или никак.
     

  • 1.65, Аноним (64), 17:23, 02/07/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Есть браузер без пушей как класса?
     
     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2020 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру