I know it’s been a long time since I rapped at ya. But I’m finally getting around to upgrading my ancient weak-sauce blog, And it’s got my mind all up in that long-form writing headspace, you catch my drift? And today I absolutely threw down on a simple fix for an issue that’d been stuck in my craw for about a year now.
So, here I am, droppin’ some keywords on ya and dumpin’ a log to hopefully, you know, offer some support to some other future frustrated dude as the DNS Gods harsh all over his mellow.
it was an IPv6 thing.
It should come as no surprise that I need me some consistent
/etc/hosts resolution coming back from:
- Google Chrome
- Node.js’s dns module
Chrome had never been an issue; it was bonafide. I could get around issues in
curl using –resolve, but that’s a pain in the ass. The real troublemakers were Firefox and
dns, the latter introducing a problem into webpack-dev-server. At least with Firefox I could do DNS Spoofing with Charles – until I needed to proxy WebSockets – but anything at the shell-level was a total no-go, bro.
I had an entry
192.168.99.100 vbox.redacted.com – yep, redacted.com – in my
/etc/hosts. Now, sometimes the name would resolve locally. And then suddenly, it wouldn’t … instead it’d resolve to an external IP. For a long periods of time. Firefox would seize up,
curl would start doing it’s pain-in-the-ass dance … I mean, it was a bad scene. We’re talking beyond dogs-and-cats-living-together territory. Meanwhile,
dig vbox.redacted.com would mock me by resolving properly. Every. Single. Time.
I mean, I figure mr. Foley’s gotta lay all this low-down on ya, just to clue you into how draggingly low-down it had gotten. In all desperation, I’d even gone so far as to set up dnsmasq and hack my
/etc/resolv.conf with ‘nameserver 127.0.0.1’ to try and get OS X to behave. But no dice. Turns out that the hostname resolved to an external IP because our ‘*.redacted.com’ wildcard entry got applied once the query got Forwarded upstream. So, yeah - hooray for us.
And the ‘long periods of time’ thing, that was clearly a DNS caching issue … Yet one that no amount of mdnsflushcache‘ing would resolve. I could sometimes get things to work by leaving this dreadful hack running in a shell:
watch -n 1 dig local.redacted.com
… but, that was a darker time.
Today Was Different
Because today I finally watched the
dnsmasq logs while I did
dns.lookup-style resolution from the shell with the help of atorstling/getaddrinfo. And I saw this:
dnsmasq: query[A] vbox.redacted.com from 127.0.0.1 dnsmasq: /etc/hosts vbox.redacted.com is 192.168.99.100 dnsmasq: query[AAAA] vbox.redacted.com from 127.0.0.1 dnsmasq: forwarded vbox.redacted.com to 126.96.36.199 dnsmasq: reply vbox.redacted.com is <CNAME> dnsmasq: reply sw33tj35u5.0MF6.us-east-1.elasticbeanstalk.com is NODATA-IPv6 dnsmasq: query[A] sw33tj35u5.0MF6.us-east-1.elasticbeanstalk.com from 127.0.0.1 dnsmasq: forwarded sw33tj35u5.0MF6.us-east-1.elasticbeanstalk.com to 188.8.131.52 dnsmasq: query[AAAA] sw33tj35u5.0MF6.us-east-1.elasticbeanstalk.com from 127.0.0.1 dnsmasq: forwarded sw33tj35u5.0MF6.us-east-1.elasticbeanstalk.com to 184.108.40.206 dnsmasq: reply sw33tj35u5.0MF6.us-east-1.elasticbeanstalk.com is 220.127.116.11 dnsmasq: reply sw33tj35u5.0MF6.us-east-1.elasticbeanstalk.com is 18.104.22.168 dnsmasq: reply sw33tj35u5.0MF6.us-east-1.elasticbeanstalk.com is NODATA-IPv6
“Hey, what’s this AAAA shit?” I asked myself. The Community patted me on the back and told me, “that’s IPv6”. So, might it be that my
/etc/hosts was only providing a trustworthy IPv4 mapping?
OMG, do you mean … I just have to …
Yes, You Just Have To
… fully round out the
# provide both IPv4 and IPv6 mappings 127.0.0.1 local.redacted.com ::1 local.redacted.com 192.168.99.100 vbox.redacted.com ::ffff:c0a8:6364 vbox.redacted.com
kill -HUP to dnsmasq, and … everything is suddenly right as rain. Firefox resolves like Chrome. My
Yes, today was truly different