OS X DNS cache reset script | Hacker News Reader

OS X DNS cache reset script

github.com

125 pointsmiketheman84 comments

In 10.10 Apple replaced the then 12-year-old mDNSResponder, which does DNS (apart from other things) with "discoveryd", which had issues so they reverted the change.

http://arstechnica.com/apple/2015/01/why-dns-in-os-x-10-10-i...

http://arstechnica.com/apple/2015/05/new-os-x-beta-dumps-dis...

https://support.apple.com/en-us/HT202516

Do you remember when it JUST FUCKING WORKED before 10.6?

Yes. I think it changed because they introduced Airdrop.

Ugh - Airdrop which you have to disable in any decently dense Wifi environment

If I want a video call to work properly I have to:

  sudo ifconfig awdl0 down

Hmm? As far as I know it's not "on" until you open an Airdrop window in Finder.

Don't let sense get in the way of cargo cult.

What a worthless link. How about an explanation of the problem? Stop what? Not resetting? Why is a reset necessary? And why the double-negative? Why not "noreallyjustfuckingresetitalready"?

I don't understand

Exactly. And the author doesn't bother to explain.

The author didn't care and it's not their day job to explain.

They just put it out there, which is more than other people did.

If someone feels it needs an added explanation, they can add it themselves.

Some, who had faced similar issue at some time or another, will understand immediately what this is, anyway.

