I'm breaking out the discussion about reliance on PTR records into a new issue here.
Over on T2902 , Werner wrote:
To answer your question:
Can you explain why dirmngr does the DNS roundtrip lookup, mapping
from the pool's A and AAAA addresses back to names? It seems like
it'd be a lot simpler (and faster, and less error-prone) to avoid
the PTR lookups if we have the IP addresses already.
If it is a plain server and not a pool, looking up the PTR is
necessary to get the hostname for SNI and possible also for Host:
This is *not* the standard way to set SNI for TLS, or the standard way to set
the Host: header for HTTP.
The expectation in the TLS and HTTP worlds is that the SNI and the Host: headers
will contain the name that the client is configured with, *not* the name
reported by PTR records.
Using PTR records to "scrub" SNI actually leaves a security vulnerability if the
client is willing to accept certificates that match the PTR-derived hostname,
instead of requiring certificates to match the client-configured hostname.
As for sending the Host: header -- as with a browser lookup, i'd expect any HTTP
client to send the requested (client-configured) hostname, not anything that has
passed through a DNS reverse lookup.
For a pool we would not need the name because the already known name
of the pool is used for SNI. However, to find duplicate hosts in the
hosttable it is useful to have the hostname.
I'm assuming that "duplicate hosts" means "hosts reachable via multiple
addresses". Is that what you mean? For example, if a keyserver foo.example.com
is reachable on both an IPv4 address, and is also reachable on an IPv6 address,
then those two addresses are in some sense "duplicates". is that right?
If so, i'm not convinced what dirmngr gains from that information. If i can't
reach host X via address A, does that mean i *should* or *should not* try
reaching it on address B?
We also return the
actual used hostname to gpg for information purposes and to eventually
store this with the key as meta info.
The "actual used hostname" should be the configured hostname, i think. any
additional metadata about the path that the key was recovered would be
interesting to have, but none of it is cryptographically authenticated. And if
we're not doing anything with it today, why should dimrngr block for several
more seconds (on what can already be a fairly high-latency operation) for info
that we're likely to just throw away?
Yes, we could the PTR lookup of pools faster or in the background -
but for now a simple appraoch is better for debugging.
sure, we can leave the discussion about parallelizing DNS queries and responses
to T2907 :)
For this ticket, let's focus on whether we can just do away with PTR entirely.
What would make sense: a patch to make it optional, with another config option
for dirmngr? or just a patch to remove reverse DNS requests entierly?