DNStt как способ обхода белых списков - пара вопросов

[Marta5v]

Мелькало мнение, что dnstt можно использовать в двух ситуациях:

1. Получение бесплатного интернета от ОпСоСа при нулевом балансе;
2. Для нынешнего обхода вайтлистов

Вопрос: как это работает? В случае с VLESS (ситуация 2) мы как бы подделываемся под разрешенный домен, однако это спешно фиксится (видимо, через сопоставление SNI с CIDR/IP сервера). Т.е. опсос так или иначе видит, на какой IP мы ходим.

В случае с dnstt, по моему пониманию, мы отправляем запросы к какому-то публичному dns (например, google), запрашивая IP нашего домена, а полезные данные гоняем внутри этих запросов-ответов. И здесь непонятная для меня часть:

1. во-первых, провайдер видит, что мы стучимся на условный 8.8.8.8, которого не присутствует в белом списке (по крайней мере, явно)
2. во-вторых, он видит, запрос о каком ресурсе мы производим. Даже если мы используем dns самого провайдера, запросы мы все равно делаем по нашему личному домену, которого в вайтлисте быть не может

Так как же это работает “под капотом“, с учетом вышеозвученного? Провайдер видит, что мы запрашиваем IP не разрешенного домена через не разрешенный же dns-сервер - разве он ничего с этим не может сделать?

[Xunlei]

@Marta5v

как это работает?

https://ntc.party/c/community-software/dnstt/33

@Marta5v

мы отправляем запросы к какому-то публичному dns

К резолверу ISP или опсоса, который указывается в DHCP (можно напарсить дополнительные того же провайдера).

@Marta5v

запросы мы все равно делаем по нашему личному домену, которого в вайтлисте быть не может

Пока политик ограничений на резолверах нет, будет работать, если появятся (например запрет TXT записей при нулевом балансе), то перестанет.

[Marta5v]

@Xunlei

https://ntc.party/c/community-software/dnstt/33

Под этим вопросом имелось в виду “как это работает с учетом очевидности для провайдера попыток обхода его рестрикций“

@Xunlei

К резолверу ISP или опсоса, который указывается в DHCP (можно напарсить дополнительные того же провайдера).

Да, об этом тоже подумалось, но ведь провайдер всё равно видит, какой домен мы запрашиваем - и он явно не будет в “белом списке“

@Xunlei

Пока политик ограничений на резолверах нет, будет работать, если появятся (например запрет TXT записей при нулевом балансе), то перестанет.

[Xunlei]

Понял. Будет работать пока не пофиксят. Думаю, к моменту повсеместного чебурнета (белых списков), если и будут работать произвольные ru домены, то добавят Query Rate Limit на домен второго уровня — тогда только какой-нибудь текстовый чат можно будет реализовать.

[Marta5v]

Ясно, благодарю за ответ!
Следом хотелось бы задать еще один вопрос, который сразу не вспомнился: что влияет на размер эффективного MTU? Иными словами, как увеличить количество полезных данных, передаваемых в пакете через dnstt? Про правило “чем короче домен для запроса - тем больше места остается” и настройку MTU в конфиге dnstt известно, но может, есть еще что-то - например, дополнительные настройки с серверной стороны, или уменьшение количества записей самого домена, или использование определенного резолвера (Cloudflare, etc)?

[Xunlei]

@Marta5v

на что влияет на размер эффективного MTU?

Устанавливается только на сервере. Влияет на количество данных в ответе сервера, т.е. тем он больше, тем больше payload и меньше overhead на скачивание (на моих провайдерских резолверах больше 1232 не поддерживаются).

@Marta5v

или использование определенного резолвера (Cloudflare, etc)?

Зависит

@server/main.go

	// On 2020-04-19, the Quad9 resolver was seen to have a UDP payload size
	// of 1232. Cloudflare's was 1452, and Google's was 4096

Размер более 1232 приведёт к фрагментации пакета ответа, верноятность потерять которого кратно возрастёт, если ещё настройками резолвера примется при этом.

@Marta5v

Про правило “чем короче домен для запроса - тем больше места остается”

