[Dxspider-support] Forgeries

[Tim Tuck]

Or you could put a hash in a TXT record as a key and query for that just 
like ACME and Google do and use that for verification.

e.g. here is an one from an old inactive server of mine...

[timt at timzpc 18:04 ~]$dig -t txt        _acme-challenge.monitor.skybase.net

; <<>> DiG 9.18.30-0ubuntu0.24.04.2-Ubuntu <<>> -t txt 
_acme-challenge.monitor.skybase.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4319
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;_acme-challenge.monitor.skybase.net. IN    TXT

;; ANSWER SECTION:
_acme-challenge.monitor.skybase.net. 5 IN TXT 
"3AdPIb2NZCUY7tcPGzc67ZrdvF-OCSdDGHkH0hCTSog"

;; Query time: 27 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Wed Mar 12 18:05:01 AEDT 2025
;; MSG SIZE  rcvd: 120

[timt at timzpc 18:05 ~]$

cheers

Tim

On 12/3/25 12:19, Rudy Bakalov via Dxspider-support wrote:
>  1/ Cluster A has defined SSID N2WQ-1 with FQDN cluster.n2wq.com as 
> partner
> 2/ Cluster A receives a telnet connection request and the other party 
> claims it is N2WQ-1
> 3/ Cluster A resolves the FQDN for N2WQ-1 to IP
> 4/ If the connection request from whoever claims to be N2WQ-1 
> originates from the resolved FQDN, the connection is accepted and 
> partner handshake sequence begins
> 5/ Otherwise Cluster A drops the connection.
>
> The FQDN acts like a shared key. It doesn’t need to be secret. Simple 
> and elegant.
>
-- 
VK2XAX : QF68KM : ITU59 : CQ30 : ORARC : WIA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.tobit.co.uk/pipermail/dxspider-support/attachments/20250312/77e02726/attachment.htm>