Jormungandr: Trusted peers should accept DNS name

[disassembler]

Is your feature request related to a problem/context ? Please describe if applicable.
We define the rendezvous nodes in a DNS round robin this way we can change/scale the IP's in the DNS round robin
Describe the solution you'd like
Allow DNS names in trusted peers.

Additional context

[mzabaluev]

It's possible to encode DNS in multiaddr, so at the very least we need to extract the DNS components and make the HTTP service URL out of them, relying on the resolver in H2 (which can further be customized if necessary).

[NicolasDP]

this could be done easily in the CLI by adding support to enter multiaddr but with a FQDN instead of the associated ip.

the multiaddr addr format first entry needs to be enforced:

i.e.:

• /ip4/example.com/tcp/8080 still need to only resolve into ip4 (A) : /ip4/192.168.0.1/tcp/8080
• same thing for ip6 (AAAA only)

Also if a query returns multiple entries, we need to resolve into that multiple entries:

sh$ dig iohk.io
iohk.io.        300 IN  A   104.24.29.11
iohk.io.        300 IN  A   104.24.28.11

so if one enters in the trusted peer list /ip4/iohk.io/tcp/9999 we expect this to resolve into a list of the following: /ip4/104.24.29.11/tcp/9999 and /ip4/104.24.28.11/tcp/9999

_EDIT: adding more details_:

Currently we are taking the value from here: https://github.com/input-output-hk/jormungandr/blob/8bf37dba8e0d230897386ed5b5caec8a253155e2/jormungandr/src/settings/start/network.rs#L57

Instead we need to add a new type TrustedPeer that is either a valid poldercast::Address or a valid Multiaddress style format but instead but with an FQDN as described above.

[NicolasDP]

one could use the standard library value:

https://doc.rust-lang.org/stable/std/net/trait.ToSocketAddrs.html

[onicrom]

I'm not a huge fan of this. It requires more trust in at least 1 or 2 third parties (owner of the TLD and owner of the nameservers hosting the domain) -- it also assumes those 2 entities are not attacked. Not to mention increasing complexity of the node.

[mark-stopka]

@onicrom, there is trust established in DNS thru DNSSEC, in a near future we can also expect new DNS services built on top of a distributed ledgers...

Also, support for DNS FQDN resolution does not force users to use it...

[onicrom]

DNSSEC adoption has been SUPER slow: https://stats.labs.apnic.net/dnssec
Currently this list of TLDs do NOT support DNSSSEC:
.africa, .ai, .ar.com, .berlin, .ch, .cm, .com.au, .com.cn, .com.es, .com.pe, .de, .desi, .es, .eu, .fr, .gb.com, .gg, .hamburg, .help, .hiphop, .hosting, .how, .it, .kr.com, .li, .ltda, .lol, .mom, .net.au, .net.cn, .net.pe, .nl, .no.com, .nom.es, .nu, .ooo, .org.au, .org.cn, org.es, .org.pe, .paris, .pe, .physio, .protection, .property, .qc.com, .sg, .ski, .soy, .sucks, .tattoo, .to, .uy.com, .voting, .whoswho.

I would guess DNS on/through DLT is not near at all. Look how long ipv6 took to roll out, and how long adoption is taking.

Don't forget all those users who might not own domains or static addresses and rely on a third-party services like dyndns.

WRT to not forcing users... I find that most people would tend to go the simpler route. If they aren't educated about the risks of DNS services not managed by them or secured with things like DNSSEC, then that's a bad thing.

[mzabaluev]

I think DNS resolution of trusted peer names needs to be done as a practical matter. Node operators should not be forced to deal with lists of IPv4 and IPv6 addresses. FQDNs of trusted node providers are much easier to manage and verify. Trust issues should be resolved with DNSSEC (supposing the resolver can eventually validate) and choosing which node providers to contact using the domain names they control.

[JamesRobertKelley]

What about depreciating the "trusted_peers" config in favor of a "trusted_dns_domains" option?
Here's how it would work:
"trust_dns_domains": ["iohk.io", "emurgo.io", "cardano.org", "volunteer-pool-operator.com"]

A DNS TXT record named after the genesis block would be hosted on each domain. The genesis hash is 64 bytes long and the maximum label is 63, which is unfortunate, but it could be written like this (using the ITN hash of 8e4d2a343f3dcf9330ad9035b3e8d168e6728904262f2c434a4f8f934ec7b676 as an example):

_8e4d2a343f3dcf9330ad9035b3e8d168e6728904262f2c434a4f8f934ec7b6.iohk.io. 5 IN TXT "76 tn1.iohk.io/tcp/3000 /ip4/52.9.132.248/tcp/3000 /ip4/52.8.15.52/tcp/3000 /ip4/13.114.196.228/tcp/3000 /ip4/13.112.181.42/tcp/3000 /ip4/3.125.75.156/tcp/3000 /ip4/52.28.91.178/tcp/3000 /ip4/3.124.116.145/tcp/3000"

