<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Dnscontrol on 5ok — sysadmin, devops, hosting</title><link>https://www.5ok.eu/tags/dnscontrol/</link><description>Recent content in Dnscontrol on 5ok — sysadmin, devops, hosting</description><generator>Hugo</generator><language>en</language><lastBuildDate>Sun, 20 Sep 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://www.5ok.eu/tags/dnscontrol/index.xml" rel="self" type="application/rss+xml"/><item><title>Hardening First-Connect SSH Trust with SSHFP Records</title><link>https://www.5ok.eu/blog/hardening-first-connect-ssh-trust-with-sshfp-records/</link><pubDate>Sun, 20 Sep 2026 00:00:00 +0000</pubDate><guid>https://www.5ok.eu/blog/hardening-first-connect-ssh-trust-with-sshfp-records/</guid><description>&lt;p&gt;Anyone who&amp;rsquo;s used SSH has seen this prompt on the first connection to a new host:&lt;/p&gt;
&lt;pre tabindex="0"&gt;&lt;code&gt;The authenticity of host &amp;#39;example.com (203.0.113.1)&amp;#39; can&amp;#39;t be established.
ED25519 key fingerprint is SHA256:...
Are you sure you want to continue connecting (yes/no)?
&lt;/code&gt;&lt;/pre&gt;&lt;p&gt;The honest answer for most people, most of the time, is &amp;ldquo;I have no idea - but I&amp;rsquo;ll type yes anyway.&amp;rdquo; That&amp;rsquo;s trust-on-first-use (TOFU): SSH has no independent way to confirm the host key is genuine on that first connection, which is exactly the window in which a man-in-the-middle attack could substitute a different key without anyone noticing.&lt;/p&gt;</description></item></channel></rss>