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

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

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

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

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

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

Записи 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, игнорировать это неразумно. Если ваш TLD в настоящее время его не поддерживает ...

1. Временный обходной путь - это реализация DNSSEC Lookaside Validation (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.

Я знаю, что это означает, что я не смогу добавить в домен запись 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. Текущая система CA имеет серьезные недостатки с точки зрения безопасности, поскольку она фактически оставляет вас в безопасности только на уровне худшего CA.

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

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

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