payment_identifier: expand FIXME that openalias resolution DNS-leaks
What the developer wrote
Authored by SomberNight
payment_identifier: expand FIXME that openalias resolution DNS-leaks
and even for lightning-address, we also do the openalias resolution!
What changed, and why it matters
This commit only adds comments to the code. It does not fix anything. The comments warn that when Electrum resolves OpenAlias or Lightning Address payment identifiers, it sends DNS queries directly to Google's DNS server (8.8.8.8) instead of routing them through the user's configured network proxy (such as Tor). This could leak the user's real IP address and the fact that they are looking up a particular payment recipient. The commit itself is a documentation of a known privacy weakness, not a security patch.
Treat this as a known privacy issue that still needs a real fix. Users who require proxy/Tor privacy should avoid OpenAlias and Lightning Address lookups until DNS resolution is routed through the configured proxy. Developers should implement proxy-aware DNS resolution, for example by using the Tor SOCKS RESOLVE extension or routing queries through a proxy-compatible resolver.
Security signals we found
DNS queries bypass user-configured network proxy
Hardcoded external DNS resolver (8.8.8.8) receives query metadata
Potential IP address leak for users relying on Tor/proxy for privacy
OpenAlias and Lightning Address resolution share the same leaky path
Commit is comment-only; no mitigation implemented
Evidence from the diff
The diff expands FIXME comments in electrum/dnssec.py and electrum/payment_identifier.py. dnssec.query() already hardcodes 8.8.8.8 as the nameserver and notes it does not use the network proxy. The new comments add that Tor SOCKS proxies could use the RESOLVE extension, and that resolving openalias in payment_identifier.py bypasses the proxy and leaks the user’s IP to the DNS server. No code behavior changes; only explanatory text is added.
Changed components
electrum/dnssec.pyelectrum/payment_identifier.pyOpenAlias resolutionLightning Address resolutionInspect captured patch +4 / −0
diff --git a/electrum/dnssec.py b/electrum/dnssec.py
index 9a9d733..2415317 100644
--- a/electrum/dnssec.py
+++ b/electrum/dnssec.py
@@ -144,6 +144,8 @@ async def query(url: str, rtype: dns.rdatatype.RdataType) -> Tuple[dns.rrset.RRs
so the caller must carefully consider whether the response can be used for anything if validated=False.
"""
# FIXME this method is not using the network proxy. (although the proxy might not support UDP?)
+ # if the proxy is a Tor SOCKS proxy, we could use Tor's "RESOLVE" extension command.
+ # (see https://spec.torproject.org/socks-extensions.html)
# 8.8.8.8 is Google's public DNS server
nameservers = ['8.8.8.8']
ns = nameservers[0]
diff --git a/electrum/payment_identifier.py b/electrum/payment_identifier.py
index 7fe8a2f..aed2124 100644
--- a/electrum/payment_identifier.py
+++ b/electrum/payment_identifier.py
@@ -319,6 +319,8 @@ class PaymentIdentifier(Logger):
openalias_task = asyncio.create_task(self.resolve_openalias(openalias_key))
# prefers lnurl over openalias if both are available
+ # FIXME resolving openalias disregards the network proxy and leaks our IP to
+ # the DNS server. (see dnssec.query)
lnurl = lightning_address_to_url(self.emaillike) if self.emaillike else None
if lnurl is not None and (lnurl_result := await try_resolve_lnurlpay(lnurl)):
openalias_task.cancel()
Why this scored 35/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.