3 ms·
It specifically needed to be its own record as the record requires DNSSEC to verify that the returned SSH key is trusted. Using TXT would be ridiculously insecu
by wallmountedtv 4y ago
It specifically needed to be its own record as the record requires DNSSEC to verify that the returned SSH key is trusted. Using TXT would be ridiculously insecure as it cannot force the DNSSEC verification step that SSHFP as a unique record gives.
Definitely annoying, but does ensure that the returned SSH key is always correct and not from a forged record.
- 8organicbits 4y agoCan you clarify the issue? Are you saying that DNSSEC doesn't allow verification of TXT records, but does support SSHFP records? I'm not seeing a reference to that online.
- LeonM 4y ago> Using TXT would be ridiculously insecure as it cannot force the DNSSEC verification step that SSHFP as a unique record gives. I don't believe that that is true. DNSSEC RRSIG records are created over the entire result set. So even if there are numerous records returned, you should still be able to verify the signature. Also, there is nothing stopping you from also returning multiple SSHFP records in a single query. However, SPF does have a design flaw (amongst many other) that the record is placed under the domain root, which is often already polluted with other records. This is why other standards that use TXT (DMARC, DKIM, BIMI, MTA-STS, TLSRPT, etc.) use a specific label prefix, or a selector. But this is not because of DNSSEC.
- teddyh 4y agoWhat are you talking about? DNSSEC can sign TXT records perfectly well, just as any other RR type. Of course, it’s much cleaner, design-wise, to have its own RR type, and any resolvers which cannot tolerate unknown types are seriously obsolete and should be replaced.