Если ccTLD не имеет адресов IPv6 для своих серверов имен, пользователь, работающий только с IPv6, может не иметь возможности разрешить любые имена в этом TLD, даже если эти имена находятся в IPv6-компетентных зонах. Разрешение следует по цепочке от корня, и если одно звено не работает, отказывает все.

DNSSEC обеспечивает криптографическую аутентификацию данных DNS. Как и все в DNS, он следует обычному дереву, начиная с корневой зоны. И снова, если одно звено не работает, выходит из строя вся цепочка. Таким образом, любые имена в ccTLD, которые не поддерживают DNSSEC, будут уязвимы для спуфинга (примечание: в данном случае есть метод обхода цепочки, называемый DLV. Однако он устарел и Поддержка этого ICANN прекратится в 2017 г.)

Я бы подумал об использовании более качественного TLD: -)

Записи AAAA могут быть доставлены как преобразователями IPv4, так и IPv6. Вы можете добавить IPv6-адреса в свой домен, и они будут доставлены. Люди, у которых есть преобразователи только IPv6 (что, я считаю, будет относительно редко), ни в коем случае не смогут разрешить ваш домен.

Стандартным обходным решением для DNSSEC является использование DLV (альтернативная проверка DNSSEC). Это использовалось в течение длительного времени и долгое время было единственным способом проверки ряда TLD. Когда поставщики TLD добавляют поддержку DNSSEC, требование DLV для этих TLD исчезает.

В целом внедрение IPv6 и DNSSEC было очень медленным. Там, где я нахожусь, мне по-прежнему требуется туннель IPv4 для подключения к IPv6.

Скромно прагматичное (но, по общему признанию, менее точное или постоянное) Руководство:

Если вы оказались в указанном выше рассуждении и по какой-либо причине ДОЛЖНЫ продолжить работу с рассматриваемыми TLD ...

(A) Нет поддержки IPv6 для TLD

На момент публикации этого сообщения (январь / 2016) IPv4 еще далеко не устарел, поэтому любое практическое влияние на общую обнаруживаемость должно быть минимальным. Но из-за неточности этого предположения и могут быть случаи, когда использование определенного TLD неизбежно по каким-либо причинам брендинга или массового приобретения / передачи TLD и т. Д. ...

1. Посетите IANA (отдел ICANN) База данных корневой зоны по адресу http://www.iana.org/domains/root/db и найдите официальные технические и административные контактные данные для соответствующей организации-спонсора TLD и свяжитесь с ними, чтобы узнать, будет ли IPv6 поддерживается.

(B) Нет поддержки DNSSEC для TLD

Поскольку распознаватели, поддерживающие DNSSEC, проверяют цифровые подписи перед тем, как запрос может быть обработан, в качестве дополнительных усилий (в отличие от SSL), направленных на предотвращение атак MITM, игнорировать это неразумно . Если ваш ДВУ в настоящее время не поддерживает его ...

1. Временное решение - это реализация альтернативной проверки DNSSEC (DLV), которая в этом случае должна находиться на резолвере или кэширующем сервере, а не на полномочном сервере имен. Но если вы просто размещаете сайт или приложение, вы, скорее всего, не собираетесь делать это на соответствующем разрешающем сервере имен с самого начала, и, как предлагает @ Calle-Dybedahl, этот вариант подходит к концу. ~ 2017. (См. Официальный план прекращения действия здесь: https://singapore52.icann.org/en/schedule/mon-tech/presentation-dlv-decommissioning-09feb15-en.pdf )

Итак, аналогично (A) выше ...

2. Посетите базу данных корневой зоны IANA (подразделение ICANN) по адресу http://www.iana.org/domains/root/db и найдите официальный контакт по техническим и административным вопросам. сведения о соответствующей организации-спонсоре TLD и свяжитесь с ними, чтобы узнать, будет ли / когда поддерживаться DNSSEC.

Если TLD не поддерживает записи AAAA для адресов серверов имен, это не означает, что у вас не может быть записей AAAA для ваших базовых услуг, это просто означает, что люди выиграли невозможно использовать IPv6 для самого протокола DNS для поиска адресов ваших служб.

Это совершенно нормальная конфигурация (см. BCP 91 aka RFC 3901 ), чтобы иметь только IPv4 -только серверы имен, перечисленные в реестре домена, причем эти серверы имен публикуют записи AAAA для записей в вашем домене. На данный момент это ничего не сломает - соединение только IPv6 (без NAT64) в значительной степени непригодно для использования.

Что касается DNSSEC, большинство ccTLD уже поддерживают его, а из тех, у кого не так много планов, или уже находятся в середине реализации, хотя Африка является основной проблемой. Последняя карта ISOC , полученная несколько дней назад, показывает следующее:

Я знаю, что это означает, что я не смогу добавить запись AAAA в домен,

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

но что это означает для доступности / совместимости / видимости с других DNS-серверов с поддержкой IPv6?

Если зона для tld недоступна через ipv6, то преобразователи только для ipv6 не смогут разрешить домен .

Если зона для tld доступна через ipv6, но они не позволяют вам предоставлять связующие записи IPv6, все становится более сложным. Если ваш сервер имен находится в рассматриваемом домене, то для поддержки преобразователей только IPv6 необходима связующая запись IPv6. Если ваш сервер имен находится в другом домене, то связующие записи не нужны для вашего домена (хотя, очевидно, они необходимы для некоторого домена).

Двойные преобразователи стека должны подходить в любом случае. Скорее всего, большинство преобразователей DNS будут поддерживать IPv4 (либо двойной стек, либо только v4) в обозримом будущем.

Я понимаю, что DNSSEC так или иначе важен для аутентификации разрешения DNS, но понятия не имею, влияет ли / как его реализация (или ее отсутствие) на меня как на разработчика приложений, когда дело касается безопасности.

Dnssec должен обеспечивать механизм проверки подлинности получаемых вами записей. Однако

1. подавляющее большинство систем не применяют его в настоящее время.
2. проверка подлинности записей на самом деле не очень помогает для записей A и AAAA. Злоумышленник, который может испортить DNS, также может испортить IP-маршрутизацию.

DNSSEC с DANE - это потенциальная будущая замена или дополнение к существующей системе CA. Текущая система ЦС имеет серьезные недостатки с точки зрения безопасности, поскольку она фактически оставляет вас в безопасности только на уровне худшего ЦС.

Вы не говорите, какие приложения вы разрабатываете. Если это клиентское приложение, которое обращается к серверу, которым вы владеете, вам следует защитить свои соединения с помощью tls с частным CA.

Для веб-приложений общедоступная система CA (как бы дрянная) - действительно единственный вариант. Возможно, вы захотите рассмотреть HKP, который пытается снизить риск неправильной выдачи сертификатов. Наличие работающего DNSSEC / DANE обеспечит лучшую безопасность, но только для горстки клиентов, которые действительно его поддерживают ..

Если вы разрабатываете свой собственный протокол, который позволяет использовать произвольные серверы, вы можете рассмотреть возможность включения эквивалента hkp.

1163365]