Distribution of Device ID using DNS TXT record

Development
1

The Device ID doesn’t say anything, why should we not use the distributed DNS system (with own DNS servers) to have a discosrv coupled with the strength of internet caching. I had an idea

  • TXT record

    • Prefix with st
    • ID of property
      • 0: <Device ID (63 char string)>
      • 1: <Device ID (63 char string)>

  • Server/NAS record

    • nas.xor-gate.org. 86205 IN TXT "st 0 PLO5DGO-VYXVWJY-4IE3JAB-7UDLNBH-BG4PKZA-FA4F2ML-GQVASQM-APPL3QG"

  • User instance on a system could become: jerry@nas.xor-gate.org resolves uses the record:

    • jerry.nas.xor-gate.org. 86205 IN TXT "st 1 jerry PLO5DGO-VYXVWJY-4IE3JAB-7UDLNBH-BG4PKZA-AB4F2ML-GQVASQM-APPL3QG"

This is just a idea with rough edges to share with you all.

1 Like
2

I’m not sure I understand the point? This is a way of discovering the device ID for someone associated with a domain, so someone can bombard you with “Accept this device” requests? However they won’t know any of your folder IDs, so it’s not enough to actually share anything?

3

What if you’re behind corporate DNS servers that do not answer to TXT queries?

The value add here is that you don’t need to memorise IDs? How often do you need to add a device? You could just have a TXT record you can dig whenever you forget it that returns you the ID.

4

This is a neat idea. Suspect complicated to implement but really good idea on individual basis.

Had device ID’s in a spreadsheet but this may be better way to store.

5

How many users actually have the capability to create txt records?

The idea itself is not bad, but it’s probably easier to add some sort of name aliasing and a sense of ownership into the vanilla discovery than to ask people to use DNS.

6

@AudriusButkevicius I totaly agree on your points. I have seen public internet in a train which won’t relay any SSHFP records. Syncthing is great, it should not become a “dropbox” replacement but current user-base are mostly tech people. Security and user-friendlyness are choices but I like the idea just to use an easy to remember alias (e.g name@domain) with my Device ID. This can also be implemented in a more advanced discovery with trusted/signed chains of key-values with the device id public part of the cert (e.g DHT).

It is indeed true people can DDOS on your syncthing instance because brute force on aliases (e.g with a domain) is easier than DDOS on the list of all possible device ids.

7

Regardless of feasibility or useability give credit for innovative use of txt records.

8

Something similar was proposed before, albeit different and more advanced, using SRV or even A records and DNSSEC for signing/verifying advertisements etc.

9

The only thing I can find on the forum is this post of you @AudriusButkevicius Future protocol & discovery changes

10

It was in the old syncthing/discovery repo.

11

You could punch through corporate firewalls DNS over HTTPS (or DNS over TLS) which is fairly new concept: https://en.wikipedia.org/wiki/DNS_over_HTTPS.

12

So you had actual DNS server code in place? I was playing around with CoreDNS which seems fairly nice with a pluggable (compile-type) DNS system.

13

I had a thing written using miekg/dns, but I hit fragmentation issues, but that was for a different problem. Dns over https is essentially what we have now, just our addresses are device ids.

1 Like
14

I could see a point in being able to add a device as either device ID or address (DNS or IP). If an address was entered you’d get to confirm/accept the device ID on first connect. Potentially in that case a TXT or SRV record could point out the correct device ID and you could skip the confirmation step.

15

In the case you want to add devices based on their “(pseudo)mail adres” we should hash with salt e.g {SSHA256} to prevent pushing semi-private information in public registries like DNS. Just like ssh known_hosts is able to be hashed for leaking hostnames.