Кратко

  • Реестр ENUM Services сообщает, что означают ical-access и ical-sched и с какими URI schemes они работают. Он не является инвентарём телефонных номеров, серверов, пользователей или активных deployments.
  • Даже наблюдаемый NAPTR даёт только typed discovery. CalDAV authorization, iMIP delivery, обработка объекта, ответ участника и outcome подтверждаются другими системами.

Vocabulary стало ложным inventory

У стандартного реестра есть сильная институциональная форма: стабильный URL, утверждённые поля, ссылki на RFC. Поэтому его легко принять за источник operational truth. Скрипт видит две зарегистрированные calendar services и рисует два развёрнутых сервиса.

На самом деле реестр отвечает на вопрос семантики. Если implementer встречает ical-access:https, он понимает назначение URI. Если встречает ical-sched:mailto, он понимает, что это scheduling через Internet mail. Реестр не наблюдает ни одного конкретного номера.

Deployment требует другую population: какие ENUM zones доступны, какие E.164 numbers публикуют NAPTR, когда записи наблюдались, куда они ведут и отвечают ли targets. Registration count и deployment count не имеют автоматического отношения один к одному.

Наблюдаемый NAPTR тоже не завершает инвентаризацию

Допустим, сканер действительно получил запись для номера. Это доказательство публикации в определённый момент через определённый resolver. Запись может оставаться в cache, target может быть удалён, номер может сменить контроллера.

Чтобы назвать service активным, нужен probe соответствующего типа и ограниченная временем методика. Для ical-access это как минимум разрешение URI и взаимодействие с CalDAV. Для ical-sched — существование корректного mail route. Но даже такие probes не должны нарушать privacy или выдавать тест за пользовательскую транзакцию.

Inventory row должен хранить provenance: input number, normalized query, RRset, TTL context, observation time, DNSSEC result, NAPTR fields, rewritten URI и probe policy. Тогда читатель видит, что именно было посчитано.

Два enumservice описывают разные поверхности

RFC 5333 регистрирует ical-access с http и https для доступа к calendar или free/busy resource через CalDAV. ical-sched с mailto предназначен для передачи iTIP scheduling objects через iMIP.

Первая поверхность поддерживает попытку чтения или изменения ресурса при наличии прав. Вторая поддерживает отправку scheduling message. Mailbox не становится CalDAV collection, а HTTPS resource не становится адресом электронной почты.

Если inventory хранит только calendar_endpoint, он не может выбрать корректный probe и может расширить authority. Агент, которому разрешили послать приглашение, не получает тем самым право читать календарь. Type — не украшение; это предел допустимого действия.

Reachability не равна authorization

Сервер ical-access может отвечать по сети, успешно проходить TLS и всё же отклонить principal. CalDAV policy может разрешать только free/busy, скрывать event details, разрешать read и запрещать write.

URI из ENUM не содержит ACL. Она не утверждает текущего owner и не обещает, что resource не перемещён. Поэтому monitoring обязан разделять target resolution, connection, server identity, client authentication, resource, method, authorization result, response и committed change.

Считать endpoint active по TCP connection допустимо только если metric так и называется. Переименовать её в «calendar accessible» — значит приписать сетевому probe решение приложения.

Mail acceptance не равна attendee response

В ветке ical-sched отправитель создаёт iTIP object и передаёт его mail infrastructure. SMTP acceptance подтверждает лишь один handoff. Далее возможны delay, reject, quarantine, forwarding, client filtering и parsing.

Даже доставленное и показанное приглашение оставляет человеку выбор. Acceptance, decline, tentative и no response — application states. Они не находятся в DNS и не выводятся из факта доставки.

Mailbox может быть shared или delegated. Телефонный номер может быть reassigned. Поэтому mapping к адресу не доказывает identity человека, прочитавшего сообщение. Inventory service endpoint не должен превращаться в inventory согласий.

DNSSEC аутентифицирует данные своего слоя

DNS response можно подменить. DNSSEC позволяет validator проверить происхождение и целостность DNS data в рамках trust chain. Для discovery это существенный receipt.

Но secure RRset может вести к offline target. Он не аутентифицирует CalDAV client, не авторизует method, не доказывает control mailbox и не знает participant decision. Это не недостаток DNSSEC; это правильная граница.

Schema должна хранить resolver, validation time, secure/insecure/bogus и данные RRset. Boolean trusted_service, вычисленный из DNSSEC, уничтожает scope доказательства и усложняет incident review.

Public discovery может раскрыть relationship

RFC 5333 предполагает общедоступность ENUM DNS records и отмечает, что URI может показать имя или работодателя. Calendar content может быть закрыт authentication, но связь номера с организацией уже видна.

Opaque URI уменьшает прямую читаемость, однако stable token, domain, query pattern, redirect, TLS name, logs и поздняя login activity допускают correlation. Непрозрачность не исправляет stale mapping после job change или number reassignment.

Lifecycle требует minimization, rotation, revocation и ownership review. Privacy audit должен смотреть не только на ответы CalDAV, но и на graph, созданный public locator.

Order и preference не превращают запись в работающую

NAPTR order и preference направляют selection. Они не являются uptime telemetry. Предпочтённый record может указывать на недоступный target, а менее предпочтённый — на доступный. Выбор остаётся корректным относительно опубликованного RRset.

Нельзя также считать ical-sched fallback для неудачного ical-access. После переключения меняется действие: вместо доступа к ресурсу отправляется сообщение. Outcome и authority уже другие.

Selection receipt сохраняет RRset, время, TTL, order, preference, flags, service, regexp и URI. Operational receipt начинается в target protocol. Report может соединить их, но не должен позволять первому писать результат второго.

Четыре числа вместо одного

Руководителю полезно видеть как минимум четыре независимых показателя. Первый — registry coverage: сколько понятий стандартизовано. Второй — observed publication: сколько NAPTR найдено в объявленной выборке и окне. Третий — typed reachability: сколько targets ответило на безопасный probe. Четвёртый — authorized transaction outcome в явно разрешённых тестах.

Эти знаменатели различаются. Registry coverage не имеет E.164 population. Publication зависит от sampling. Reachability меняется со временем. Authorization зависит от principal и method. Складывать их в один процент значит скрыть методику.

Отдельно учитываются human outcomes для scheduling. Даже идеальная infrastructure не может гарантировать согласие участника. Это не failure системы; это сохранённая человеческая authority.

Evidence chain для честного inventory

Каждая строка начинается с утверждения, а не с объекта. «В момент T resolver R вернул RRset X для query Q». Следом: «validator дал state S». Затем: «по полям NAPTR выбран record N и получена URI U».

Для access добавляются redirect, TLS identity, principal, resource, method, authorization, response и commit. Для sched — iTIP object, message ID, mail handoffs, client processing и participant response. Unknown остаётся unknown.

Такой graph позволяет агрегировать без потери границ. Можно считать registrations, publications или probes, явно называя каждую метрику. И можно удалить stale inference, не переписывая исходные наблюдения.

Текущий инцидент источниками не установлен

Рассмотренные источники определяют protocols, registries и security considerations. Они не доказывают действующий сбой сервиса, утечку конкретного человека, unauthorized CalDAV access, фальшивые приглашения или дефект поставщика. Статья не делает таких заявлений.

Это не мешает исправить аналитику: разделить метрики, сохранить service types, проверять lifecycle и собирать receipts. Архитектурный риск можно уменьшать без вымышленного deployment и вымышленной жертвы.

Источники