DNS Leakage

("SSH resolve"/"DNS lookup") itself is not encrypted, If (normal DNS/unencrypted DNS/legacy DNS/oldschool DNS) is used, (someone spying on the dns server/hacker sniff:ing the network) may not see the SSH traffic, but they still see which server was looked up and at what time a client resolved shell.hiddenssh.com.

That means DNS can leak metadata about SSH usage.

DNS security is therefore relevant to SSH because the connection often begins with name resolution. The internet works in reality with IP numbers; DNS is only the phonebook that maps (domain names/vhost) to specific IP addresses.

Hardware key

(Hardware key/trezor/ledger) use an identity string to map a key to a (vhost/domain) of the host server.

ssh-ed25519 AAAA... <ssh://user1@shell.hiddenssh.com>

CheckHostIP and DNS Resolution

When CheckHostIP yes is enabled, which is the default, SSH also checks the IP address stored for that host in ~/.ssh/known_hosts against the IP address that the hostname currently resolves to. This helps detect possible DNS spoofing or man-in-the-middle changes.

DNS resolution happens before this check, as part of turning a hostname shell.hiddenssh.com into an IP address.

In short, CheckHostIP yes is about verifying the resolved IP against ~/.ssh/known_hosts during connection. It is not what performs the name lookup. DNS resolution happens anyway whenever you connect to SSH using a hostname instead of a direct IP address.

Using: /etc/hosts

If /etc/hosts contains shell.hiddenssh.com 1.2.3.4, SSH uses that IP directly and normally skips DNS for that hostname. The lookup order is controlled by /etc/nsswitch.conf, usually hosts: files dns myhostname.

With an /etc/hosts entry, the hostname is mapped locally before DNS query. Since the hostname never goes to DNS for DNS query, that SSH lookup does not create a DNS leak.

But it needs entry for each server, and can become a nightmare to manage. And an eye on nsswitch.conf...

nano ~/.ssh/config

Simplest way to avoid exposure is not to use domains, and use only IPs; using ssh client config file, ("hosts"/"directive"/"host section").
This is not a practical solution for a server with large amount of users, and that might have an IP Change.
It is far easier and better to use domains rather then IP numbers, but for maximum security; using IPs defined as hostname in the ssh config file is the better option.

DNS / Firewall

DNS over HTTPS provides privacy and security for DNS queries and responses by encrypting them in transit.
TCP/443, same port and protocol used for HTTPS traffic, making it more likely to work across networks.
Much more reliable when using a laptop on the move across different networks.

Service Providers:

• Cloudflare
  1.1.1.1:443
• Cloudflare
  1.0.0.1:443
• OpenDNS by Cisco
  208.67.222.123:443
• OpenDNS by Cisco
  208.67.220.123:443

DNS SEC:

Domain Name System Security Extensions, ("dnssec"/"dns security"). Can be applied to a servers (domain/vhost) for extra level of security,
but OpenSSH does not process it anyway in application level.

Risk

Your DNS query's is still at the same level of risk when using an ("unencrypted dns"/"normal dns"), but only exposed towards the service provider.
The query's are not magically at the endpoint local:ly encrypted and anonymous:ed at any provider, and chosing the right one becomes based on reputation and time it has existed.

Technical

DNS over SSH works by creating an SSH tunnel between the DNS client and a remote server by the IP address, then forwarding DNS traffic through that tunnel.

By creating an SSH Tunnel from the client using (-L/ local port forwarding) and mapping 127.0.0.1:53 on the client to the server’s DNS port, so DNS traffic can be routed through that server for resolution.

Risk

tcp/22 is more likely to be blocked on different networks.

Hack

Have sshd listen on multiple ports for the same process, 22 and 443 on the same IP.
It will work for a dumb Firewalls that only looks at port/protocol.
But a Firewall with Deep Packet Inspection (DPI) can usually detect the protocol by the first few bytes and blocks SSH/443.

Technical

When people say DNS over SSL, they often really mean DNS over TLS.

DNS over TLS / DoT
Port: TCP/853
Protocol: TLS
Modern standard: Yes

Firewall Issues

When you are on the move a lot, using TCP/853 becomes very fast a hassle and a pain.
IT admins block it on their networks; coperate guest wifi networks, in coffee shops, hotel lobbies, and airport lounges.
If you fly a lot and visit different regions or countries with different sets of laws and strict regulations, TCP/853 is most likely blocked by default.

Summary

TLS is a more modern secure way to perform DNS query, but it lacks the stability of TCP/443.
Most ideal usage is in colocation-hosted servers, VPCs, or anywhere you have fully non-firewalled traffic all the time.