Well if you had ran into that problem the link would be very touching to you too. The stop is referring to the constant changing and difficulty in diagnosing resolution under os x (or whatever it's called)

Maybe, except the author doesn't clarify what exactly the problem is, or that s/he's offering a solution. A solution is only viable if it's both discoverable and understandable.

OS X has like 4 commands to flush the DNS cache depending on version. It's a PITA. This script runs the right thing on each.

Even more reason to clarify.

Too bad they didn't address the DNS problem in the Keynote. This is a bit of an exaggeration, but I do feel I've spun mDNSResponder more often than using their Messages app.

That's not a positive feeling. Especially if you're with a client and your browser stops resolving and your client is watching you open up terminal to spin mDNSResponder

Could someone add some context please? I see that apparently the method to flush the DNS cache changes between versions. Is there a deeper reason why this is necessary?

I'm not sure. The `dscacheutil -flushcache` command he lists for Snow Leopard still works for me (OS X Yosemite here).

And it still works for me on macOS 10.12.

So I see absolutely no point here.

The command doesn't fail but does it actually flush the DNS cache, or does it flush the Directory Cache which isn't used for DNS anymore (or possibly at all, on my El Cap machine flushing succeeds but any query of the cache content or its statistics replies "Unable to get details from the cache node")

The command did flush the Directory Service cache, but DNS is no longer part of it. You can still use its query command though.

    dscacheutil -q host -a name www.example.com

On the topic, easiest way to see if dscacheutil -flushcache work or not is to probably do something like:

    dscacheutil -q host -a name www.example.com
    # Make sure it's in the cache prior to running.
    
    sudo dscacheutil -flushcache
    dscacheutil -q host -a name www.example.com
    # Notice if there's a slight delay for the lookup.
    
    sudo killall -HUP mDNSResponder
    dscacheutil -q host -a name www.example.com
    # Notice if there's a slight delay for the lookup.

"macOS" has a tendency to cache stale DNS. But over the years they have changed the commands to flush the cache, so you end up googling how to clear the cache, checking your version of osx, and pray to the DNS gods that it will work this time.

Basically:

* Snow Leopard and earlier use lookupd for DNS resolving (`dscacheutil -flushcache`)

* Since Lion, they switched from lookupd to mDNSResponder, presumably for Bonjour protocol support (`killall -HUP mDNSResponder`)

* Yosemite switched to discoveryd that basically is a rewrite of mDNSResponder (`discoveryutil mdnsflushcache`)

* Due to a lot of problems with discoveryd, they switched from discoveryd back to mDNSResponder since v10.10.4 (so we're back to `killall HUP mDNSResponder`)

https://support.apple.com/en-us/HT202516

What's the context of this?

The process seems to change every version of OS X for some reason. So basically this script runs the appropriate command for whichever version you are using.

I've personally found myself Googling it at least once for each version.

It gets more annoying if you want to explain it to a non-technical OS X user. Maybe this little repo will help them converge on a command alias for the future

The content is that it's tricky to truly flush the DNS cache on OS X and the command to do it gets changed a lot with new releases. It's very annoying because it makes working with DNS very painful.

Any time I need to flush dns cache, I simply google "flush dns cache mac" and top result shows you the simply command to run: https://support.apple.com/en-us/HT202516

Having a simple command such as "reset dnscache" or something of course would be nice, but since it can already be done in a matter of seconds with a quick google I can't imagine it's that much of concern for apple of many developers compared to other issues.

What if ping was different on every build of linux. Shit gets old.

I guess that's really handy if your dns cache doesn't include a poisoned record for Google. Otherwise it's useless.

I'd just do

  dscacheutil -flushcache || \
  discoveryutil mdnsflushcache || \
  killall -HUP mDNSResponder

SO MUCH TYPING

aliases are your friend

aliases make you week

But they help you avoid typos such as "week".

alias d='dscacheutil -flushcache || discoveryutil mdnsflushcache || killall -HUP mDNSResponder'

alias dns_flush="dscacheutil -flushcache &> /dev/null ; discoveryutil mdnsflushcache &> /dev/null ; killall -HUP mDNSResponder &> /dev/null ; true"

Just copy/paste it from the internet.

Nothing bad could possibly happen. [1]

[1]: http://thejh.net/misc/website-terminal-copy-paste

You might be interrested in an unreleased security tool I've been working on

Install with

curl http://issh.it/yadummy | sh

How is that any different than installing any opaque binary app?

It all comes downs to whether you trust the source.

At least with the "curl http://xxx | sh" method you can also examine the contents of the script before running it, and even opt to run it after downloading it and checking it locally.

With binary apps off of internet sites, which is what people install and use dozens of times a month, no such luck.

In this case, you have no idea if the connection is MITM'd because of http. You must assume the source untrustworthy, because you don't know who it is. Additionally, assuming the page's source (from which you copy this command) is over http, you must assume the website has compromised (e.g.) your clipboard on copy and you're pasting in malicious unicode characters or whatever. People should have an inherent distrust of binary blobs, too, for whatever that's worth. Same caveats over serving the download over http, with the added benefit of not being able to read the source (necessarily), with the added bonus of now having to assume the build machine has not been compromised.

>People should have an inherent distrust of binary blobs, too, for whatever that's worth.

All you said are true for binary blobs as well. The page could be MITM, etc.

"curl xxx | sh" style deployment has all the same disadvantages of binary blogs, but has the added advantage that you can download and check the code before executing it.

https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b...

In short, `curl https://www.example.org/foo.sh` and `curl https://www.example.org/foo.sh | sh` can do different things :(

Could OSX just have a way to disable negative caching completely? All it does is troll me when I'm on bad wifi and the DNS lookup for www.google.com gets dropped and that negative response is cached. Can we just stop doing that?

I can't recall the last time I had a positive cache entry issue, but the last time the dropped DNS lookup for www.google.com happened to me was like 2 days ago...

Actually, this should be included with the Mavericks+ version

    sudo discoveryutil udnsflushcaches

This is quite nice (I went with an alias myself). Does anyone know if it changed again in macOS?

No.

I am running Sierra right now and `killall HUP mDNSResponder` doesn't work but `sudo dscacheutil -flushcache` does.

Also, just think about how we get all new browser user agents because of this.

It's good practice to include

    set -eu
    set -o pipefail

to avoid the default ON ERROR RESUME NEXT behaviour of bash.

Please stop with the cargo-cult shell scripting. That's not all those options do.

Perhaps an explanation would have been more constructive than an insult.

Yes, I owe an explanation, but the guy advocating pasting bash settings into every script doesn't.

He gave an explanation of what they do. It might be wrong, but you haven't given any alternative one.

Besides he is right, and those are useful additions to almost any script that you want to stop on error, undefined vars, etc.

Is that behaviour not the point here? The script tries the first command,then the second if that fails,etc.

One should also create traps on exit, to revert the system to a good state in the event of pipefail.

I have in my .bash_profile for this purpose: alias cleardns='dscacheutil -flushcache' but this solution is way funnier.

I think you understand my true intentions, jrcii

>(or whatever your name is)

Why is changing names seen as a negative thing? My company also changed its name a month ago, and several customers leaving negative feedback said included this phrase or something similar, while to my recollection none of the positive feedback (which we have way more of) took mention of the name change.

"A rose by any other name would smell as sweet"

basically, it's a no-feature change, so an unnecessary one, so a "bad" one.

Because, what is the point? It is a chore to learn a new name, provides no value to the consumer, and has a feeling of ego/vanity.

When a company renames itself, everyone that works with that company needs to make changes. Financial records, password and account management, , internal documentation, integrations, etc all have to change. Plus, eduction on the change takes time. People who occasionally interact with the company are going to be confused for months afterwards. It's very rare that something positive comes out of the name change for existing customers. The same thing is likely for product renames - platform version detection in software, browser/OS categorization in analytics tools, documentation, etc. It just makes work for everyone involved.

And what's the point? MacOS X was a decent name, with good recognition and trust. If people were interested in understanding the back story to the name, they could, but the 'X' didn't scream '10' to people who weren't familiar with the history, so there wasn't a ton of confusion.

This isn't a company changing names.

Branding changes product names all the time. MacOS X was nonsensical. I'm glad they changed it.

It's not seen universally as a negative thing (by people who know about branding and marketing).

It is, however, used as a negative thing by people who would vent regardless of the name change, and just want to emphasize they care so little about you that they can't even remember your name("or whatever you're called"). It's just some classic disgruntled customer stuff.

       echo "¯\_(ツ)_/¯"

Something about seeing the shrug emoji in code just cracks me up every time.

Thats not an emoji.

Indeed: https://en.wikipedia.org/wiki/Emoticon#Japanese_style

> There is also the \(°O°)\, indicating a hooligan or crazed behaviour, and the (ﾉ◕ヮ◕)ﾉ*:･ﾟ.

Yikes, you are absolutely right, but I think the way that language is fluid we are at most 5 years away from "kids" not being able to recognize the term "smiley". Emoji is becoming the defacto catch-all term.

Well now I have to ask... Presumably that's ascii art, and :) is an emoji. And :-) is also an emoji. So how many characters/rows before an emoji becomes ascii art? Also, I take it emoji is the ascii, and emoticon is the image. Also, emoji sounds plural to me - I take it it's not.

https://en.wikipedia.org/wiki/Emoji

In Japanese, they call ASCII-art style smiley and a pictogram separately. The ASCII-art one is "kaomoji" (where kao means "face" and "moji" is letter) while the pictogram is strictly an emoji (where "e" means "picture").

Of course, one could argue that since the word is now being used internationally, it's not necessary for them to be interpret in the same way as its roots.

The term emoticon refers to a series of text characters (typically punctuation or symbols) that is meant to represent a facial expression or gesture (sometimes when viewed sideways), such as ;-).

Emoticons predate Unicode and emoji, but were later adapted to include Unicode characters.

http://unicode.org/reports/tr51/#Emoticons

An emoji is the name for an image/drawing which represents a single specific unicode character, not a series of characters. The name comes from Japanese e (絵, "picture") + moji (文字, "character") [1]

Multi-character ones would be called smileys, emotes, or emoticons. The confusion comes from the fact that many messengers will automatically replace multi-character emotes with an emoji.

[1] https://en.wikipedia.org/wiki/Emoji

You have it backwards: ¯\_(ツ)_/¯, :), and :-) are all examples of emoticons. Emoji are the images.

