Всем занимаются рабочие процессы. У мастера только одна функция: обеспечивать отказоустойчивость, т.е. перезагружать конфигурацию без потери соединений и восстанавливать рабочие процессы, если с ними что-то не так. Мастер процесс максимально упрощен и не умеет обслуживать соединения, у него даже полноценного цикла событий нет.
Доступ к сокету соответственно должен быть у пользователя от которого запускаются рабочие процессы.
MTU минус IP/TCP/TLS/HTTP заголовки, т.к. там в сумме набегает ~500B.
Открыл `google.com` - он мне выдал заголовков на 1,4 КБ, не даром же сжатие для них начали делать в HTTP/2. У некоторых на сайтах только одних кук на несколько килобайт набирается, какие уж там 500 байт...
каждый ресурс сжимается независимо от другого, а агрегация происходит на уровне стрима, так что если ваш ресурс меньше 1KB вы просто потратите процессорное время, а данные будут пересылаться так же как и без сжатия.
Не очень понял мысль этого заявления. Предположим, что у нас в пакет помещается с учетом всех оберток около 1200 байт ответов. Если каждый ответ по 1Кб в несжатом виде и около 600 Байт в сжатом, то при запросе двух ресурсов - оба они могут поместиться в 1 пакет в сжатом виде или в 2 пакета в несжатом. Поэтому всё же нет, не так же.
Подгонять min_length строго под размер MTU - не имеет смысла, т.к. ответ состоит не только из самих сжимаемых данных, но и служебных данных от разного рода протокольных оберток, как тех же HTTP-заголовков, фрейминга, чанков и TLS-записей. В случае с HTTP/2 - все ещё гораздо сложнее, т.к. в один пакет могут паковаться данные сразу от нескольких ответов на разные запросы, а потому там в принципе чем меньше ответы - тем лучше, тем больше их поместится разом.
Скорости компрессии и декомпрессии сильно зависят от вычислительных мощностей на сервере и клиенте, а скорость передачи от пропускной способности канала. Тут нет универсальных решений.
А если каждый порт - в отдельную docker-сеть? (этот случай - это уже что-то сложное, я не ожидаю что вы это поддерживаете, но интересно).
Такое скорее всего сейчас не получится настроить. Но я завтра уточню у автора функциональности.
Как в конфиге управлять роутингом на разные порты сервиса? location /abc/ на порт 8080, а location /xxx/ на порт 9090 - так можно?
Вот в примере выше адреса добавятся в разные группы upstream с названиями: web и mqtt, причем даже разных модулей - http и stream. Можно добавить в разные upstream-группы в http, а там уже должны на них смотреть разные location.
А можно задавать конфигурацию сервисов не через labels, а через конфиг? hot reload поддерживается же, так что можно конфиг подсовывать наживую.
Не совсем понял, что имеется в виду, можно чуть подробнее с примером?
Потому, что Docker API работает по HTTP-протоколу. И чтобы прочитать какой-то ответ из сокета - туда сперва нужно записать запрос. Но даже если бы было иначе, то в Linux просто даже для подключения к Unix-сокету уже нужны права на write.
В директиву - нет. Но авторизация поддерживается уже сейчас. Через настройки блока client {} можно добавить какие угодно заголовки авторизации к запросу или даже клиентский сертификат, пользуясь обычными директивами модуля http proxy.
Самым нормальным способом была бы возможность в самом докере создавать дополнительные unix-сокеты с перенастроенным ограниченным доступом к API.
Такие сообщения регулярно в телеграм чате поддержки и комментариях в разных местах. Там просто не о чем писать: "поставили Angie, добавили пару директив, все работает автоматически, спасибо большое" - в таком духе. Пример: https://t.me/angie_support/7987 Если вдруг не работает, то обращаются за помощью и помогаем разобраться почему не работает.
Как поддержку добавили, я сам у себя на сервере удалил Certbot, добавил пару директив и работает с тех пор. Какой плюс? Избавился от лишнего компонента, которым забываешь как пользоваться через несколько месяцев и приходится вспоминать, когда нужно очередной домен завести. В конфиге веб-сервера его так или иначе нужно прописывать и теперь для этого достаточно просто добавить домен в server_name, сделать релоад конфига и всё. Не знаю как из этого выжать целую статью.
А тут коллега детально описал самый комплексный случай настройки, который только можно придумать, разобрался с OctoDNS и другими инструментами, которыми может кто-то захотеть воспользоваться, всё протестировал, написал скрипт и AFAIK никаких промптов. Людям теперь везде ИИ мерещатся. =)
зашёл узнать, насколько удобнее angie, чем связка nginx+dehydrated именно для получения сертификатов с http-авторизацией (т.е., условно говоря, я добавляю новый server {}, а сертификаты для него получаю автоматически).
А чем в таком случае не устроила официальная документация?
Традиционный путь - это держать где-то список доменов, и иногда перестраивать конфиги вебсервера из списк и запрашивать сертификаты. Но мне кажеся, это каким-то сложным, кривым путем. Вроде бы Caddy умеет так делать. Про Angie не знаю, я вот о нем только услышал.
Вам в любом случае придется хранить список доменов и проверять по нему, прежде чем выпустить сертификат. Попробую объяснить почему.
Представим, что такого списка нигде нет. В SNI, как и в заголовке Host, клиент может указать вообще всё, что угодно, абсолютно любой домен. Таким образом злоумышленник сможет вывести ваш сервер из строя, начав запрашивать произвольные домены. Попытка выпустить сертификат на такой произвольный домен не увенчается успехом, однако вы попадете в черный список у ACME-сервера и не сможете получить сертификат для реального нужного домена.
Ок, вы скажите, что ACME клиент должен перед тем, как идти получать сертификат на новый домен - сам попытаться его отрезолвить. А я отвечу, что ничего не мешает злоумышленнику зарегистрировать какой-то домен и прописать для него IP-адрес вашего сервера. И ваш сервер даже получит на него сертификат, но при определенном количестве таких запросов у того же Let's Encrypt сработает лимит и получение новых сертификатов на какое-то время будет далее невозможно, что опять приведет к DoS.
Т.е. так или иначе, перед тем, как идти получать сертификат на какой-то домен с которым пришел клиент - неплохо бы проверить его по списку.
Те, кто использует Caddy таким образом в проде, сильно рискуют, если они не поставили перед ним ещё какой-то прокси, который умеет фильтровать TLS-подключения по SNI и таким образом фильтруют их по списку, либо используют механизм проверки домена внешним запросом к хранилищу, который предоставляет Caddy. Т.е. так или иначе, список доменов где-то есть и по нему происходит сверка.
Потенциально такой режим можно добавить и в Angie с соответствующими предупреждениями и инструкциями, как это безопасно настроить. Но какая-то проверка по списку доменов все равно будет, просто этот список будет храниться вне конфигурации сервера.
Еще, почему-то веб-сервера не умеют сами подбирать сертификаты. Мне кажется немного тупостью, что нужно для каждого виртхоста прописывать, где ему искать файлы с сертификатом и ключам - лишние хлопоты, громоздкий конфиг, лишние ошибки.
Абсолютно с вами согласен. Поэтому в свое время в NGINX Unit я реализовал это иначе. Там сертификат и ключ автоматически выбирается по SNI исходя из тех доменов, что прописаны в сертификате.
nginx и многие сервера появились задолго до того, как появился SNI, отсюда и такая настройка. Можно подумать над тем, как это переделать в Angie, чтобы было проще и удобнее чем механизм, унаследованный от nginx, но это уже отдельная задача.
рановато заявлять о плюсе который ещё не в проде..
Тут я скорее о том, что в принципе технически нормально не реализовать в случае отдельной утилиты, т.к. требует вмешательства в сам процесс TLS-хендшейка.
ну nginx/angie это всё же не для пользователей а для тех кто делает этим пользователям сервисы.
Мы пользователями привыкли называть тех, кто пользуется нашим ПО, т.е. устанавливает и занимается его настройкой. =)
пользователям свойственно ошибаться, если вы утверждаете что так лучше для пользователя то снова вопрос: "чем?"
Они по этой причине уходят на кадди, и не ощущают, что ошиблись. Опять же, кому не нужно и кто считает это ошибкой - может просто не пользоваться данным модулем и вообще его не собирать. Тем не менее, отставание от конкурентов в этом плане приводит только к потере пользователей. Кажется, это весомый аргумент, чтобы не отставать, если хочешь разрабатывать действительно популярное решение, а не что-то сугубо нишевое.
не вижу почему бы из коробки у меня бы не заработал lego/certbot/acme.sh/etc. меньше сил это когда ты добавляешь в свой ansible/puppet/etc проект ещё один хост с его варсами и запускаешь сто раз проверенный плейбук
Значит у вас уже есть какой-то плейбук, вы в этом однажды разобрались и его написали. Это не из коробки. Это не поставил apt install angie, а дальше добавил две директивы и всё работает, причем добавил в парадигме конфигурационного файла, который и так нужно изучать, чтобы пользоваться nginx/Angie.
потому что она провереная временем, эта догма строится на базе того что человек не всесилен и ему свойственно допускать ошибки, и на том как уменьшить возможное кол-во ошибок не более.
Да, и ошибки он допускает при настройке двух разных инструментов. Тратит время на изучение дополнительного инструмента, написание плейбука и пр. пр. Зачем этим заниматься, если можно воспользоваться встроенным решением, которое уже раз разработали те, кто разобрались в вопросе глубже, чем просто настройка Certbot и реализовали это автоматически.
Тут нужно понимать, что в статье рассмотрен довольно комплексный и сложный случай настройки. В простейшем виде вся настройка заключается в добавлении пары директив в конфиг из документации:
acme_client example https://acme-v02.api.letsencrypt.org/directory;
server {
acme example;
...
При этом обновление сертификатов происходит без перезагрузки процессов веб-сервера. Для тех, у кого доменов и сертификатов очень много, необходимость чаще перезапускать процессы - становится отдельной проблемой.
Вот вы спорите, а мы регулярно получаем благодарность от пользователей, которые пишут, что поддержка ACME в Angie - это стало для них одним из ключевых факторов, чтобы перейти с nginx и они очень довольны, благодарят за эту функциональность чаще, чем за многую другую.
Это же не вот вдруг нам заняться было нечем. Это был нескончаемый поток просьб встроить поддержку ACME в веб-сервер, т.к. по той или иной причине пользователи не хотят возиться с отдельным Certbot/Acme.sh и др., предпочитая вместо этого даже сменить веб-сервер на такой, где поддержка ACME уже встроена. Можно конечно сидеть и заявлять, что такие пользователи ошибаются, не должен этим заниматься веб-сервер, но это странный способ кому-то что-то доказать, весьма не конструктивный в плане развития и популяризации проекта.
В конце статьи есть ответ на вопрос чем лучше. Самое банальное - не нужно поддерживать список доменов в двух разных местах. Из небанального, что никогда в принципе не сможет скрипт на bash делать, так это выполнять ALPN-челендж, поддержку которого уже в ближайших версиях добавим.
люди забыли принцип "утилита должна выполнять только одну задачу, но делать это хорошо"
Сколько я работаю в индустрии, то постоянно сталкиваюсь, что реальные пользователи чаще всего хотят обратного, а именно, чтобы всё работало из коробки и желательно тратить на это как можно меньше сил. И в целом, в этом нет ничего плохого... есть в индустрии другие задачи, чем как сопряжение отдельных разрозненных компонентов между собой каждый раз.
Так для чего повторять когда-то десятилетия назад выдвинутую догму, когда задачи и масштабы были совсем другие, снова и снова? Тем более, что тут возникает коллизия в том, а что есть утилита в части веб-сервера... должен ли он хорошо обрабатывать HTTPS трафик? Современному веб-серверу без этого никуда, а если да, то входит ли в эту задачу работа с сертификатами? Ведь если он не сможет обновлять сертификаты, то хорошо обрабатывать HTTPS трафик тоже не получится. Какая-то неполноценная утилита тогда выходит, не справляющаяся со свой задачей.
Форк создан большинством бывших разработчиков nginx. Среди них Хомутов, Ермилов, Бартенев.
Сысоев не занимается разработкой nginx примерно с 2012 года. Не знаю, с кем вы там знакомы, но мы вместе с ним работали над NGINX Unit вплоть до его увольнения из F5. =)
Мы отслеживаем найденные уязвимости в nginx и других форках, оперативно выпускаем исправления, иногда даже раньше, чем это делают сам nginx. Прецедентов нахождения уязвимостей в функциональности самого Angie ещё не было.
Кроме того, у нас есть ряд улучшений, направленных на дополнительное повышение безопасности и защиты от DoS-атак, в том числе портированных из freenginx.
Ещё было бы круто где-то найти полный список отличий в конфигах nginx/angie, чтобы можно было выполнять проверки конфигураций на предмет небезопасных настроек.
Вы можете взять конфиг от nginx и запустить с ним Angie - будет работать также. Rutube, например, так и делает, им так удобнее. У нас же есть руководство по миграции.
Если вы не используете новую функциональность, которая была добавлена только в Angie, то отличий в директивах конфигурации нет за одним незначительным исключением.
Список фич есть на странице документации: https://angie.software/angie/docs/#index-features-oss - если преобразовать это в табличку, то будет просто более громоздко. Или требуется какой-то более расширенный список?
Протокол QUIC реализован не в ядре.
Через labels домен прикрутить сейчас нельзя.
Всем занимаются рабочие процессы. У мастера только одна функция: обеспечивать отказоустойчивость, т.е. перезагружать конфигурацию без потери соединений и восстанавливать рабочие процессы, если с ними что-то не так. Мастер процесс максимально упрощен и не умеет обслуживать соединения, у него даже полноценного цикла событий нет.
Доступ к сокету соответственно должен быть у пользователя от которого запускаются рабочие процессы.
Добавлю ещё, что мониторинга состояния кэша в open source версии nginx тоже никакого нет.
Открыл `google.com` - он мне выдал заголовков на 1,4 КБ, не даром же сжатие для них начали делать в HTTP/2. У некоторых на сайтах только одних кук на несколько килобайт набирается, какие уж там 500 байт...
Не очень понял мысль этого заявления. Предположим, что у нас в пакет помещается с учетом всех оберток около 1200 байт ответов. Если каждый ответ по 1Кб в несжатом виде и около 600 Байт в сжатом, то при запросе двух ресурсов - оба они могут поместиться в 1 пакет в сжатом виде или в 2 пакета в несжатом. Поэтому всё же нет, не так же.
Подгонять min_length строго под размер MTU - не имеет смысла, т.к. ответ состоит не только из самих сжимаемых данных, но и служебных данных от разного рода протокольных оберток, как тех же HTTP-заголовков, фрейминга, чанков и TLS-записей. В случае с HTTP/2 - все ещё гораздо сложнее, т.к. в один пакет могут паковаться данные сразу от нескольких ответов на разные запросы, а потому там в принципе чем меньше ответы - тем лучше, тем больше их поместится разом.
Скорости компрессии и декомпрессии сильно зависят от вычислительных мощностей на сервере и клиенте, а скорость передачи от пропускной способности канала. Тут нет универсальных решений.
Правильно ли я понял, что это как если бы в блоке upstream в директивах server вместо IP-адреса можно было бы имена контейнеров указать?
Да, вот выше в новости, как раз, предпоследним пунктом в списке изменений.
Да
Ок. Добавим.
GET /version
GET /vX.Y/containers/json"
GET /vX.Y/containers/ID/json"
GET /vX.Y/events?filters=...
Подписываемся на события.
В текущей версии не поддерживается. Добавим ли поддержку позже - да, возможно.
Добавить метки с портами, которые будут добавляться в разные usptream-группы.
Пример:
- "angie.http.upstreams.web.port=80"- "angie.stream.upstreams.mqtt.port=1883"Такое скорее всего сейчас не получится настроить. Но я завтра уточню у автора функциональности.
Вот в примере выше адреса добавятся в разные группы upstream с названиями: web и mqtt, причем даже разных модулей - http и stream. Можно добавить в разные upstream-группы в http, а там уже должны на них смотреть разные location.
Не совсем понял, что имеется в виду, можно чуть подробнее с примером?
Потому, что Docker API работает по HTTP-протоколу. И чтобы прочитать какой-то ответ из сокета - туда сперва нужно записать запрос. Но даже если бы было иначе, то в Linux просто даже для подключения к Unix-сокету уже нужны права на write.
В директиву - нет. Но авторизация поддерживается уже сейчас. Через настройки блока client {} можно добавить какие угодно заголовки авторизации к запросу или даже клиентский сертификат, пользуясь обычными директивами модуля http proxy.
Самым нормальным способом была бы возможность в самом докере создавать дополнительные unix-сокеты с перенастроенным ограниченным доступом к API.
Так чем простейший пример в документации плох: https://angie.software/angie/docs/configuration/acme/#http - зачем ждать, пока где-то в каком-то блоге появится какая-то заметка, цитирующая документацию? =)
Такие сообщения регулярно в телеграм чате поддержки и комментариях в разных местах. Там просто не о чем писать: "поставили Angie, добавили пару директив, все работает автоматически, спасибо большое" - в таком духе. Пример: https://t.me/angie_support/7987 Если вдруг не работает, то обращаются за помощью и помогаем разобраться почему не работает.
Как поддержку добавили, я сам у себя на сервере удалил Certbot, добавил пару директив и работает с тех пор. Какой плюс? Избавился от лишнего компонента, которым забываешь как пользоваться через несколько месяцев и приходится вспоминать, когда нужно очередной домен завести. В конфиге веб-сервера его так или иначе нужно прописывать и теперь для этого достаточно просто добавить домен в server_name, сделать релоад конфига и всё. Не знаю как из этого выжать целую статью.
А тут коллега детально описал самый комплексный случай настройки, который только можно придумать, разобрался с OctoDNS и другими инструментами, которыми может кто-то захотеть воспользоваться, всё протестировал, написал скрипт и AFAIK никаких промптов. Людям теперь везде ИИ мерещатся. =)
А чем в таком случае не устроила официальная документация?
Вам в любом случае придется хранить список доменов и проверять по нему, прежде чем выпустить сертификат. Попробую объяснить почему.
Представим, что такого списка нигде нет. В SNI, как и в заголовке Host, клиент может указать вообще всё, что угодно, абсолютно любой домен. Таким образом злоумышленник сможет вывести ваш сервер из строя, начав запрашивать произвольные домены. Попытка выпустить сертификат на такой произвольный домен не увенчается успехом, однако вы попадете в черный список у ACME-сервера и не сможете получить сертификат для реального нужного домена.
Ок, вы скажите, что ACME клиент должен перед тем, как идти получать сертификат на новый домен - сам попытаться его отрезолвить. А я отвечу, что ничего не мешает злоумышленнику зарегистрировать какой-то домен и прописать для него IP-адрес вашего сервера. И ваш сервер даже получит на него сертификат, но при определенном количестве таких запросов у того же Let's Encrypt сработает лимит и получение новых сертификатов на какое-то время будет далее невозможно, что опять приведет к DoS.
Т.е. так или иначе, перед тем, как идти получать сертификат на какой-то домен с которым пришел клиент - неплохо бы проверить его по списку.
Те, кто использует Caddy таким образом в проде, сильно рискуют, если они не поставили перед ним ещё какой-то прокси, который умеет фильтровать TLS-подключения по SNI и таким образом фильтруют их по списку, либо используют механизм проверки домена внешним запросом к хранилищу, который предоставляет Caddy. Т.е. так или иначе, список доменов где-то есть и по нему происходит сверка.
Потенциально такой режим можно добавить и в Angie с соответствующими предупреждениями и инструкциями, как это безопасно настроить. Но какая-то проверка по списку доменов все равно будет, просто этот список будет храниться вне конфигурации сервера.
Абсолютно с вами согласен. Поэтому в свое время в NGINX Unit я реализовал это иначе. Там сертификат и ключ автоматически выбирается по SNI исходя из тех доменов, что прописаны в сертификате.
nginx и многие сервера появились задолго до того, как появился SNI, отсюда и такая настройка. Можно подумать над тем, как это переделать в Angie, чтобы было проще и удобнее чем механизм, унаследованный от nginx, но это уже отдельная задача.
Кстати, сам Игорь с вами не знаком. Что и не удивительно, оказалось такое же вранье, как и всё, что вы тут понавыдумывали.
Тут я скорее о том, что в принципе технически нормально не реализовать в случае отдельной утилиты, т.к. требует вмешательства в сам процесс TLS-хендшейка.
Мы пользователями привыкли называть тех, кто пользуется нашим ПО, т.е. устанавливает и занимается его настройкой. =)
Они по этой причине уходят на кадди, и не ощущают, что ошиблись. Опять же, кому не нужно и кто считает это ошибкой - может просто не пользоваться данным модулем и вообще его не собирать. Тем не менее, отставание от конкурентов в этом плане приводит только к потере пользователей. Кажется, это весомый аргумент, чтобы не отставать, если хочешь разрабатывать действительно популярное решение, а не что-то сугубо нишевое.
Значит у вас уже есть какой-то плейбук, вы в этом однажды разобрались и его написали. Это не из коробки. Это не поставил apt install angie, а дальше добавил две директивы и всё работает, причем добавил в парадигме конфигурационного файла, который и так нужно изучать, чтобы пользоваться nginx/Angie.
Да, и ошибки он допускает при настройке двух разных инструментов. Тратит время на изучение дополнительного инструмента, написание плейбука и пр. пр. Зачем этим заниматься, если можно воспользоваться встроенным решением, которое уже раз разработали те, кто разобрались в вопросе глубже, чем просто настройка Certbot и реализовали это автоматически.
Тут нужно понимать, что в статье рассмотрен довольно комплексный и сложный случай настройки. В простейшем виде вся настройка заключается в добавлении пары директив в конфиг из документации:
При этом обновление сертификатов происходит без перезагрузки процессов веб-сервера. Для тех, у кого доменов и сертификатов очень много, необходимость чаще перезапускать процессы - становится отдельной проблемой.
Вот вы спорите, а мы регулярно получаем благодарность от пользователей, которые пишут, что поддержка ACME в Angie - это стало для них одним из ключевых факторов, чтобы перейти с nginx и они очень довольны, благодарят за эту функциональность чаще, чем за многую другую.
Это же не вот вдруг нам заняться было нечем. Это был нескончаемый поток просьб встроить поддержку ACME в веб-сервер, т.к. по той или иной причине пользователи не хотят возиться с отдельным Certbot/Acme.sh и др., предпочитая вместо этого даже сменить веб-сервер на такой, где поддержка ACME уже встроена. Можно конечно сидеть и заявлять, что такие пользователи ошибаются, не должен этим заниматься веб-сервер, но это странный способ кому-то что-то доказать, весьма не конструктивный в плане развития и популяризации проекта.
В конце статьи есть ответ на вопрос чем лучше. Самое банальное - не нужно поддерживать список доменов в двух разных местах. Из небанального, что никогда в принципе не сможет скрипт на bash делать, так это выполнять ALPN-челендж, поддержку которого уже в ближайших версиях добавим.
Сколько я работаю в индустрии, то постоянно сталкиваюсь, что реальные пользователи чаще всего хотят обратного, а именно, чтобы всё работало из коробки и желательно тратить на это как можно меньше сил. И в целом, в этом нет ничего плохого... есть в индустрии другие задачи, чем как сопряжение отдельных разрозненных компонентов между собой каждый раз.
Так для чего повторять когда-то десятилетия назад выдвинутую догму, когда задачи и масштабы были совсем другие, снова и снова? Тем более, что тут возникает коллизия в том, а что есть утилита в части веб-сервера... должен ли он хорошо обрабатывать HTTPS трафик? Современному веб-серверу без этого никуда, а если да, то входит ли в эту задачу работа с сертификатами? Ведь если он не сможет обновлять сертификаты, то хорошо обрабатывать HTTPS трафик тоже не получится. Какая-то неполноценная утилита тогда выходит, не справляющаяся со свой задачей.
Форк создан большинством бывших разработчиков nginx. Среди них Хомутов, Ермилов, Бартенев.
Сысоев не занимается разработкой nginx примерно с 2012 года. Не знаю, с кем вы там знакомы, но мы вместе с ним работали над NGINX Unit вплоть до его увольнения из F5. =)
Мы отслеживаем найденные уязвимости в nginx и других форках, оперативно выпускаем исправления, иногда даже раньше, чем это делают сам nginx. Прецедентов нахождения уязвимостей в функциональности самого Angie ещё не было.
Кроме того, у нас есть ряд улучшений, направленных на дополнительное повышение безопасности и защиты от DoS-атак, в том числе портированных из freenginx.
Вы можете взять конфиг от nginx и запустить с ним Angie - будет работать также. Rutube, например, так и делает, им так удобнее. У нас же есть руководство по миграции.
Если вы не используете новую функциональность, которая была добавлена только в Angie, то отличий в директивах конфигурации нет за одним незначительным исключением.
Список фич есть на странице документации: https://angie.software/angie/docs/#index-features-oss - если преобразовать это в табличку, то будет просто более громоздко. Или требуется какой-то более расширенный список?
"Встроенный DNS‑резолвер NGINX не поддерживает fallback на TCP" - это неправда, как и множество других ошибок и неточностей в статье