CloudFlare убирает возможность отключить IPv6, начиная с эккаунтов на бесплатном тарифе, в дальнейшем для всех — blog.cloudflare.comreddit.com
Помимо этого рассказывают об экспериментах с созданием нового типа DNS-запроса, в ответ на который будут возвращаться IP-адреса обоих типов (v4 и v6), вместо отдельных A и AAAA запросов/ответов.

Вот тут значит все на CloudFlare пальцем показывают... Лето/осень 2003 года. Peterhost.ru. Я к apache 1.3.x прилаживаю "патч Котерова", который делает vfork(). Суть в том, что vfork() он не настоящий fork(), но позволяет сделать setgid, setuid и даже всякие setrlimit, чем я и воспользовался. Там конечно есть проблемы с тем, что можно испортить код и запустить его от рута, но это уж очень высокая магия. Короче, приладил я его и он работал на Peterhost.ru до момента пока там был apache 1.3.x и на diphost.ru тоже.

2005 год. Peterhost.ru. Сижу никого не трогаю. Вдруг пишет клиент, что мол у него сайт солидного строительного консалтинга, но иногда секс-игрушки и проституток Москвы и Питера показывает. Ну его мы стандартно покрутили — мол у вас прокся не такая, комп не такой. Но я чую неладное — секс-игрушки на том же сервере у нас. И тут я вдруг ловлю этот баг у себя на компе. Туда-сюда, редко, но повторяется. Походил по другим клиентам — да, тоже иногда вдруг вылезают куски соседних сайтов. Причем там слом мозга — вдруг в середине твоего сайта появляется чужой. В основном конечно куски часто посещаемых сайтов.

Через неделю нахожу, что я из форкнутого по vfork() процесса выхожу по exit(), хотя в мне русским по белому написано — _exit(), иначе там стек сместится и сломаете себе всё.

Второй день (это я в отпуске, ага!) пытаюсь прописать TXT-запись домена на DNS-хостинге (не мой) nic.ru. В ответе запись всегда отсутствует. Дошёл до того, что написал к ним в техподдержку, жду ответа. Для сравнения, прописал то же самое на своём домене на CloudFlare — запись в отклике появилась мгновенно. Давно пора было переводить эту организацию с платного хостинга nic.ru на бесплатный CloudFlare...

Жесть. Пытаюсь (пока Авиабаза лежит) перевести работу с серверами-заглушками на домашнюю машину через CloudFlare. Добавил домены, настроил DNS… И всё. Тишина. Жмёшь в списке сайтов «Continue Setup», оно немного думает и снова оказывается в списке сайтов. Ну, думаю, ждёт, пока DNS обновятся. Оно так и пишет, мол, «Domain Record Scanned». С обеда ждал, периодически тыкаясь. Пока не догадался из Фокса зайти. И сразу всё заработало. По этой кнопке, оказывается, дальнейшая настройка. А в Хроме — не работает…

Удивителен и разнообразен мир этих ваших интернетов. Где-то в начале этой недели мы начали получать претензии от пользователей, что у них перестали быть доступны сайты, которые, казалось бы, ничего не связывает. Единственное общее в их историях — все сайты используют CloudFlare. Типовой ответ при резолве выглядит как

$ host www.joindota.com
www.joindota.com is an alias for www.joindota.com.cdn.cloudflare.net.
www.joindota.com.cdn.cloudflare.net is an alias for cf-ssl8578-protected-www.joindota.com.cdn.cloudflare.net.
cf-ssl8578-protected-www.joindota.com.cdn.cloudflare.net has address 141.101.124.37
cf-ssl8578-protected-www.joindota.com.cdn.cloudflare.net has address 108.162.207.37
cf-ssl8578-protected-www.joindota.com.cdn.cloudflare.net has IPv6 address 2400:cb00:2048:1::6ca2:cf25
cf-ssl8578-protected-www.joindota.com.cdn.cloudflare.net has IPv6 address 2400:cb00:2048:1::8d65:7c25

Таким образом, адрес сайта являет собой CNAME к адресу в CDN CloudFlare. Не вдаваясь в особые подробности методологии поиска пути рекурсивного резолва можно сказать, что каждый отдельный резолв через NS'ы выдавал правильный результат. А вот композиция с рекурсивным резолвом через наши DNS давала либо 5(REFUSED), либо 3(NXDOMAIN).

Обновление unbound с 1.4.19 до 1.4.20 не дало никакого результата. Но при удалении конфигурации unbound начинал нормально разрешать имена. Соответственно, в конце концов я добрался до опции use-caps-for-id, которая по умолчанию выключена, но в нашей конфигурации включена:

use-caps-for-id: <yes or no>
Use 0x20-encoded random bits in the query to foil spoof
attempts. This perturbs the lowercase and uppercase of query
names sent to authority servers and checks if the reply still
has the correct casing. Disabled by default. This feature is
an experimental implementation of draft dns-0x20.

Судя по всему, коллеги из CloudFlare каким-то образом задействовали функционал, который генерирует CameCase ответы при резолве. Естественно, экспериментальный функционал анти-спуфинга в unbound сравнивал маску и запрещал разрешение таких имён. Подробней об этом можно почитать в драфте tools.ietf.org

Ну а я, пожалуй, пойду отключу эту фичу.