Yosemite localhost resolver and dnsmasq fails offline - osx-yosemite

Setup my local dev environment similar to this post and everything was working fine but recently I am unable to access my local dev domains when I am offline. When I am connected to the internet it works fine. I'm wondering if something changed with how resolver is used in Yosemite. It seems as if resolver rules are ignored if I'm offline.
dnsmasq.conf:
address=/.dev/127.0.0.1
listen-address=127.0.0.1
/etc/resolver/dev
nameserver 127.0.0.1
When online:
ping -c 1 mydomain.dev
PING mydomain.dev (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.038 ms
--- mydomain.dev ping statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.038/0.038/0.038/0.000 ms
scutil --dns
resolver #1
search domain[0] : nomadix.com
nameserver[0] : 203.124.230.12
nameserver[1] : 202.54.157.36
if_index : 4 (en0)
flags : Request A records
reach : Reachable
resolver #2
domain : dev
nameserver[0] : 127.0.0.1
flags : Request A records, Request AAAA records
reach : Reachable,Local Address
when offline:
ping -c 1 mydomain.dev
ping: cannot resolve mydomain.dev: Unknown host
scutil --dns
No DNS configuration available

OSX Yosemite + resolver + dnsmasq offline === resolved !!
when you're offline every interface on your computer, but 127.0.0.1, goes down.
so if you want to have a dns resolution your dns server have to listen to 127.0.0.1. In my case it's dnsmasq I choose because you don't have to be a sys admin to make it work, and it does !
following those simple steps I got it working:
1) brew install dnsmasq
2) cp /usr/local/opt/dnsmasq/dnsmasq.conf.example /usr/local/etc/dnsmasq.conf
if like me it's not properly installed in /usr/local/opt you should be able to read in the brew installation debug lines something like this :
make install PREFIX=/usr/local/Cellar/dnsmasq/2.72
in this case run the following command:
ln -s /usr/local/Cellar/dnsmasq/2.72 /usr/local/opt/dnsmasq
and then back to step 2
3) vi /usr/local/etc/dnsmasq.conf
and add your domains like this for exemple:
address=/foo.dev/192.168.56.101
where in that case every url ending with foo.dev (http://www.foo.dev, http://foo.dev, http://what.ever.you.want.foo.dev, etc...) will be resolved as 192.168.56.101 (this is the kind of ip you have using Virtualbox, 192.168.56.*)
4) sudo launchctl load /Library/LaunchDaemons/homebrew.mxcl.dnsmasq.plist
5) try it before putting it into the resolver
nslookup foo.dev 127.0.0.1
and expect this :
Server: 127.0.0.1
Address: 127.0.0.1#53
Name: foo.dev
Address: 192.168.56.101
6) mkdir -p /etc/resolver
vi /etc/resolver/dev
add those two lines :
nameserver 127.0.0.1
search_order 1
7) ping foo.dev or hint http://foo.dev or http://so.cool.foo.dev in your browser address bar and you're good to go !!!
8) Be happy !! You can work offline AGAIN !!!!

I've been checking this question for months hoping for an answer. I believe this will help when 10.10.4 drops: http://arstechnica.com/apple/2015/05/new-os-x-beta-dumps-discoveryd-restores-mdnsresponder-to-fix-dns-bugs/
Apple are replacing discoveryd with mDNSresponder (like it used to be)

The problem is when you are offline you should specify a resolver for the root domain '.':
When we search for www.google.com
There is a "." (root domain) added automatically at the end like: www.google.com.
So all you have to do is :
Set all your network interface dns servers to 127.0.0.1:
networksetup -setdnsservers Ethernet 127.0.0.1
networksetup -setdnsservers Wi-Fi 127.0.0.1
...
Create a file /etc/resolver/whatever:
nameserver 127.0.0.1
domain .
See this question for more details

Related

XAMPP 7.2.8-0 Mac Apache web server update/install won't start anymore

