hyperboria/peers

DNS in credentials

ansuz opened this issue · 15 comments

ansuz commented

DNS records in peering credentials are only resolved at launch time.

While they make it possible to provide a public node even if you have a dynamic IP address, this can make it difficult to debug peering problems when users encounter problems stemming from 'UNRESPONSIVE' peers.

Each time the IP being pointed to changes, nodes which are using those credentials will need to restart (or otherwise dynamically reconfigure their peering credentials). This is problematic when considering that the purpose of this repo was initially to provide a simplified means of gaining access to the network.

Thoughts?

ansuz commented

oops, duplicate of #23

ansuz commented

I propose better defining what we mean by 'preferring' IPs to Hostnames.

Kubuxu commented

After thinking some more about it, I really don't see any reason for DNS in creditentials.

DynDNS users shouldn't run cjdns for recieving connections either way, and for sure they shouldn't run public peer.

  • 👍1
ansuz commented

Agreed.

If more people 👍, maybe we can see about changing domains to IPs in the next while.

ansuz commented

ping @kyrias

kyrias commented

I'll do this soon. I'm currently moving though, so might take roughly a week.

  • ❤️1
kyrias commented

Sadly I've had to drop leeloo from being a public peer for now, because I don't currently have access to set up a port forward on the new network. The peer is still running though, so can do outgoing peering. Hopefully I'll be able to get it public again though.

ansuz commented

I wrote a test for this:

ansuz@box:~/code/hype/peers$ node tests.js 
The following peers are using DNS hostnames instead of IPs
[ { 'hk.hub.icfreedom.net:39119': 
     { contact: 'mixxit@hyperboria.name',
       password: '60dgptu2x8400qxnss5u1h9ld6h89p4',
       peerName: 'hk.hub.icfreedom.net',
       publicKey: 'b5rxqzvz1m8nbmx2473dgpxqgh7q0m7hu8fr1kxv40018zq1bwm0.k' } },
  { 'sg.hub.icfreedom.net:64221': 
     { contact: 'mixxit@hyperboria.name',
       password: '92tkn2fhkyx4p139v2320cs2d1407u0',
       peerName: 'sg.hub.icfreedom.net',
       publicKey: '265s36tzlnj26ctxbmk4zjdt6fn5xmn0lgtyurkrwgftc3uysgb0.k' } },
  { 'hub.icfreedom.net:64749': 
     { contact: 'mixxit@hyperboria.name',
       password: ')h.1-_[?bFW!0H:O{=a>H+9&17q]*j1~Bjzk{e.$',
       peerName: 'icfreedom.net',
       publicKey: 'ny90t66vzmfywtcs3rs8fwwhzfk7frgvdfxutqxslk18jrj82hx0.k' } },
  { 'play.fallofanempire.com:50005': 
     { contact: 'mixxit@hyperboria.name',
       password: 'LTRXc&UQ>YQOB=zNSWh{^HXf%|ha5r)A)R/IV!dT',
       peerName: 'play.fallofanempire.com',
       publicKey: '3c4q5wfvjm525gq0d0lmp1lh87dhm7llxhcyh2srhkjyrrmnxsm0.k' } },
  { 'rethymno-meshnet.tk:38295': 
     { contact: 'kaotisk@irc.fc00.io',
       login: 'default-login',
       password: 'wgs9k7n7j5yh0kx7kyl5m7cpp71ls4y',
       peerName: 'gr-rethymno-meshnet',
       publicKey: 'wb3pt76psbt28mt9t2wzyudyh9zkqwq9z3jqb3t06y53g6f5qzh0.k' } },
  { 'eu-east.hub.icfreedom.net:22992': 
     { contact: 'mixxit@hyperboria.name',
       password: 'g7575cd9p1f6cmubhy705b50f0qp95b',
       peerName: 'eu-east.hub.icfreedom.net',
       publicKey: '5xvkzx99t4x915x8xqzbsflvj3urpu48558wjc0613v97p377ks0.k' } },
  { 'ca.hub.icfreedom.net:25109': 
     { contact: 'mixxituk@gmail.com',
       password: '.!jjR[tyKF1ZO(J7mbf1=9!0jS^(~LUb#JPknsO,',
       publicKey: 'g0q7z39pnptj1r5src9jnpp5wuzl1rtg608gy5xmd4ulpg275520.k',
       user: 'ca.hub.icfreedom.net' } },
  { 'us-west.hub.icfreedom.net:56941': 
     { contact: 'mixxituk@gmail.com',
       password: '80b8cqnbfy560f9mh8g3dqkh17gwp6g',
       publicKey: 'wjzupkw8h2n20krbf887zyhu107j1dsz8m34rfbb9z10063ym2t0.k',
       user: 'us-west.hub.icfreedom.net' } } ]
ansuz commented

these should be easy enough to fix, even programatically by resolving the domains and rewriting the files.

The only question is whether these are using domains because their IPs are dynamic. That would be problematic.

mixxit commented

Why can't we use DNS?

On Sun, 12 Jun 2016 11:06 ansuz, notifications@github.com wrote:

ping @mixxit https://github.com/mixxit @kaotisk-hund
https://github.com/kaotisk-hund

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#50 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AAOPR6GqT-gWf_New0n9TxMWtR4Fs5nNks5qK9ojgaJpZM4H2AaL
.

ansuz commented

As I understand it, DNS hosts are resolved at launch time, before seccomp is set up. After seccomp is active, DNS resolution is forbidden.

If somebody were to programatically drop and reset their peers at runtime (with peers that depend on DNS) then seccomp would crash the cjdns process.

Granted, this only affects linux clients that have compiled with seccomp, and people have the choice of resolving the domain and keeping the IP in their version of the credentials, so there are workarounds.

DNS might be useful if a node has a dynamic IP, but again, given that domains are only resolved at launch time, such peers are not ideal for this repository. We'd like to minimize the amount of things that can go wrong when configuring a node using public peers, and DNS is just another moving part that can cause problems.

Deleted user commented

If somebody were to programatically drop and reset their peers at runtime (with peers that depend on DNS) then seccomp would crash the cjdns process.

DNS resolution must be part of the external drop-and-reset-peers script then:

> dig +short transitiontech.ca
104.200.29.163
mixxit commented

OK well all my nodes are static except one that I had moved to a new
provider which was why DNS was useful as its static IP changed

On Sun, 12 Jun 2016 14:17 Lars Gierth, notifications@github.com wrote:

If somebody were to programatically drop and reset their peers at runtime
(with peers that depend on DNS) then seccomp would crash the cjdns process.

DNS resolution must be part of the external drop-and-reset-peers script
then:

dig +short transitiontech.ca
104.200.29.163

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#50 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AAOPR-xl50pZ0FA_B8x00lep41pXCMZLks5qLAbNgaJpZM4H2AaL
.