Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Starting the beta and specifying a .io domain breaks resolution of any .io domains at all #219

Open
synic opened this issue Jan 23, 2017 · 6 comments
Labels

Comments

@synic
Copy link

synic commented Jan 23, 2017

Bug Reports

  • dlite version in use (run dlite --version):

dlite version 2.0.0-beta9

  • expected behavior:

dlite is accessible on a .io domain

  • actual behavior:

dlite is not accessible on a .io domain, and no .io domains can be resolved whatsoever

  • steps to reproduce

Specify a .io domain for the hostname, here is my config:

cpu: 2
disk: 20
dns: 192.168.64.1
docker: latest
extra: ""
hostname: ebdev.io
id: d3a0649d-e181-11e6-9f68-a0999b1068eb
memory: 3
route: true

This has happened before, I thought it was unrelated to dlite, however, I'm fairly sure it's dlite now. It has also happened to a coworker. Once you try to specify a .io domain, no .io domains will be resolvable (including the one you specified).

~]$ ping sentry.io
ping: cannot resolve sentry.io: Unknown host
[~]$ ping slither.io
ping: cannot resolve slither.io: Unknown host
[~]$

EDIT: It happens with .com domains too. Had to put github's IP in my /etc/hosts to make this post.

@synic
Copy link
Author

synic commented Jan 23, 2017

Had to read dlite's source to fix it. In cmd_setup.go, it mentions /etc/resolver

In that directory, there were three files, all with the same contents. com, io and docker:

[resolver]$ cat com
nameserver 127.0.0.1
port 1053

Removing all the files, I am able to resolve domains again.

@synic
Copy link
Author

synic commented Jan 23, 2017

Moving the resolve files to a more specific domain also fixes it

$ cd /etc/resolver
$ sudo mv io ebdev.io

@nlf
Copy link
Owner

nlf commented Jan 23, 2017

ahhh yes, this is a good point. i should probably make it clear when choosing a hostname that the tld portion should be invalid since its dns lookups will be hijacked

i wonder if there's an api somewhere that will let me determine if a tld is valid or not..

@ultiweb-zz
Copy link

ultiweb-zz commented Jan 23, 2017 via email

@synic
Copy link
Author

synic commented Jan 23, 2017

@nlf: perhaps if it IS valid, the entire domain should be used when creating the file.

This is something that the old dlite did not have a problem with

@nlf
Copy link
Owner

nlf commented Jan 23, 2017

the old dlite also wasn't able to resolve containers :) the reason i setup the resolver for the whole tld is because when container routing is enabled you can do lookups for <containername>.<tld>

@nlf nlf added the bug label Feb 15, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants