Адреса резолвятся через системный DNS, а не через DNS антизапрета. Если ваш провайдер блокирует сайты по IP, антизапрет будет работать только частично, т.к. не предназначен для таких провайдеров.
С помощью blockcheck v0.0.9.8 выяснил что проблемы с DNS на стороне провайдера и каноничные DNS-серверы прописывать бессмысленно.
[!] Результат:
[] Ваш провайдер блокирует сторонние IPv4 DNS-серверы.
Вам следует использовать шифрованный канал до DNS-серверов, например, через VPN, Tor, HTTPS/Socks прокси или DNSCrypt.
[
[
DNSCrypt помог. Осталось 3 вопроса. Почему проблемы с DNS не проявляются в Opera и прочих браузерах на вебките? Почему проблемы проявляются в Firefox только при включенном прокси Антизапрета? Что означает переменная dnsResolve(null), резолвинг через DNS Антизапрета?
Неплохо было бы добавить в инструкцию Антизапрета предупреждение что Firefox не работает с Антизапретом без DNSCrypt при блокировках сторонних DNS-серверов. Установить и настроить DNSCrypt конечно несколько сложнее чем вбить url скрипта автонастройки прокси в настройки браузера, что явно не добавит лисе популярности.
Большое всем спасибо что помогли разобраться.
ip = dnsResolve(hostname);
hostname – доменное имя.
dnsResolve – функция, принимающая доменное имя и возвращающая ip-адрес.
Я советовал вам заменить ip = dnsResolve(hostname) на ip = null.
То, как вы сделали, передав null вместо hostname, неожиданно тоже сработало, наверно, потому что функция может принимать ложные значения (false, '', 0, null и т.п.) и возвращает для них что-то типа null вместо ip-адреса, как я догадываюсь.
А попробуйте DNS over HTTPS: меню → Настройки → Основные → Параметры сети → Настроить… → Отметить галочкой “Включить DNS через HTTPS”.
Для чистоты эксперимента проверил ip = null - тоже сработало.
ip-адреса открываемого ресурса? Тогда откуда Firefox берёт его когда там null?
Отключил DNSCrypt и включил DNS over HTTPS в Firefox.
Proxy.pac отключен: неблокированные ресурсы отлично загружаются как при использовании дефолтного DoH-резолвера Cloudflare, так и при использовании стороннего, оба резолвера не блокируются провайдером и открываются без каких-либо проблем.
Proxy.pac включен: с обоими DoH-резолверами неблокированные ресурсы лагают также как cо стандартными DNS.
В PAC-скрипте есть главная функция, что-то типа main в других языках программирования, но тут она называется FindProxyForURL(url, hostname). Эта функция вызывается при любом http-запросе браузера и в эту функцию передаются аргументы url и hostname для совершаемого запроса. hostname часто зовётся host, что я считаю неправильным (т.к. если адрес содержит порт, то это host, иначе hostname).
Так вот, внутри этой главной функции зовётся функция dnsResolve(hostname). В переменной hostname лежит доменное имя запроса, как я описал в предыдущем абзаце. Если hostname заменить на null, то dnsResolve не знает, ip адрес какого доменного имени вы от него требуете и, как я догадываюсь, возвращает опять null, но уже в качестве результата работы (а не аргумента в скобочках в dnsResolve(null)). При таком “холостом” вызове DNS-запроса не совершается совсем.
Я не вижу смысла разбираться в проблеме — очевидно, она вызвана проблемами с DNS.
Если хотите разобраться, начните с записи трафика на порт 53.
В PAC-скрипте используется не hostname, а host.
FindProxyForURL(url, host)
dnsResolve(host)
и тд.
Если при “холостом” вызове DNS-запроса не совершается совсем, то откуда браузер берёт ip? Это любая версия Firefox 69.* - 70.*. Чем проще всего записать трафик на 53 порт?
dnsResolve вызывается на каждый запрос, к любым сайтам. Эта функция не обязательно будет работать точно так же, как резолв домена в браузере.
ip = dnsResolve(null) и ip = null аналогичны по моей догадке. ip не присваивается строка с адресом, вместо этого ему присваивается значение null (не строка). Если говорить о том, откуда тогда браузер берёт ip для сайта вообще, т.е. вне PAC-скрипта, то там уже отдельный скрипт и он, скорей всего, не на js.
Отправил всем в ЛС запись трафика на 53 порт. Всё записано при включенном proxy.pac, за исключением файла Firefox.pcapng. Особых отличий в запросах-ответах и таймингах между ними при лагах не вижу, но возможно что-то проглядел. Если они действительно не отличаются, тогда совсем непонятно почему движок Firefox ломается при включении proxy.pac.
Благодарю всех за помощь, это баги Firefox.
- Функция dnsResolve блокирует движок, если для некоторых из запрашиваемых страницой доменов не приходит никакого ответа от DNS. Это не позволяет движку загрузить контент с остальных доменов пока блокировка не снимется по таймауту, что сильно замедляет загрузку страницы.
- DNS-over-HTTPS не работает для функции dnsResolve. При включении DNS-over-HTTPS, все запросы функции dnsResolve идут к системному DNS на 53 порт.
Создал https://bugzilla.mozilla.org/show_bug.cgi?id=1592248. 127.0.0.1 у меня тоже проксируется, PAC-скрипт для него срабатывает, dns-пакеты отсылаются.
Странно что 127.0.0.1 проксируется, в Firefox на Windows он в исключениях. Второй баг тоже надо зарепортить, у них там какой-то говнокод, если сравнивать с вебкитом. Видимо в вебките это как-то асинхронно исполняется.
Попробуйте отправить им второй баг самостоятельно, я мало заинтересован в том, чтобы чинить FireFox для работы с блокировками на уровне DNS, мне нужно, чтобы наши PAC-скрипты работали у пользователей безопасно (т.е. через DoH) и независимо от системных DNS, когда нужно.
WebKit-браузеры на windows – это, наверно, уже редкость, я ни одного не знаю. Хромиум перешёл на собственный движок Blink.
Спасибо, дописал к репорту. Кстати, какой практический смысл в резолвинге через dnsResolve(), а не напрямую через движок?
Внутри PAC-скрипта вам не известен IP-адрес. Единственный способ там его получить – это dnsResolve. Почему dnsResolve работает не так, как адресная строка браузера, я не знаю. По идее dnsResolve отрабатывает до отправки DNS-запроса адресной строки (к примеру, этот dns-запрос вообще может быть передан прокси-серверу, установленному через PAC-скрипт).