Those aren't emoji, they're emoticons.

¯\_(ツ)_/¯ is a type of emoticon referred to as kaomoji common in Asia (and now worldwide), but like the happy face :-) it is an emoticon (kaomoji use a wider character set than the ASCII commonly used in Western emoticons)

Emoji is a Japanese loan word 絵文字 (literally picture character), you can read more about them:

https://en.wikipedia.org/wiki/Emoji

Emoji in English can used as a singular or plural word but you can also write emojis.

All I know is in the mid 90s on IRC we called a :) an emoticon.

Emoji are the images that you often see spammed all over the place: , , , , , ... And "Emoji" is actually plural. "Emojis" is sometimes used as plural, but it's actually wrong.

Emoticons are then usually made up out of multiple ASCII-symbols, although general Unicode is by now also in use: :), :-), :|, :[ ...

And then for the "ㄟ(ツ)ㄏ"-Emoticon, you can get more specific about it and call it "Kaomoji". Kaomoji are not Emoji, even though the two sound related, and are actually a more horizontal style of Emoticons, so basically any Emoticon which you can read without turning your head: ㄟ(ツ)ㄏ, ^^, (っ´▽`)っ, (╯°□°)╯︵ ┻━┻, ఠ_ఠ ...

Yore welcome

Someone renamed this. Why?

We did. The original title, "Please OS X (or whatever your name is) just fucking reset your DNS cache please", is obviously baity, which means it breaks the HN guidelines. Please read https://news.ycombinator.com/newsguidelines.html. When a title is misleading or linkbait, one should change it to something accurate and neutral.

Thanks for the update. Would the removal of "fucking" allowed the original title to remain? I feel that the title spurred the interest, as evidenced by the amount of discussion. The new title is not nearly as interesting, nor does it convey the author's vision and rage accurately.

The title rather than the content spurring the interest is pretty much the point of the 'no clickbait titles' guideline. The content itself is hardly in the 'gratifies intellectual curiosity' category.

> Would the removal of "fucking" allowed the original title to remain?

No, it isn't the profanity we care about, but the baitiness. Titles that stir up drama or controversy aren't a good fit for HN—the discussions are inevitably primed by the titles, and those are the kind of discussions we hope to avoid.

Reply on news.ycombinator.com