Tag Archives: dns

DiggyDB – Amazon Route53 as a blazingly fast and reliable database

Building further upon a “wild story” by Corey Quinn, Nicholas Martin describes how to (ab)use DNS TXT records by storing data in them, as if it were a database:

When you think about it, DNS configuration is actually a very rudimentary NoSQL database. You can view and modify it at any time quite easily through your domain provider’s website, and you can view each “record” just like a row in a database table.

To easily do this, he created DiggyDB

DiggyDB goes one step further than simple a key/value TXT record by allowing you to use (or indeed abuse) DNS TXT records by storing JSON data, almost as though it was a MongoDB or AWS DynamoDB!

Apparently, You Can Use Route53 as a Blazingly Fast Database →
DiggyDB – Amazon Route53 as a blazingly fast and reliable database →

💵 This linked article is stuck behind Medium's metered paywall, which may prevent you from reading it. Open the link in an incognito window to bypass Medium's ridiculous reading limit.

Via CSS-Tricks

Manage your DNS from GitHub with DNSControl

In this post Sven Luijten uses DNSControl from within GitHub Actions to manage DNS:

What if you could edit a JavaScript file with your desired DNS configuration, submit a pull request on GitHub, see a preview of the changes you are about to make, and when you merge it, have those changes be applied completely automatically?

The main action behind it is koenrh/dnscontrol-action:

# .github/workflows/push.yml
name: Push DNS changes

on:
  push:
    branches:
      - main

jobs:
  push:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2

      - name: Push DNS changes
        uses: koenrh/dnscontrol-action@v3
        env:
          CLOUDFLARE_API_TOKEN: ${{ secrets.CLOUDFLARE_API_TOKEN }}
        with:
          args: push

The action also supports more arguments — as covered in Sven’s post — for checking and previewing.

Manage your DNS from GitHub with DNSControl →

How and why the leap second affected Cloudflare DNS

At midnight UTC on New Year’s Day, deep inside Cloudflare’s custom RRDNS software, a number went negative when it should always have been, at worst, zero. A little later this negative value caused RRDNS to panic. This panic was caught using the recover feature of the Go language. The net effect was that some DNS resolutions to some Cloudflare managed web properties failed.

90 minutes later they had identified the problem and started rolling out a 1-character fix.

How and why the leap second affected Cloudflare DNS →

Related:

Zero-config development with Apache’s VirtualDocumentRoot and xip.io

# Use name-based virtual hosting.
NameVirtualHost *:80
UseCanonicalName Off
 
# ~/Sites/ vhost configuration - sends foo.bar.dev to ~/Sites/bar/foo
<VirtualHost *:80>
    VirtualDocumentRoot /Users/dave/Sites/%2/%1
 
    <Directory "/Users/dave/Sites">
        Options Indexes FollowSymLinks MultiViews
        AllowOverride All
        Order allow,deny
        Allow from all
    </Directory>
</VirtualHost>

What that VirtualDocumentRoot does is map the above company and project to the %2 and %1 variables, respectively. So whenever I surf to http://foo.bar.dev, I end up in ~/Sites/bar/foo.

Dave’s a clever man.

Zero-config development with Apache’s VirtualDocumentRoot and xip.io →

xip.io – Wildcard DNS for any IP address.

xip.io is a magic domain name that provides wildcard DNS for any IP address. Say your LAN IP address is 10.0.0.1. Using xip.io:

  • 10.0.0.1.xip.io resolves to 10.0.0.1
  • www.10.0.0.1.xip.io resolves to 10.0.0.1
  • mysite.10.0.0.1.xip.io resolves to 10.0.0.1
  • foo.bar.10.0.0.1.xip.io resolves to 10.0.0.1

…and so on. You can use these domains to access virtual hosts on your development web server from devices on your local network, like iPads, iPhones, and other computers. No configuration required!

Now that’s pure genius! How come no-one else ever thought of that before?

To get this working in MAMP Pro, select your vhost, go to the advanced tab and enter ServerAlias project.*.xip.io in the Customized virtual host general settings-field.

Test it out by surfing to http://project.127.0.0.1.xip.io on your local machine. If for example your IP is 192.168.0.11, you can access it from other machines via http://project.192.168.0.11.xip.io

xip.io →