Когда браузеры запрашивают и используют IPv6 записи DNS?
Я рад, что мой новый Linode разместил предложения сервера IPv4 и адрес IPv6 также.
И записи DNS по умолчанию, при использовании Linode в качестве NS, показывают обоим A и AAAA записи
example.com 86400 IN A 203.0.113.4
example.com 86400 IN AAAA 2001:db8::ff00:1111:2222:3333
который хорош, веб-приложения доступны и от v4 и от v6.
Однако я понимаю много ISPs (по крайней мере, где я) еще, не предлагают возможности соединения IPv6.
Таким образом доступ от браузера через IPv6 от такой области выполнит AAAA (v6) запрос успешно. Однако http (s) соединение с помощью этого адрес v6 перестанет работать.
У меня есть причины для беспокойства такой вещи, происходящей с недавними браузерами?
Я должен удалить адреса IPv6 из зоны DNS, чтобы гарантировать IPv4 только доступы?
--
Примечание: это не тот же вопрос как этот, который фокусируется на проблемах разрешения DNS
Проблема, о которой вы спрашиваете, была главной 4-5 лет назад. Вероятно, это задержало принятие IPv6 на пару лет. Никто не хотел идти первым, потому что боялся, что их сайт может показаться нестабильным, и пользователи перейдут на конкурирующие сайты без поддержки IPv6.
Многие компании приложили усилия для решения этой проблемы. Возможно, подход Happy Eyballs, с которым @HekanLindqvist связался, был самым значительным вкладом в решение проблемы.
В 2011 году была достаточная уверенность в том, что проблема была решена, что основные веб-сайты провели скоординированный 24-часовой пробный запуск под названием World IPv6 Day. Координированный пробный запуск был направлен на то, чтобы гарантировать, что все пользователи, у которых все еще есть проблема, не перейдут к ошибочному выводу, что проблема была с одним конкретным сайтом, а не с их собственным подключением.
Результаты были достаточно успешными, что через год основные сайты постоянно включали IPv6 в World IPv6 Launch.
Мы близки к критической точке, когда проблемы, вызванные NAT, станут больше, чем проблемы, вызванные сломанным IPv6. На данный момент и те и другие достаточно малы, что трудно измерить, если мы уже преодолели эту критическую точку.
Моими рекомендациями будет настройка DNS записей двойного стека, как только у вас появится работающее собственное подключение двойного стека. Чем раньше вы начнете, тем дольше вам придется решать любые проблемы. Вы хотите, чтобы он был стабильным к тому времени, когда он станет действительно критически важным.
Не устанавливайте серверы на адреса 6to4 или Teredo, если бы это были ваши единственные варианты получения IPv6 на вашем сервере, я бы порекомендовал переключиться на лучшего провайдера.
Однако я рекомендую настроить ретрансляторы 6to4 и Teredo непосредственно на вашем собственном сервере, если ваш сервер имеет публичный IPv4-адрес. Развертывание этих ретрансляторов обеспечит более надежное соединение с вашим сервером для клиентов, использующих либо 6to4, либо Teredo.
Иногда на вашем сервере все еще будут клиенты с нарушенным IPv6 соединением. Но в течение последних двух лет эти клиенты будут испытывать проблемы с основными сайтами, поэтому вы можете ожидать, что они как-то решат свои проблемы. Они вряд ли увидят проблему только с вашим сайтом.
Тем не менее, вы должны обратить внимание на IPv6-соединение вашего собственного сайта. В случае сбоя IPv6-подключения на вашем сайте, вы можете повлиять на небольшое количество пользователей с работающим IPv6-подключением и браузером с предустановленным IPv6-интерфейсом. Это может привести только к проблемам с вашим сайтом, но все остальное будет работать.
То, что на данный момент IPv6 имеет меньшее количество пользователей, не означает, что его можно безопасно развернуть с меньшим мониторингом, чем IPv4. Если что, я скажу, что вам нужно больше мониторинга для подключения к IPv6, потому что вы скорее всего не заметите никаких проблем
.Чтобы добавить что-то к другому ответу и прокомментировать:
Я понимаю, что многие провайдеры (по крайней мере, там, где я нахожусь) еще не предлагают подключение по IPv6. Таким образом, доступ из браузера через IPv6 из такой зоны будет успешно выполнять запрос AAAA (v6). Однако http(s) соединение, использующее этот v6 адрес, будет неудачным.
Нет, оно (почти) никогда не будет пытаться сделать IPv6 соединение. Система знает, что у нее нет IPv6-соединения. getaddrinfo() не вернет приложению никаких IPv6 адресов. (Причина, по которой она все равно будет делать запросы AAAA, заключается в том, что на сайте может быть запись AAAA, которая действительно работает, например, IP-адрес локального хоста, ::1. )
Это проблема только для исчезающего небольшого процента систем: те, которые неправильно думают, что у них есть IPv6-соединение и они работают в браузере несколько летней давности. Как упоминалось выше, благодаря Всемирному дню IPv6 и Всемирному запуску IPv6, большинство из них уже исправлены, так как при падении Facebook и Google на улицах появляется кровь, а браузеры внедрили Happy Eyeballs, так что неудачное соединение стоит всего пару сотен миллисекунд.
.