The Cloudflare proxy tier no longer asks DNS for kws{N}-1 records. Each one
was a wasted lookup, and on --default-domains a guaranteed failure that showed
up in the log as a warning.
No more kws2-1.<domain>: Name does not resolve (#139)
For every CF domain the proxy tried two hostnames, kws{N}.{domain} and
kws{N}-1.{domain}. Neither upstream tg-ws-proxy nor the shared
--default-domains zones have -1 records, and they could not help anyway:
through Cloudflare the hostname only selects the origin IP, and our own setup
guide pointed both records at the same DC. So every -1 attempt cost a DNS
lookup that, on the default domains, always came back NXDOMAIN.
The proxy meant to stay quiet about that miss, but it only did when the base
record had not already timed out. With the default list, base records time out
often, so logs filled with lines like this one:
CF WS DC2 failed on kws2-1.pclead.co.uk: TCP connect: failed to lookup address information: Name does not resolve
The log in #124 has 99 of these in two and a half minutes. On routers that run
dnscrypt-proxy or other DoH setups, the lookup volume also overloaded the
resolver, which started answering Try again.
What changed:
- Only
kws{N}.{domain}is dialled. Each domain gets two attempts at it, back
to back, unless the first one timed out. - The number of attempts is the same as before. The missing
-1record used to
give the base record its second attempt implicitly, and dropping that retry
had measurably pushed more connections into the TCP fallback. It is now
explicit, and media and non-media DCs get it alike. - The direct WebSocket path is unchanged:
kws{N}-1.web.telegram.orgreally is
a separate Telegram host and is still tried.
If you run your own --cf-domain, nothing needs to change. The kws1-1…
kws203-1 records from older versions of docs/CfProxy.md are no longer
queried and can be deleted. The guide, docs/Fallbacks.md and
cloudflare-dns-import.txt no longer list them.
What it costs
- A zone whose
-1records deliberately point somewhere other than the base
record loses that route. The setup guide never described such a zone. - The second attempt now goes to the same hostname instead of a different one,
so it reuses the base record's DNS answer and TLS session.