Every so often I make changes to a DNS record, test it, find out it's wrong, fix it and still get the old response because of caching somewhere along the line. After it happened to me and a colleague during a launch of a new version of a website, I decided to address the issue. I wanted a way to test DNS quickly and easily (preferably locally on command line), for it to be lightweight, doesn't require changes to my existing setup and doesn't require learning new tools. I decided to create a Docker image that has its own DNS resolver and each new container from that image has a clean cache and doesn't depend on other DNS servers or is affected from their caching.
Usage
To create a new container:
docker run -it registry.shore.coil/resolver
Inside the container you have access to nslookup, dig and mail for testing purposes. If you need to test new changes, exit the container and create a new one with no cache.
If you want to run just a single command (like getting the MX record for shore.co.il):
docker run registry.shore.co.il/resolver dig +short shore.co.il mx
How does it work
On launch, the container runs and uses its own DNS resolver (in this case NSD). This way the OS caching or upstream caching don't interferes with querying and every new container starts with an empty cache.
A common practice for me when a new member joins the team or when someone forgets his/ her AWS account password is to change the account password myself, send the new password over an insecure channel (email, Slack) but force the account to change the password on first login. Also, I prefer to have users manage their own keys to AWS themselves. But without the correct IAM policy users aren't able to perform either action. Here's an IAM to allow both:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"iam:GetAccountPasswordPolicy",
"iam:ListAccount*",
"iam:GetAccountSummary",
"iam:GetAccountPasswordPolicy",
"iam:ListUsers"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"iam:ChangePassword",
"iam:*LoginProfile",
"iam:*AccessKey*",
"iam:*SSHPublicKey*"
],
"Resource": "arn:aws:iam::<INSERT AWS ACCOUNT ID HERE>:user/${aws:username}"
}
]
}
If you want a little script with the AWS CLI, here's one for you:
tempfile=$(mktemp)
accountid="$(aws ec2 describe-security-groups \
--group-names 'Default' \
--query 'SecurityGroups[0].OwnerId' \
--output text)"
curl https://www.shore.co.il/blog/static/policy.json | sed "s/<INSERT AWS ACCOUNT ID HERE>/$accountid/" > $tempfile
aws iam create-policy \
--policy-name change-own-password \
--policy-document file://$tempfile
rm $tempfile
On some occasion you want to serve your git repo from your local copy (perhaps your git repository is quite large and your internet connection is slow or your build process would benefit from pulling from an intermediary without authentication). Here are 2 ways to serve your git repository without any configuration or software installation. Both ways serve a single repository without authentication or encryption but read-only (no push).
Using the git protocol
The git executable is itself a git server using the native git protocol. Inside the root of the repository run the following command
git daemon --reuseaddr --verbose --base-path=. --export-all ./.git
And on the client you can clone by running
git clone git://servername/ reponame
Using the HTTP protocol
This way serves the repo over HTTP using Python 2's SimpleHTTPServer. Run the following in the rot of the git repo
git update-server-info
cd .git
python -m SimpleHTTPServer
And on the client clone by running
git clone http://servername:8000/ reponame
Final words
I've added both ways as git aliases in my rcfiles repo.
