I know many people that just type in the usual Google public DNS when they need to add one to a computer or server. It’s easy right!? Just remember 188.8.131.52 and/or 184.108.40.206 it’s a no brainer! But what are we REALLY doing when we use Google for DNS?
Your chosen DNS servers translate domains (xyz.com) to IP addresses (xxx.xxx.xxx.xxx). So your name servers know every domain you have accessed since they did the job of translating them to IP address of the servers hosting the site. This is some pretty juicy information for a company like Google or even your ISP that provides your DSL or Cable Internet access. If you are already using Google services like search and Gmail using their name servers adds to the bounty of information they collect about you.
Maybe you just hate that your ISP hijacks your browser every time you type in an address wrong? Giving your their recommendations that are ad driven.
“How can I not leak all my information!?”
OpenNIC DNS can help solve this issue and give you some added features. It is simple to change the DNS servers.
You can also take it one step further and use DNScrypt to secure your queries. Just choose your closest geographic OpenNIC DNS servers from the list that offer DNScrypt support.
Another added bonus of using OpenNIC is they support Namecoin (.bit) domain names and offers for free a list of their own Top Level Domains (TLDs).
It is hard to wean yourself off of services like Google that are in actuality a key player in what many call the surveillance economy. Which equates to giving your information and privacy away for free services. A simple change like your DNS and using a search engine that does not track you can be a huge step to taking back control of your privacy.
I came across a simple yet elegant means of managing multiple Amazon Web Services credentials when using the AWS CLI. This way does not make you have to hack your .aws/config and is the simplest/cleanest way I have found.
First install direnv and make sure it is in your PATH.
Be sure to remember to add the hook to your shell of choice as they outline in their README.
Now that you have direnv setup we can configure it for each client.
I use a directory structure to keep each client in their own directory.
So for example in :
.../clients/ACME/ I make a .envrc file and export my AWS keys in it:
Once you make your .envrc file run direnv allow to enable using the config. Then test your AWS CLI to insure working properly.
Then when you are doing work on that client’s account you simply have to cd into their respective directory.
Be sure to either encrypt the whole directory or at least chmod 600 the .envrc files to protect your keys.
I deal with a lot of different clients on a daily basis. It is a bit of a chore to figure out how to tie together their different messaging apps in order to interact with them and be alerted of any needs or emergencies.
Most clients nowadays use either Slack, HipChat, Google Hangouts, and Skype. With Slack and HipChat being most popular in my regards. The main issue I have is that I use Linux and the Slack web interface is a resource hog and can only monitor one client at a time. Whichever one is loaded at the time. The HipChat web interface is a bit lighter but the same issue persists as with Slack.
Luckily with Slack you can enable either (or both) XMPP and IRC. With HipChat you can only enable XMPP.
For Slack you go to Admin Settings and enable both or your choice: