#13

Адреса резолвятся через системный DNS, а не через DNS антизапрета. Если ваш провайдер блокирует сайты по IP, антизапрет будет работать только частично, т.к. не предназначен для таких провайдеров.

#14

С помощью blockcheck v0.0.9.8 выяснил что проблемы с DNS на стороне провайдера и каноничные DNS-серверы прописывать бессмысленно.

[!] Результат:
[:warning:] Ваш провайдер блокирует сторонние IPv4 DNS-серверы.
Вам следует использовать шифрованный канал до DNS-серверов, например, через VPN, Tor, HTTPS/Socks прокси или DNSCrypt.
[:warning:] Ваш провайдер полностью блокирует доступ к HTTPS-сайтам из реестра.
[:warning:] У вашего провайдера “обычный” DPI. Вам поможет HTTPS/Socks прокси, VPN или Tor.

DNSCrypt помог. Осталось 3 вопроса. Почему проблемы с DNS не проявляются в Opera и прочих браузерах на вебките? Почему проблемы проявляются в Firefox только при включенном прокси Антизапрета? Что означает переменная dnsResolve(null), резолвинг через DNS Антизапрета?

Неплохо было бы добавить в инструкцию Антизапрета предупреждение что Firefox не работает с Антизапретом без DNSCrypt при блокировках сторонних DNS-серверов. Установить и настроить DNSCrypt конечно несколько сложнее чем вбить url скрипта автонастройки прокси в настройки браузера, что явно не добавит лисе популярности.

Большое всем спасибо что помогли разобраться.

#15 
ip = dnsResolve(hostname);

hostname – доменное имя.
dnsResolve – функция, принимающая доменное имя и возвращающая ip-адрес.

Я советовал вам заменить ip = dnsResolve(hostname) на ip = null.
То, как вы сделали, передав null вместо hostname, неожиданно тоже сработало, наверно, потому что функция может принимать ложные значения (false, '', 0, null и т.п.) и возвращает для них что-то типа null вместо ip-адреса, как я догадываюсь.

А попробуйте DNS over HTTPS: меню -> Настройки -> Основные -> Параметры сети -> Настроить… -> Отметить галочкой “Включить DNS через HTTPS”.

#16

Для чистоты эксперимента проверил ip = null - тоже сработало.

ip-адреса открываемого ресурса? Тогда откуда Firefox берёт его когда там null?

Отключил DNSCrypt и включил DNS over HTTPS в Firefox.
Proxy.pac отключен: неблокированные ресурсы отлично загружаются как при использовании дефолтного DoH-резолвера Cloudflare, так и при использовании стороннего, оба резолвера не блокируются провайдером и открываются без каких-либо проблем.
Proxy.pac включен: с обоими DoH-резолверами неблокированные ресурсы лагают также как cо стандартными DNS.

#17

В PAC-скрипте есть главная функция, что-то типа main в других языках программирования, но тут она называется FindProxyForURL(url, hostname). Эта функция вызывается при любом http-запросе браузера и в эту функцию передаются аргументы url и hostname для совершаемого запроса. hostname часто зовётся host, что я считаю неправильным (т.к. если адрес содержит порт, то это host, иначе hostname).

Так вот, внутри этой главной функции зовётся функция dnsResolve(hostname). В переменной hostname лежит доменное имя запроса, как я описал в предыдущем абзаце. Если hostname заменить на null, то dnsResolve не знает, ip адрес какого доменного имени вы от него требуете и, как я догадываюсь, возвращает опять null, но уже в качестве результата работы (а не аргумента в скобочках в dnsResolve(null)). При таком “холостом” вызове DNS-запроса не совершается совсем.

#18

@ValdikSS, может, в этой версии FireFox dnsResolve использует системный DNS в обход DoH?

#19

Я не вижу смысла разбираться в проблеме — очевидно, она вызвана проблемами с DNS.
Если хотите разобраться, начните с записи трафика на порт 53.

#20

В PAC-скрипте используется не hostname, а host.
FindProxyForURL(url, host)
dnsResolve(host)
и тд.

Если при “холостом” вызове DNS-запроса не совершается совсем, то откуда браузер берёт ip? Это любая версия Firefox 69.* - 70.*. Чем проще всего записать трафик на 53 порт?

#21

dnsResolve вызывается на каждый запрос, к любым сайтам. Эта функция не обязательно будет работать точно так же, как резолв домена в браузере.

#22

Wireshark.

#23

ip = dnsResolve(null) и ip = null аналогичны по моей догадке. ip не присваивается строка с адресом, вместо этого ему присваивается значение null (не строка). Если говорить о том, откуда тогда браузер берёт ip для сайта вообще, т.е. вне PAC-скрипта, то там уже отдельный скрипт и он, скорей всего, не на js.

#24

Отправил всем в ЛС запись трафика на 53 порт. Всё записано при включенном proxy.pac, за исключением файла Firefox.pcapng. Особых отличий в запросах-ответах и таймингах между ними при лагах не вижу, но возможно что-то проглядел. Если они действительно не отличаются, тогда совсем непонятно почему движок Firefox ломается при включении proxy.pac.

#25

Благодарю всех за помощь, это баги Firefox.

  1. Функция dnsResolve блокирует движок, если для некоторых из запрашиваемых страницой доменов не приходит никакого ответа от DNS. Это не позволяет движку загрузить контент с остальных доменов пока блокировка не снимется по таймауту, что сильно замедляет загрузку страницы.
  2. DNS-over-HTTPS не работает для функции dnsResolve. При включении DNS-over-HTTPS, все запросы функции dnsResolve идут к системному DNS на 53 порт.
Медленная прогрузка страниц в Firefox
Жуткие тормоза последние пару дней при использовании PAC скрипта
#26

Создал https://bugzilla.mozilla.org/show_bug.cgi?id=1592248. 127.0.0.1 у меня тоже проксируется, PAC-скрипт для него срабатывает, dns-пакеты отсылаются.

#27

Странно что 127.0.0.1 проксируется, в Firefox на Windows он в исключениях. Второй баг тоже надо зарепортить, у них там какой-то говнокод, если сравнивать с вебкитом. Видимо в вебките это как-то асинхронно исполняется.

#28

Попробуйте отправить им второй баг самостоятельно, я мало заинтересован в том, чтобы чинить FireFox для работы с блокировками на уровне DNS, мне нужно, чтобы наши PAC-скрипты работали у пользователей безопасно (т.е. через DoH) и независимо от системных DNS, когда нужно.

#30

Создал https://bugzilla.mozilla.org/show_bug.cgi?id=1592556

#31

WebKit-браузеры на windows – это, наверно, уже редкость, я ни одного не знаю. Хромиум перешёл на собственный движок Blink.

#32

Спасибо, дописал к репорту. Кстати, какой практический смысл в резолвинге через dnsResolve(), а не напрямую через движок?

#33

Внутри PAC-скрипта вам не известен IP-адрес. Единственный способ там его получить – это dnsResolve. Почему dnsResolve работает не так, как адресная строка браузера, я не знаю. По идее dnsResolve отрабатывает до отправки DNS-запроса адресной строки (к примеру, этот dns-запрос вообще может быть передан прокси-серверу, установленному через PAC-скрипт).