Длина домена влияет на payload отдачи: чем он короче, тем больше места остаются для аплоада. На рег.ру пока свободные случайные 4-х буквенные домены можно легко найти.

[bolvan]

При белых списках вероятен запрет обращения к любым DNS, кроме провайдерского.
А у них обычно плохо с рейт-лимитом. Виснет все.
Я имел дело с белым только однажды - когда заблочили на половину дня из-за БПЛА.
Тк был тогда с простой тыкалкой без доступа к компу и с плохой связью, особо исследовать не удалось.
Во всех современных броузерах и мобильных ОС по умолчанию DoH.
Если они делают белые списки, это значит, что у всех должен открываться вк.
Но как он откроется, если более 90% даже не догадывается, что есть DoH, и он заблокирован ?
Сейчас такой контингент пользователей, что у них все должно работать сразу. Надо рассчитывать, что юзера не могут абсолютно ничего. У них либо работает с первого тыка, либо не работает вообще. Настраивать что-то для них - это за гранью фантастики.
Надо проверить бы доступны ли стандартные ресолверы DoH под белыми.
И если да, почему бы не использовать их для прогона dnstt ? Это заодно скроет от провайдеров и властей весь передаваемый трафик как через VPN. Разве что увидят аномалию по трафику

[wigeance]

DoT/DoH во время белизны не работает, со следующими оговорками

DoT просто в блоке везде, видимо из-за нестандартного порта

На одном операторе работает DOH яндекса, на другом уже нет

Работают только dns провайдера по udp/53, пробовал постучаться в НСДИ, MSK-IX dns и т.д. - не работают

На dns яндекса udp/53 как-будто бы рейт лимит стоит (возможно dns hijack оператором), через него даже спидтест через dnstt не проходит

[bolvan]

Тогда у всех из коробки вообще ни один сайт не откроется.
Саму идею проверил. Через dns.google doh вполне dnstt работает.
Собрал https_dns_proxy от openwrt под cygwin, dnstt для винды. Работает.

На яндексе тоже рейт лимит. Кое-как удается что-то написать в шелле, но чуть что-то большее - вис на несколько секунд после каждых нескольких кб

[Marta5v]

@Xunlei

Устанавливается только на сервере. Влияет на количество данных в ответе сервера, т.е. тем он больше, тем больше payload и меньше overhead на скачивание (на моих провайдерских резолверах больше 1232 не поддерживаются).

На сервере стоит 1232, при установке соединения с клиентских устройств в их консоли пишется “effective MTU 137”. Пробовалось менять MTU dnstt с серверной стороны на 512 и на 1400, а также резолвер на 8.8.8.8 и 1.1.1.1, но всё равно “клиентский эффективный” никак не менялся… Что за “effective MTU” и как можно повлиять на него?

[Xunlei]

На клиенте MTU отдачи зависит от длины домена. У меня тоже 137 для 4-х буквенного. Вычисляется так:

@client/main.go

// How many bytes of random padding to insert into queries.
numPadding = 3

mtu := dnsNameCapacity(domain) - 8 - 1 - numPadding - 1 // clientid + padding length prefix + padding + data length prefix

// dnsNameCapacity returns the number of bytes remaining for encoded data after including domain in a DNS name.
func dnsNameCapacity(domain dns.Name) int {
	// Names must be 255 octets or shorter in total length.
	// https://tools.ietf.org/html/rfc1035#section-2.3.4
	capacity := 255
	// Subtract the length of the null terminator.
	capacity -= 1
	for _, label := range domain {
		// Subtract the length of the label and the length octet.
		capacity -= len(label) + 1
	}
	// Each label may be up to 63 bytes long and requires 64 bytes to encode.
	capacity = capacity * 63 / 64
	// Base32 expands every 5 bytes to 8.
	capacity = capacity * 5 / 8
	return capacity
}

Канал получается ассиметричный, как в мобильных сетях, DSL или спутнике.

Способы Internet over DNS можно считать как аварийные, а не для повседневного использования.

[Marta5v]

Благодарю за подробные разъяснения!

@Xunlei

Способы Internet over DNS можно считать как аварийные, а не для повседневного использования.

Да, разумеется

[BARNS]

хм, интересная вещь, надо бы почитать