Хорошо, допустим у вас на 443 порту открывается ваш https сайт — может даже настоящий нормальный сайт, а не фейк. Но мне кажется, что по паттернам трафика на этот порт можно определить, что это не просто https трафик. Кто как думает?
Я считаю, что типичная работа с массивами и их индексами (>97% случаев) в языках типа Java/Javascript/C# не обладает большим удобством из-за выбора 0, а не 1. В будущем будут создаваться новые высокороуровневые языки программирования. И одним из основных аргументов в пользу 1 будет именно большее удобство изучения программирования с нуля школьниками (студентами), у которых еще нет привычки считать индекс с 0.
Есть еще одна аналогичная холиварная тема — с чего начинать индексацию в массиве с 0 или 1. Вот страница википедии, где можно увидеть ЯП, у которых начинается с 1. И если в С/С++ это естественно из-за адресной арифметки, то в Java/Javascript/C# это было сделано из соображений «похожести» синтаксиса на С++. То есть это просто историческое наследие, а ведь могло бы быть и так:
string[] students = new string[3];
students[1] = "John";
students[2] = "Bob";
students[3] = "Alex";
Console.WriteLine("Third student is " + students[3]);
Многие исследователи считают, что чувство юмора — один из последних рубежей, который необходимо преодолеть искусственному интеллекту, чтобы максимально приблизиться к человеку.
Категорически согласен. Вспомнился один специфический тип шуток — Russian reversal, описание на лурке. Можно погуглить и картинки.
Нужно именно _acme-challenge. В dns админке моего регистратора name.com это работает. Похоже, ваш регистратор не разрешает создавать такие dns записи. Советую попробовать переключить ns сервера на что-нибудь из этого.
Совершенно верное решение! Есть и такая его вариация:
Используем 33 переменных и один проход по массиву.
В первую переменную вычисляем XOR элементов, где первый бит равен 1.
Во вторую переменную вычисляем XOR элементов, где второй бит равен 1.
… и так первые 32 переменные.
А в последнюю 33 переменную — общий XOR всех элементов.
По крайней мере одна из 32 переменных не будет равна общему XOR или нулю — это и есть одно из двух непарных чисел. Второе вычисляется по их общему XOR.
Хм, интересно, с CAA записями раньше не встречался. Но у mail.ru и vk.com их нет. Гугл подсказал, что у Let's Encrypt действительно есть некий черный список, скорее даже, секретный алгоритм определения high-risk доменов. И по запросу они могут наоборот добавить домен в белый список.
Я сделал так: в AWS Route 53 создал DNS zone для _acme-challenge.baur.im. Там сразу отображается 4 NS адреса для входящих запросов. Эти адреса (можно не все) я указал у своего регистратора как NS записи для _acme-challenge.baur.im. Все, теперь можно в этой зоне создать TXT запись в корне (а можно было и сразу).
Добавлю, что при экспериментах с DNS надо учитывать TTL — время кэширования в секундах, иногда надо подождать. Также удобно изучать DNS записи через dig/nslookup/их онлайн эквиваленты — можно явно указывать через какой NS сервер опрашивать.
Вообще, так как достаточно создать TXT запись для фиксированного суб-домена _acme-challenge.baur.im, то вовсе не обязательно давать боту/скрипту токен доступа на все DNS записи. Достаточно создать отдельный DNS zone для _acme-challenge.baur.im — в ней скрипт и будет раз в 3 месяца создавать TXT запись. А в самой админке домена baur.im — добавить эти NS адреса для _acme-challenge.baur.im.
https://gist.github.com/kometchtech/8c1b91ec427b264fbe97
Там есть и другие красивые, запоминающиеся айпишники: 1.2.4.8; 80.80.80.80;
https://gtmetrix.com
https://www.dareboost.com
http://yslow.org
Используем 33 переменных и один проход по массиву.
В первую переменную вычисляем XOR элементов, где первый бит равен 1.
Во вторую переменную вычисляем XOR элементов, где второй бит равен 1.
… и так первые 32 переменные.
А в последнюю 33 переменную — общий XOR всех элементов.
По крайней мере одна из 32 переменных не будет равна общему XOR или нулю — это и есть одно из двух непарных чисел. Второе вычисляется по их общему XOR.
Добавлю, что при экспериментах с DNS надо учитывать TTL — время кэширования в секундах, иногда надо подождать. Также удобно изучать DNS записи через dig/nslookup/их онлайн эквиваленты — можно явно указывать через какой NS сервер опрашивать.