• The node-config.yaml only needs domain names trusted by the pool operator.
• This TXT record expires after 5 seconds, allowing it to be changed quickly.
• DNS is a very efficient way to distribute this type of information.
• It lists all of the currently configured trusted nodes with an example of a DNS named node.
• Allowing a DNS named node will give clients the option to ask for an A or AAA record for IPv4 or IPv6, so the IP protocol version does not need to be specified.
• DNS named nodes can also take advantage of DNS Round Robin and geographic distribution features of DNS servers.
• The first two characters of the string hold the last two of the genesis hash because DNS labels are limited to 63 characters. This is the only awkward part..

The description above does not include the IDs of the trusted nodes but I saw somewhere else that there is an intention to eliminate the ID requirement. If the IDs are required, they can be specified in the TXT record but it may require additional strings to fit within the 254 character limit.

[mark-stopka]

@JamesRobertKelley SRV records are designed to handle this type of use-cases.

[JamesRobertKelley]

I thought of SRV records but they aren't ideal if you are requesting a specific Genesis Hash.
On the other hand, if Jormungander can get a list of peers that have a specific Genesis Hash via a Distributed Hash Table, then SRV records would be more simple.

Either way, I believe DNS is a better way to bootstrap (and also maybe storing a cache of peers between reloads) than adding the IPs to a config file.

[mark-stopka]

@JamesRobertKelley you would create a SRV record which would at the tip of the FQDN have the genesis hash specified, then the node would look for SRV records with that genesis hash under the specified domain root.

[JamesRobertKelley]

The only problem with that is the 63 char limit for each DNS label, the genesis hash is too long by one char! With the SRV record you could just go with:

_jormungandr._tcp.iohk.io. 5 IN SRV 10 60 3000 bootstrap.iohk.io.

... and other entries for backup servers, but there isn't any room for the genesis hash.
If there is a protocol for a DHT where it asks the peers, "Who has genesis hash xxx?" then that would work out well.

[mark-stopka]

@JamesRobertKelley the character limit you're describing applies only to DNS resolvers which do not support DNSSEC, which are not the kind of resolvers you'd like to use anyway. Also it's a limit for A and AAAA records, not for all other types of records. Please refer to the relevant RFC 2782 for more details.

[JamesRobertKelley]

I strongly favor your idea of using SRV records if the client is requesting a Distributed Hash Table, but
I do not believe SRV records may be used with the genesis hash prepended.

Just in case I misunderstood what you are saying, here is how I understood your comment:

I understood you as suggesting that the genesis hash could be in the FQDN of the SRV record. For example:

_8e4d2a343f3dcf9330ad9035b3e8d168e6728904262f2c434a4f8f934ec7b676._tcp.iohk.io.

The specification says that the service should lead with an underscore, and it is the "_symbolic name of the desired service_." For example, _ldap or _sip. I guess you could argue that the genesis hash is the service but it would better conform to the standard if it were:

_jormungandr._tcp.iohk.io. or _jormungandr._udp.iohk.io. if the protocol is UDP based.

Additionally, using _jormungandr allows the responding server to service ANY genesis hash from Production or Testnet.

A request for that SRV record would return the records that include a _priority_, _weight_, _location_, and _port_ for each _jormungandr resource record.

To quote from the RFC you mentioned:

    Here is the format of the SRV RR, whose DNS type code is 33:
      _Service._Proto.Name TTL Class SRV Priority Weight Port Target

The RFC also states:

    Note that where this document refers to "address records", it means A
    RR's, AAAA RR's, or their most modern equivalent.

It also references RFC 2181 saying:

    If a truncated response comes back from an SRV query, the rules
    described in [RFC 2181] shall apply.

The relevant section of RFC 2181 is section 11 "Name syntax" which states:

     The DNS itself places only one restriction on the particular labels
     that can be used to identify resource records.  That one restriction
     relates to the length of the label and the full name.  **The length of
     any one **label is limited to between 1 and 63 octets**.  A full domain
     name is limited to 255 octets (including the separators)**.

I don't see anything in the DNSSEC specifications that indicate the 63 octet limit was removed. When Googling I see this statement in a Cisco DNSSEC paper:

    Each domain name is composed of one or more labels.
    Labels are separated with a "." character and may **contain a maximum of 63 characters**.
    A FQDN may contain a maximum of 255 characters, including the "." character.

In my opinion, using SRV records will be superior if Jörmungandr requests a DHT from the hosts returned in the SRV request results because no DNS changes are needed to introduce a new testnet. If there was no will or time to create that new service to share a Distributed Hash Table, the DNS TXT records could be a reasonable alternative because it allows for an arbitrary payload to be returned.