предлага алтернативи на термините „whitelist/blacklist“ и „master/slave“, предпочитащи се за употреба в спецификациите — вместо „master/slave“ се препоръчва да се използват „primary/secondary“, „leader/follower“, формиране на RFC за механизма „DNS Push Notifications“ и публикуване на свързаната спецификация под идентификатор . 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 дни в седмицата — абонаментът трябва да бъде отменян при неактивност (например, при преминаване на устройството в режим на изчакване) и да се използва само при пряка необходимост от следене на промени в реално време. Чрез установения TCP канал за Push уведомления също могат да се изпращат и обикновени DNS запитвания.
Източник: opennet.ru
