DNS in credentials

Question

DNS in credentials

ansuz opened this issue 8 years ago · comments

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 · Answer 1 · Tue Mar 22 2016 19:33:27 GMT+0800 (China Standard Time)

oops, duplicate of #23

ansuz · Answer 2 · Tue Mar 22 2016 19:34:24 GMT+0800 (China Standard Time)

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

Jakub Sztandera · Answer 3 · Fri Apr 22 2016 23:03:37 GMT+0800 (China Standard Time)

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.

ansuz · Answer 4 · Sun May 22 2016 17:45:20 GMT+0800 (China Standard Time)

Agreed.

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

ansuz · Answer 5 · Sun May 22 2016 17:51:19 GMT+0800 (China Standard Time)

Looks like all of @mixxit's nodes use DNS.

And these too:

And then if we could just update the readme to keep more from finding their way in:

ansuz · Answer 6 · Sun May 22 2016 17:51:58 GMT+0800 (China Standard Time)

ping @kyrias

Johannes Löthberg · Answer 7 · Sun May 22 2016 19:11:47 GMT+0800 (China Standard Time)

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

Johannes Löthberg · Answer 8 · Fri Jun 10 2016 16:05:18 GMT+0800 (China Standard Time)

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 · Answer 9 · Sun Jun 12 2016 18:03:34 GMT+0800 (China Standard Time)

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 · Answer 10 · Sun Jun 12 2016 18:05:30 GMT+0800 (China Standard Time)

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.

ansuz · Answer 11 · Sun Jun 12 2016 18:06:25 GMT+0800 (China Standard Time)

ping @mixxit @kaotisk-hund

Michael Bolland · Answer 12 · Sun Jun 12 2016 18:25:52 GMT+0800 (China Standard Time)

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 · Answer 13 · Sun Jun 12 2016 20:44:21 GMT+0800 (China Standard Time)

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 · Answer 14 · Sun Jun 12 2016 21:17:01 GMT+0800 (China Standard Time)

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

Michael Bolland · Answer 15 · Sun Jun 12 2016 23:44:17 GMT+0800 (China Standard Time)

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
.