I am running MacOS Sierra Version 10.12.6 and I have just tried to upgrade to the latest version of XAMPP on localhost.
I have just upgraded from XAMPP 7.1.10 to 7.2.8-0 by performing an install of the xampp-osx-7.2.8-0-installer.dmg file.
It appears now that I am getting a conflict between AVAST running on port 80
The system was working before running both AVAST and XAMPP 7.1.10 I assume on the default port of 80 but I did not check before the upgrade to 7.2.8
Disabling the AVAST Shields still resulted in processes on port 80
colins-iMac:phpmyadmin colinhart$ sudo lsof -i :80
Password:
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
com.avast 29044 root 46u IPv4 0xf605aed3cc5db167 0t0 TCP colins-imac:61319->host213-123-242-66.in-addr.btopenworld.com:http (ESTABLISHED)
com.avast 29044 root 57u IPv4 0xf605aed3d4de9a5f 0t0 TCP colins-imac:61274->64.95.190.66:http (ESTA
and XAMPP also running on Port 80 by default, I have tried changing the port for XAMPP to an available one 80+ to no avail
I am desperate to get this working now as I am unable to develop, so any help would be much appreciated.
I will continue trying to fix the problem by reviewing answers to similar queries.
UPDATE I uninstalled AVAST and installed AVIRA, and yet the Apache Web server still stops soon after Starting
Thanks
Colin
The resolution to the problem having tried virtually all suggestions given by previous answers on this site, was to change the /etc/hosts file as suggested in this response
Unable to start XAMPP Apache server on MacOS-Sierra
To solve this :
Executed following command
sudo -e /etc/hosts
Then, changed following entries
127.0.0.1 localhost
::1 localhost
to
127.0.0.1 localhost MacBook-Pro.local
::1 localhost MacBook-Pro.local
where MacBook-Pro.local is the name returned by hostname command in terminal session
colins-iMac:~ colinhart$ hostname
colins-iMac
colins-iMac:~ colinhart$
in my case the name should be colins-iMac
Many Thanks
Colin
Deleting the lib folder from XAMPP files and reinstalling worked for me
Check this SOF answer

Force docker-machine to specific IP using Hyper-V, network unreachable

I have found a partial answer to this question, and it is successfully setting the machine at the desired IP address. But the network is unreachable from inside a docker-machine created with the Hyper-V driver.
The TLDR on the answer above is to create a script, /var/lib/boot2docker/bootsync.sh:
sudo cat /var/run/udhcpc.eth0.pid | xargs sudo kill
sudo ifconfig eth0 192.168.XXX.YYY netmask 255.255.255.0 broadcast 192.168.XXX.255 up
Once I make the script, I restart the machine.
When I restart the machine, the IP is set to my desired address (expected). I can remote in at the address, so it is at least available through the host. But when I test for connections, there is no connection to the internet (unexpected).
Boot2Docker version 17.05.0-ce, build HEAD : 5ed2840 - Fri May 5 21:04:09 UTC 2017
Docker version 17.05.0-ce, build 89658be
docker#machine:~$ docker pull ubuntu
Using default tag: latest
Error response from daemon: Get https://registry-1.docker.io/v2/: dial tcp: lookup registry-1.docker.io on [::1]:53: read udp [::1]:48331->[::1]:53: read: connection refused
docker#machine:~$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
ping: sendto: Network is unreachable
If I remove the script and restart again, I am reassigned a new/random IP address (expected), remote in at that new IP address, and can do network connections (expected):
docker#pm:~$ docker pull ubuntu
Using default tag: latest
latest: Pulling from library/ubuntu
aafe6b5e13de: Pull complete
0a2b43a72660: Pull complete
18bdd1e546d2: Pull complete
8198342c3e05: Pull complete
f56970a44fd4: Pull complete
Digest: sha256:f3a61450ae43896c4332bda5e78b453f4a93179045f20c8181043b26b5e79028
Status: Downloaded newer image for ubuntu:latest
docker#pm:~$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=43 time=18.424 ms
64 bytes from 8.8.8.8: seq=1 ttl=43 time=27.638 ms
The accepted answer has several up votes, but it reads like this is a confirmed work around on VirtualBox. Not sure what about Hyper-V would be causing the IP assignment to cut off internet access.
I had the same problem, and I solved it by adding the following to the end of bootsync.sh:
route add default gw <address>
There was no default route to the gateway or the internet, so it must be set manually.

Minishift: Could not resolve: *.192.168.64.2.nip.io

I have installed minishift on OSX with brew:
brew cask install minishift-beta
...
$ minishift version
Minishift version: 1.0.0
I have sucessfuly started minishift, and created node-ex example application and exported it:
$ oc get route
NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD
nodejs-ex nodejs-ex-myproject.192.168.64.2.nip.io nodejs-ex 8080-tcp None
However I can not reach .192.168.64.2.nip.io:
$ curl nodejs-ex-myproject.192.168.64.2.nip.io
curl: (6) Could not resolve host: nodejs-ex-myproject.192.168.64.2.nip.io
$ dig +short nodejs-ex-myproject.192.168.64.2.nip.io
$
All is working with minishift web console and oc command, but I can not reach the application domain.
Thank you #enj. The explanation at http://nip.io is clear about how it works.
I have seen that queries to 8.8.8.8 and to my ISP DNS are resolved to my private IP. But it is my router (my primary DNS) which do respond nip.io
My router run DD-WRT and has enabled
Rebind protection Discard upstream RFC1918 responses
then I add nip.io at
Domain whitelist nip.io
and now I resolve queries:
≻ dig +short test.10.0.0.1.nip.io
10.0.0.1
Is something on your machine or network blocking DNS queries to nip.io?
When playing with Minishift at home, where I am connected to the internet via Deutsche Telekom's VDSL and Speedport-Router, I cannot resolve these xip.io or nip.io addresses.
My workaround is to put 8.8.8.8 into /etc/resolv.conf
I had the same issue on Windows 10. My workaround was to add an entry in C:\Windows\System32\drivers\etc\hosts file. Here is an example
192.160.90.101 nodejs-ex-nodejs-echo.192.160.90.101.nip.io # needed for minishift to work

ssh resolves -p 1234 hostname=“localhost” but does not resolve hostname=“localhost:1234”

I upgraded to Fedora 20 a few weeks back. I had very few issues in the upgrade process and the system is stable. One lingering issue I have is described below.
I have one computer on my LAN with a reverse port forward set up back to the recently updated fedora 20 machine. I can verify the reverse forward works because the following is successful from the fedora 20 computer:
$ ssh -p 1234 xxxxx#localhost
xxxxxx#localhost's password:
Last login: Mon Dec 1 14:08:22 2014 from localhost.localdomain
However if I specify the port number after localhost I get a “could not resolve” error as shown below:
$ ssh -v xxxxx#localhost:1234
OpenSSH_6.4, OpenSSL 1.0.1e-fips 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 51: Applying options for *
ssh: Could not resolve hostname localhost:1234: Name or service not known
So in the first situation it sees hostname=localhost and resolves that to an IP address. In the second situation it sees hostname=”localhost:1234:” ...
The contents of /etc/host is :
127.0.0.1 localhost.localdomain localhost
::1 localhost6.localdomain6 localhost6
Right now I'm trying to determine if this is a resolving thing or something else. a "dig localhost" doesn't return an answer section so that suggest it is. At the same time localhost:port# works in a browser. I don't know how localhost is resolved from /etc/hosts, I assume NetworkManager does this? I'm not running any sort of internal DNS server on my LAN.
I'm happy to provide additional information if requested & thanks in advance
You have to use the -p option to specify a port with SSH, not the hostname:port format.
ssh -v xxxxx#localhost -p 1234
$ ssh -v xxxxx#localhost:1234
ssh: Could not resolve hostname localhost:1234: Name or service not known
"user#host:port" or "host:port" simply aren't valid syntax for specifying a destination on the ssh command line. ssh treats everything after the "#" as a hostname. It doesn't treat part of that field as a port number, and it's not documented to do so.
The specific error indicates that ssh is trying to look up the IP address for a nonexistent host named "localhost:1234" and failing.

FATAL: no pg_hba.conf entry for host "fe80::1%lo0"

Can someone help me why this is happening when I'm trying to connect to database or rails s?
In my pg_hba.conf file I have this:
# TYPE DATABASE USER ADDRESS METHOD
# "local" is for Unix domain socket connections only
local all all trust
# IPv4 local connections:
host all all 127.0.0.1/32 trust
# IPv6 local connections:
host all all ::1/128 trust
# Allow replication connections from localhost, by a user with the
# replication privilege.
#local replication Andrew trust
#host replication Andrew 127.0.0.1/32 trust
#host replication Andrew ::1/128 trust
local all all md5
Maybe I'm doing it wrong?
Thanks
I had the same problem. somehow, this line was added to my /etc/hosts file:
fe80::1%lo0 localhost
commenting out or removing that line from /etc/hosts should fix it
sudo vi /etc/hosts
#fe80::1%lo0 localhost
I'm on OSX 10.9.3 and Postgres 9.3.4.
I've managed to resolve this problem in the following way:
First find your pg_hba.conf file by starting up psql with psql -h 127.0.0.1 and executing SHOW hba_file;:
hba_file
-------------------------------------
/usr/local/var/postgres/pg_hba.conf
(1 row)
Now add the following line to pg_hba.conf:
host all all fe80::1%lo0/128 trust
and reload the configuration via select pg_reload_conf(); within psql.
Now you should be able to connect via psql -h fe80::1%lo0.
Oo, that's an interesting one.
Assuming you're connecting to localhost (you didn't say and didn't show your database.yml), it appears that localhost is resolving to an IPv6 link-local address with zone index.
If you use ::1 or 127.0.0.1 it should work.
This is very likely an operating system misconfiguration or bug, so lots more detail (see comment above) should be added to the question if you want any concrete advice on that.
For me, the cause was calling sudo rails server -p 80.
I bound the rails server to port 80 so that I wouldn't have to specify a port in the url localhost:3000 during development. This appears to write fe80::1%lo0»localhost to my /etc/hosts file.
Try commenting out the line in your hosts file, then running rails s -p 3000
Actually,
The same error occurs for me when I execute pg_dump command to take backup of my server database (external) like below
'/Applications/Postgres.app/Contents/Versions/9.3/bin'/pg_dump -d "<database_name>" -h <server_name> -U <db_user_name> -f <destination_path>
I solved it (work around) by replacing my <server_name> to my actual server IP (10.1.0.18).
So the issue here is my system didn't understand the <server_name> host.
It might solve permanently when you add <server_name> host in /private/etc/hosts file.
Another variant: if IPv6 is not used in the network, you can just disable it. On Windows IPv6 service also can be disabled.