<?xml version="1.0" encoding="utf-8"?>
<feed xml:lang="en-us" xmlns="http://www.w3.org/2005/Atom"><title>Simon Willison's Weblog: dns</title><link href="http://simonwillison.net/" rel="alternate"/><link href="http://simonwillison.net/tags/dns.atom" rel="self"/><id>http://simonwillison.net/</id><updated>2026-03-22T19:16:30+00:00</updated><author><name>Simon Willison</name></author><entry><title>DNS Lookup</title><link href="https://simonwillison.net/2026/Mar/22/dns/#atom-tag" rel="alternate"/><published>2026-03-22T19:16:30+00:00</published><updated>2026-03-22T19:16:30+00:00</updated><id>https://simonwillison.net/2026/Mar/22/dns/#atom-tag</id><summary type="html">
    &lt;p&gt;&lt;strong&gt;Tool:&lt;/strong&gt; &lt;a href="https://tools.simonwillison.net/dns"&gt;DNS Lookup&lt;/a&gt;&lt;/p&gt;
    &lt;p&gt;TIL that Cloudflare's 1.1.1.1 DNS service (and 1.1.1.2 and 1.1.1.3, which block malware and malware + adult content respectively) has a CORS-enabled JSON API, so I &lt;a href="https://github.com/simonw/tools/pull/258#issue-4116864108"&gt;had Claude Code build me&lt;/a&gt; a UI for running DNS queries against all three of those resolvers.&lt;/p&gt;
    
        &lt;p&gt;Tags: &lt;a href="https://simonwillison.net/tags/dns"&gt;dns&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/cors"&gt;cors&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/cloudflare"&gt;cloudflare&lt;/a&gt;&lt;/p&gt;
    

</summary><category term="dns"/><category term="cors"/><category term="cloudflare"/></entry><entry><title>SSH has no Host header</title><link href="https://simonwillison.net/2026/Jan/22/ssh-has-no-host-header/#atom-tag" rel="alternate"/><published>2026-01-22T23:57:50+00:00</published><updated>2026-01-22T23:57:50+00:00</updated><id>https://simonwillison.net/2026/Jan/22/ssh-has-no-host-header/#atom-tag</id><summary type="html">
    
&lt;p&gt;&lt;strong&gt;&lt;a href="https://blog.exe.dev/ssh-host-header"&gt;SSH has no Host header&lt;/a&gt;&lt;/strong&gt;&lt;/p&gt;
&lt;a href="https://exe.dev/"&gt;exe.dev&lt;/a&gt; is a new hosting service that, for $20/month, gives you up to 25 VMs "that share 2 CPUs and 8GB RAM". Everything happens over SSH, including creating new VMs. Once configured you can sign into your exe.dev VMs like this:&lt;/p&gt;
&lt;pre&gt;&lt;code&gt;ssh simon.exe.dev
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;Here's the clever bit: when you run the above command &lt;code&gt;exe.dev&lt;/code&gt; signs you into your VM of that name... but they don't assign every VM its own IP address and SSH has no equivalent of the Host header, so how does their load balancer know &lt;em&gt;which&lt;/em&gt; of your VMs to forward you on to?&lt;/p&gt;
&lt;p&gt;The answer is that while they don't assign a unique IP to every VM they &lt;em&gt;do&lt;/em&gt; have enough IPs that they can ensure each of your VMs has an IP that is unique to your account.&lt;/p&gt;
&lt;p&gt;If I create two VMs they will each resolve to a separate IP address, each of which is shared with many other users. The underlying infrastructure then identifies my user account from my SSH public key and can determine which underlying VM to forward my SSH traffic to.

    &lt;p&gt;&lt;small&gt;&lt;/small&gt;Via &lt;a href="https://lobste.rs/s/7oqiqi/ssh_has_no_host_header"&gt;lobste.rs&lt;/a&gt;&lt;/small&gt;&lt;/p&gt;


    &lt;p&gt;Tags: &lt;a href="https://simonwillison.net/tags/dns"&gt;dns&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/hosting"&gt;hosting&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/ssh"&gt;ssh&lt;/a&gt;&lt;/p&gt;



</summary><category term="dns"/><category term="hosting"/><category term="ssh"/></entry><entry><title>Quoting AWS</title><link href="https://simonwillison.net/2025/Oct/23/aws-postmortem/#atom-tag" rel="alternate"/><published>2025-10-23T04:49:59+00:00</published><updated>2025-10-23T04:49:59+00:00</updated><id>https://simonwillison.net/2025/Oct/23/aws-postmortem/#atom-tag</id><summary type="html">
    &lt;blockquote cite="https://aws.amazon.com/message/101925/"&gt;&lt;p&gt;For resiliency, the DNS Enactor operates redundantly and fully independently in three different Availability Zones (AZs). [...] When the second Enactor (applying the newest plan) completed its endpoint updates, it then invoked the plan clean-up process, which identifies plans that are significantly older than the one it just applied and deletes them. At the same time that this clean-up process was invoked, the first Enactor (which had been unusually delayed) applied its much older plan to the regional DDB endpoint, overwriting the newer plan. [...] The second Enactor's clean-up process then deleted this older plan because it was many generations older than the plan it had just applied. As this plan was deleted, all IP addresses for the regional endpoint were immediately removed.&lt;/p&gt;&lt;/blockquote&gt;
&lt;p class="cite"&gt;&amp;mdash; &lt;a href="https://aws.amazon.com/message/101925/"&gt;AWS&lt;/a&gt;, Amazon DynamoDB Service Disruption in Northern Virginia (US-EAST-1) Region (14.5 hours long!)&lt;/p&gt;

    &lt;p&gt;Tags: &lt;a href="https://simonwillison.net/tags/aws"&gt;aws&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/dns"&gt;dns&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/scaling"&gt;scaling&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/postmortem"&gt;postmortem&lt;/a&gt;&lt;/p&gt;



</summary><category term="aws"/><category term="dns"/><category term="scaling"/><category term="postmortem"/></entry><entry><title>Cloudflare Radar: AI Insights</title><link href="https://simonwillison.net/2025/Sep/1/cloudflare-radar-ai-insights/#atom-tag" rel="alternate"/><published>2025-09-01T17:06:56+00:00</published><updated>2025-09-01T17:06:56+00:00</updated><id>https://simonwillison.net/2025/Sep/1/cloudflare-radar-ai-insights/#atom-tag</id><summary type="html">
    
&lt;p&gt;&lt;strong&gt;&lt;a href="https://radar.cloudflare.com/ai-insights"&gt;Cloudflare Radar: AI Insights&lt;/a&gt;&lt;/strong&gt;&lt;/p&gt;
Cloudflare launched this dashboard &lt;a href="https://blog.cloudflare.com/expanded-ai-insights-on-cloudflare-radar/"&gt;back in February&lt;/a&gt;, incorporating traffic analysis from Cloudflare's network along with insights from their popular 1.1.1.1 DNS service.&lt;/p&gt;
&lt;p&gt;I found this chart particularly interesting, showing which documented AI crawlers are most active collecting training data - lead by GPTBot, ClaudeBot and Meta-ExternalAgent:&lt;/p&gt;
&lt;p&gt;&lt;img alt="Line chart showing HTTP traffic by bot over time from August 26 to September 1. HTTP traffic by bot - HTTP request trends for top five most active AI bots. Crawl purpose: Training. GPTBot 31.7% (orange line), ClaudeBot 27.1% (blue line), Meta-ExternalAgent 25.3% (light blue line), Bytespider 9.3% (yellow-green line), Applebot 5.2% (green line). Max scale shown on y-axis. X-axis shows dates: Tue, Aug 26, Wed, Aug 27, Thu, Aug 28, Fri, Aug 29, Sat, Aug 30, Sun, Aug 31, Mon, Sep 1. Top right shows Crawl purpose dropdown set to &amp;quot;Training&amp;quot; with X and checkmark buttons." src="https://static.simonwillison.net/static/2025/http-traffic-by-bot.jpg" /&gt;&lt;/p&gt;
&lt;p&gt;Cloudflare's DNS data also hints at the popularity of different services. ChatGPT holds the first place, which is unsurprising - but second place is a hotly contested race between Claude and Perplexity and #4/#5/#6 is contested by GitHub Copilot, Perplexity, and Codeium/Windsurf.&lt;/p&gt;
&lt;p&gt;Google Gemini comes in 7th, though since this is DNS based I imagine this is undercounting instances of Gemini on &lt;code&gt;google.com&lt;/code&gt; as opposed to &lt;code&gt;gemini.google.com&lt;/code&gt;.&lt;/p&gt;
&lt;p&gt;&lt;img alt="Line chart showing generative AI services popularity rankings over time. Title: &amp;quot;Generative AI services popularity&amp;quot; with subtitle &amp;quot;Top 10 services based on 1.1.1.1 DNS resolver traffic&amp;quot; and question mark and share icons. Legend shows: ChatGPT/OpenAI (dark blue), Character.AI (light blue), Claude/Anthropic (orange), Perplexity (olive green), GitHub Copilot (green), Codeium/Windsurf AI (pink), Google Gemini (purple), QuillBot (red), Grok/xAI (brown), DeepSeek (yellow). Y-axis shows ranks #1-#10, X-axis shows dates from Mon, Aug 25 to Mon, Sep 1 (partially visible). ChatGPT maintains #1 position throughout. Other services show various ranking changes over the week-long period." src="https://static.simonwillison.net/static/2025/cloudflare-gen-ai.jpg" /&gt;

    &lt;p&gt;&lt;small&gt;&lt;/small&gt;Via &lt;a href="https://news.ycombinator.com/item?id=45093090"&gt;Hacker News&lt;/a&gt;&lt;/small&gt;&lt;/p&gt;


    &lt;p&gt;Tags: &lt;a href="https://simonwillison.net/tags/crawling"&gt;crawling&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/dns"&gt;dns&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/ai"&gt;ai&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/cloudflare"&gt;cloudflare&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/generative-ai"&gt;generative-ai&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/llms"&gt;llms&lt;/a&gt;&lt;/p&gt;



</summary><category term="crawling"/><category term="dns"/><category term="ai"/><category term="cloudflare"/><category term="generative-ai"/><category term="llms"/></entry><entry><title>A Sneaky Phish Just Grabbed my Mailchimp Mailing List</title><link href="https://simonwillison.net/2025/Apr/4/a-sneaky-phish/#atom-tag" rel="alternate"/><published>2025-04-04T15:05:39+00:00</published><updated>2025-04-04T15:05:39+00:00</updated><id>https://simonwillison.net/2025/Apr/4/a-sneaky-phish/#atom-tag</id><summary type="html">
    
&lt;p&gt;&lt;strong&gt;&lt;a href="https://www.troyhunt.com/a-sneaky-phish-just-grabbed-my-mailchimp-mailing-list/"&gt;A Sneaky Phish Just Grabbed my Mailchimp Mailing List&lt;/a&gt;&lt;/strong&gt;&lt;/p&gt;
In further evidence that phishing attacks can catch out the &lt;em&gt;most&lt;/em&gt; sophisticated among us, security researcher (and operator of &lt;a href="https://haveibeenpwned.com/"&gt;';--have i been pwned?&lt;/a&gt;) Troy Hunt reports on how he fell for an extremely well crafted phishing attack against his MailChimp account which then exported his full list of subscribers, including people who had unsubscribed (data which MailChimp stores and continues to make available).&lt;/p&gt;
&lt;p&gt;This could happen to any of us:&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;I've received a gazillion similar phishes before that I've identified early, so what was different about this one? Tiredness, was a major factor. I wasn't alert enough, and I didn't properly think through what I was doing.&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;Troy's account was protected by authenticator app 2FA, but the phishing site (on the realistic sounding &lt;code&gt;mailchimp-sso.com&lt;/code&gt; domain) asked for that code too and instantly proxied it through to MailChimp - somewhat ironic as Troy had been promoting phishing-resistant passkeys on his trip to London, a technology that MailChimp doesn't offer yet.&lt;/p&gt;
&lt;p&gt;There are a bunch of interesting details here. I appreciated this point about how short-lived authentication sessions can &lt;em&gt;reduce&lt;/em&gt; account security by conditioning users to expect constant login requests:&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;I also realised another factor that pre-conditioned me to enter credentials into what I thought was Mailchimp is their very short-lived authentication sessions. Every time I go back to the site, I need to re-authenticate and whilst the blame still clearly lies with me, I'm used to logging back in on every visit. Keeping a trusted device auth'd for a longer period would likely have raised a flag on my return to the site if I wasn't still logged in.&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;It looks like MailChimp preserve the email addresses of unsubscribed users to prevent them from being re-subscribed by future list imports. Troy discusses this issue at length in further updates to the post.&lt;/p&gt;
&lt;p&gt;Also interesting: this &lt;a href="https://www.validin.com/blog/pulling_threads_on_phishing_campaign/"&gt;article by DNS forensics company Validin&lt;/a&gt; which tracks down the responsible group using DNS records and other hints such as title tags and favicon hashes.

    &lt;p&gt;&lt;small&gt;&lt;/small&gt;Via &lt;a href="https://www.schneier.com/blog/archives/2025/04/troy-hunt-gets-phished.html"&gt;Bruce Schneier&lt;/a&gt;&lt;/small&gt;&lt;/p&gt;


    &lt;p&gt;Tags: &lt;a href="https://simonwillison.net/tags/dns"&gt;dns&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/phishing"&gt;phishing&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/security"&gt;security&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/passkeys"&gt;passkeys&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/troy-hunt"&gt;troy-hunt&lt;/a&gt;&lt;/p&gt;



</summary><category term="dns"/><category term="phishing"/><category term="security"/><category term="passkeys"/><category term="troy-hunt"/></entry><entry><title>OpenAI's postmortem for API, ChatGPT &amp; Sora Facing Issues</title><link href="https://simonwillison.net/2024/Dec/13/openai-postmortem/#atom-tag" rel="alternate"/><published>2024-12-13T05:29:10+00:00</published><updated>2024-12-13T05:29:10+00:00</updated><id>https://simonwillison.net/2024/Dec/13/openai-postmortem/#atom-tag</id><summary type="html">
    
&lt;p&gt;&lt;strong&gt;&lt;a href="https://status.openai.com/incidents/ctrsv3lwd797"&gt;OpenAI&amp;#x27;s postmortem for API, ChatGPT &amp;amp; Sora Facing Issues&lt;/a&gt;&lt;/strong&gt;&lt;/p&gt;
OpenAI had an outage across basically everything for four hours on Wednesday. They've now published a detailed postmortem which includes some fascinating technical details about their "hundreds of Kubernetes clusters globally".&lt;/p&gt;
&lt;p&gt;The culprit was a newly deployed telemetry system:&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;Telemetry services have a very wide footprint, so this new service’s configuration unintentionally caused every node in each cluster to execute resource-intensive Kubernetes API operations whose cost scaled with the size of the cluster. With thousands of nodes performing these operations simultaneously, the Kubernetes API servers became overwhelmed, taking down the Kubernetes control plane in most of our large clusters. [...]&lt;/p&gt;
&lt;p&gt;The Kubernetes data plane can operate largely independently of the control plane, but DNS relies on the control plane – services don’t know how to contact one another without the Kubernetes control plane. [...]&lt;/p&gt;
&lt;p&gt;DNS caching mitigated the impact temporarily by providing stale but functional DNS records. However, as cached records expired over the following 20 minutes, services began failing due to their reliance on real-time DNS resolution.&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;It's always DNS.

    &lt;p&gt;&lt;small&gt;&lt;/small&gt;Via &lt;a href="https://twitter.com/therealadamg/status/1867393379287650778"&gt;@therealadamg&lt;/a&gt;&lt;/small&gt;&lt;/p&gt;


    &lt;p&gt;Tags: &lt;a href="https://simonwillison.net/tags/dns"&gt;dns&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/devops"&gt;devops&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/kubernetes"&gt;kubernetes&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/postmortem"&gt;postmortem&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/openai"&gt;openai&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/chatgpt"&gt;chatgpt&lt;/a&gt;&lt;/p&gt;



</summary><category term="dns"/><category term="devops"/><category term="kubernetes"/><category term="postmortem"/><category term="openai"/><category term="chatgpt"/></entry><entry><title>Ask HN: What happens to ".io" TLD after UK gives back the Chagos Islands?</title><link href="https://simonwillison.net/2024/Oct/3/what-happens-to-io-after-uk-gives-back-chagos/#atom-tag" rel="alternate"/><published>2024-10-03T17:25:21+00:00</published><updated>2024-10-03T17:25:21+00:00</updated><id>https://simonwillison.net/2024/Oct/3/what-happens-to-io-after-uk-gives-back-chagos/#atom-tag</id><summary type="html">
    
&lt;p&gt;&lt;strong&gt;&lt;a href="https://news.ycombinator.com/item?id=41729526"&gt;Ask HN: What happens to &amp;quot;.io&amp;quot; TLD after UK gives back the Chagos Islands?&lt;/a&gt;&lt;/strong&gt;&lt;/p&gt;
This morning on the BBC: &lt;a href="https://www.bbc.com/news/articles/c98ynejg4l5o"&gt;UK will give sovereignty of Chagos Islands to Mauritius&lt;/a&gt;. The Chagos Islands include the area that the UK calls &lt;a href="https://en.wikipedia.org/wiki/British_Indian_Ocean_Territory"&gt;the British Indian Ocean Territory&lt;/a&gt;. The &lt;a href="https://en.wikipedia.org/wiki/.io"&gt;.io ccTLD&lt;/a&gt; uses the  ISO-3166 two-letter country code for that designation.&lt;/p&gt;
&lt;p&gt;As the owner of &lt;a href="https://datasette.io/"&gt;datasette.io&lt;/a&gt; the question of what happens to that ccTLD is suddenly very relevant to me.&lt;/p&gt;
&lt;p&gt;This Hacker News conversation has some useful information. It sounds like there's a very real possibility that &lt;code&gt;.io&lt;/code&gt; could be deleted after a few years notice - it's happened before, for ccTLDs such as &lt;code&gt;.zr&lt;/code&gt; for Zaire (which renamed to &lt;a href="https://en.wikipedia.org/wiki/Democratic_Republic_of_the_Congo"&gt;Democratic Republic of the Congo&lt;/a&gt; in 1997, with &lt;code&gt;.zr&lt;/code&gt; withdrawn in 2001) and &lt;a href="https://en.wikipedia.org/wiki/.cs"&gt;.cs&lt;/a&gt; for Czechoslovakia, withdrawn in 1995.&lt;/p&gt;
&lt;p&gt;Could &lt;code&gt;.io&lt;/code&gt; change status to the same kind of TLD as &lt;code&gt;.museum&lt;/code&gt;, unaffiliated with any particular geography? The convention is for two letter TLDs to exactly match ISO country codes, so that may not be an option.


    &lt;p&gt;Tags: &lt;a href="https://simonwillison.net/tags/dns"&gt;dns&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/domains"&gt;domains&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/hacker-news"&gt;hacker-news&lt;/a&gt;&lt;/p&gt;



</summary><category term="dns"/><category term="domains"/><category term="hacker-news"/></entry><entry><title>Migrating Mess With DNS to use PowerDNS</title><link href="https://simonwillison.net/2024/Aug/19/migrating-mess-with-dns/#atom-tag" rel="alternate"/><published>2024-08-19T22:12:07+00:00</published><updated>2024-08-19T22:12:07+00:00</updated><id>https://simonwillison.net/2024/Aug/19/migrating-mess-with-dns/#atom-tag</id><summary type="html">
    
&lt;p&gt;&lt;strong&gt;&lt;a href="https://jvns.ca/blog/2024/08/19/migrating-mess-with-dns-to-use-powerdns/"&gt;Migrating Mess With DNS to use PowerDNS&lt;/a&gt;&lt;/strong&gt;&lt;/p&gt;
Fascinating in-depth write-up from Julia Evans about how she upgraded her "mess with dns" playground application to use &lt;a href="https://github.com/PowerDNS/pdns"&gt;PowerDNS&lt;/a&gt;, an open source DNS server with a &lt;a href="https://doc.powerdns.com/authoritative/http-api/index.html#working-with-the-api"&gt;comprehensive JSON API&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;If you haven't explored &lt;a href="https://messwithdns.net/"&gt;mess with dns&lt;/a&gt; it's absolutely worth checking out. No login required: when you visit the site it assigns you a random subdomain (I got &lt;code&gt;garlic299.messwithdns.com&lt;/code&gt; just now) and then lets you start adding additional sub-subdomains with their own DNS records - A records, CNAME records and more.&lt;/p&gt;
&lt;p&gt;The interface then shows a live (WebSocket-powered) log of incoming DNS requests and responses, providing instant feedback on how your configuration affects DNS resolution.

    &lt;p&gt;&lt;small&gt;&lt;/small&gt;Via &lt;a href="https://news.ycombinator.com/item?id=41292784"&gt;Hacker News&lt;/a&gt;&lt;/small&gt;&lt;/p&gt;


    &lt;p&gt;Tags: &lt;a href="https://simonwillison.net/tags/dns"&gt;dns&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/go"&gt;go&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/julia-evans"&gt;julia-evans&lt;/a&gt;&lt;/p&gt;



</summary><category term="dns"/><category term="go"/><category term="julia-evans"/></entry><entry><title>Where is all of the fediverse?</title><link href="https://simonwillison.net/2024/Jan/12/where-is-all-of-the-fediverse/#atom-tag" rel="alternate"/><published>2024-01-12T18:54:15+00:00</published><updated>2024-01-12T18:54:15+00:00</updated><id>https://simonwillison.net/2024/Jan/12/where-is-all-of-the-fediverse/#atom-tag</id><summary type="html">
    
&lt;p&gt;&lt;strong&gt;&lt;a href="https://blog.benjojo.co.uk/post/who-hosts-the-fediverse-instances"&gt;Where is all of the fediverse?&lt;/a&gt;&lt;/strong&gt;&lt;/p&gt;
Neat piece of independent research by Ben Cox, who used the /api/v1/instance/peers Mastodon API endpoint to get a list of “peers” (instances his instance knows about), then used their DNS records to figure out which hosting provider they were running on.&lt;/p&gt;

&lt;p&gt;Next Ben combined that with active users from the /nodeinfo/2.0 API on each instance to figure out the number of users on each of those major hosting providers.&lt;/p&gt;

&lt;p&gt;Cloudflare and Fastly were heavily represented, but it turns out you can unveil the underlying IP for most instances by triggering an HTTP Signature exchange with them and logging the result.&lt;/p&gt;

&lt;p&gt;Ben’s conclusion: Hertzner and OVH are responsible for hosting a sizable portion of the fediverse as it exists today.

    &lt;p&gt;&lt;small&gt;&lt;/small&gt;Via &lt;a href="https://lobste.rs/s/kzl90v/where_is_all_fediverse"&gt;lobste.rs&lt;/a&gt;&lt;/small&gt;&lt;/p&gt;


    &lt;p&gt;Tags: &lt;a href="https://simonwillison.net/tags/dns"&gt;dns&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/hosting"&gt;hosting&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/mastodon"&gt;mastodon&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/fediverse"&gt;fediverse&lt;/a&gt;&lt;/p&gt;



</summary><category term="dns"/><category term="hosting"/><category term="mastodon"/><category term="fediverse"/></entry><entry><title>Implement DNS in a weekend</title><link href="https://simonwillison.net/2023/May/12/implement-dns-in-a-weekend/#atom-tag" rel="alternate"/><published>2023-05-12T18:14:31+00:00</published><updated>2023-05-12T18:14:31+00:00</updated><id>https://simonwillison.net/2023/May/12/implement-dns-in-a-weekend/#atom-tag</id><summary type="html">
    
&lt;p&gt;&lt;strong&gt;&lt;a href="https://implement-dns.wizardzines.com/"&gt;Implement DNS in a weekend&lt;/a&gt;&lt;/strong&gt;&lt;/p&gt;
Fantastically clear and useful guide to implementing DNS lookups, from scratch, using Python’s struct, socket and dataclass modules—Julia Evans plans to follow this up with one for TLS which I am very much looking forward to.

    &lt;p&gt;&lt;small&gt;&lt;/small&gt;Via &lt;a href="https://jvns.ca/blog/2023/05/12/introducing-implement-dns-in-a-weekend/"&gt;Julia Evans&lt;/a&gt;&lt;/small&gt;&lt;/p&gt;


    &lt;p&gt;Tags: &lt;a href="https://simonwillison.net/tags/dns"&gt;dns&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/python"&gt;python&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/julia-evans"&gt;julia-evans&lt;/a&gt;&lt;/p&gt;



</summary><category term="dns"/><category term="python"/><category term="julia-evans"/></entry><entry><title>Google Public DNS Flush Cache</title><link href="https://simonwillison.net/2021/Dec/6/google-public-dns-flush-cache/#atom-tag" rel="alternate"/><published>2021-12-06T23:17:08+00:00</published><updated>2021-12-06T23:17:08+00:00</updated><id>https://simonwillison.net/2021/Dec/6/google-public-dns-flush-cache/#atom-tag</id><summary type="html">
    
&lt;p&gt;&lt;strong&gt;&lt;a href="https://developers.google.com/speed/public-dns/cache"&gt;Google Public DNS Flush Cache&lt;/a&gt;&lt;/strong&gt;&lt;/p&gt;
Google Public DNS (8.8.8.8) have a flush cache page too.

    &lt;p&gt;&lt;small&gt;&lt;/small&gt;Via &lt;a href="https://news.ycombinator.com/item?id=29464671"&gt;isclever on Hacker News&lt;/a&gt;&lt;/small&gt;&lt;/p&gt;


    &lt;p&gt;Tags: &lt;a href="https://simonwillison.net/tags/dns"&gt;dns&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/google"&gt;google&lt;/a&gt;&lt;/p&gt;



</summary><category term="dns"/><category term="google"/></entry><entry><title>1.1.1.1/purge-cache</title><link href="https://simonwillison.net/2021/Dec/6/purge-cache/#atom-tag" rel="alternate"/><published>2021-12-06T23:15:08+00:00</published><updated>2021-12-06T23:15:08+00:00</updated><id>https://simonwillison.net/2021/Dec/6/purge-cache/#atom-tag</id><summary type="html">
    
&lt;p&gt;&lt;strong&gt;&lt;a href="https://1.1.1.1/purge-cache/"&gt;1.1.1.1/purge-cache&lt;/a&gt;&lt;/strong&gt;&lt;/p&gt;
Cloudflare’s 1.1.1.1 DNS service has a tool that anyone can use to flush a specific DNS entry from their cache—could be useful for assisting rollouts of new DNS configurations.

    &lt;p&gt;&lt;small&gt;&lt;/small&gt;Via &lt;a href="https://news.ycombinator.com/item?id=29464671"&gt;isclever on Hacker News&lt;/a&gt;&lt;/small&gt;&lt;/p&gt;


    &lt;p&gt;Tags: &lt;a href="https://simonwillison.net/tags/dns"&gt;dns&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/cloudflare"&gt;cloudflare&lt;/a&gt;&lt;/p&gt;



</summary><category term="dns"/><category term="cloudflare"/></entry><entry><title>MDN: Subdomain takeovers</title><link href="https://simonwillison.net/2021/Aug/22/mdn-subdomain-takeovers/#atom-tag" rel="alternate"/><published>2021-08-22T05:31:58+00:00</published><updated>2021-08-22T05:31:58+00:00</updated><id>https://simonwillison.net/2021/Aug/22/mdn-subdomain-takeovers/#atom-tag</id><summary type="html">
    
&lt;p&gt;&lt;strong&gt;&lt;a href="https://developer.mozilla.org/en-US/docs/Web/Security/Subdomain_takeovers"&gt;MDN: Subdomain takeovers&lt;/a&gt;&lt;/strong&gt;&lt;/p&gt;
MDN have a page about subdomain takeover attacks that focuses more on CNAME records: if you have a CNAME pointing to a common delegated hosting provider but haven’t yet provisioned your virtual host there, someone else might beat you to it and use it for an XSS attack.&lt;/p&gt;

&lt;p&gt;“Preventing subdomain takeovers is a matter of order of operations in lifecycle management for virtual hosts and DNS.”&lt;/p&gt;

&lt;p&gt;I now understand why Google Cloud make your “prove” your ownership of a domain before they’ll let you configure it to host e.g. a Cloud Run instance.

    &lt;p&gt;&lt;small&gt;&lt;/small&gt;Via &lt;a href="https://twitter.com/carboia/status/1429314879803072512"&gt;@carboia&lt;/a&gt;&lt;/small&gt;&lt;/p&gt;


    &lt;p&gt;Tags: &lt;a href="https://simonwillison.net/tags/dns"&gt;dns&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/security"&gt;security&lt;/a&gt;&lt;/p&gt;



</summary><category term="dns"/><category term="security"/></entry><entry><title>I stumbled across a nasty XSS hole involving DNS A records</title><link href="https://simonwillison.net/2021/Aug/22/xss-a-records/#atom-tag" rel="alternate"/><published>2021-08-22T05:27:34+00:00</published><updated>2021-08-22T05:27:34+00:00</updated><id>https://simonwillison.net/2021/Aug/22/xss-a-records/#atom-tag</id><summary type="html">
    
&lt;p&gt;&lt;strong&gt;&lt;a href="https://twitter.com/simonw/status/1429308904991727619"&gt;I stumbled across a nasty XSS hole involving DNS A records&lt;/a&gt;&lt;/strong&gt;&lt;/p&gt;
Found out today that an old subdomain that I had assigned an IP address to via a DNS A record was serving unexpected content—turned out I’d shut down the associated VPS and the IP had been recycled to someone else, so their content was now appearing under my domain. It strikes me that if you got really unlucky this could turn into an XSS hole—and that new server could even use Let’s Encrypt to obtain an HTTPS certificate for your subdomain.&lt;/p&gt;

&lt;p&gt;I’ve added “audit your A records” to my personal security checklist.


    &lt;p&gt;Tags: &lt;a href="https://simonwillison.net/tags/dns"&gt;dns&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/security"&gt;security&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/xss"&gt;xss&lt;/a&gt;&lt;/p&gt;



</summary><category term="dns"/><category term="security"/><category term="xss"/></entry><entry><title>nip.io</title><link href="https://simonwillison.net/2018/Dec/12/nipio/#atom-tag" rel="alternate"/><published>2018-12-12T18:18:09+00:00</published><updated>2018-12-12T18:18:09+00:00</updated><id>https://simonwillison.net/2018/Dec/12/nipio/#atom-tag</id><summary type="html">
    
&lt;p&gt;&lt;strong&gt;&lt;a href="http://nip.io/"&gt;nip.io&lt;/a&gt;&lt;/strong&gt;&lt;/p&gt;
"NIP.IO maps &lt;code&gt;&amp;lt;anything&amp;gt;.&amp;lt;IP Address&amp;gt;.nip.io&lt;/code&gt; to the corresponding &lt;code&gt;&amp;lt;IP Address&amp;gt;&lt;/code&gt;, even &lt;code&gt;127.0.0.1.nip.io&lt;/code&gt; maps to &lt;code&gt;127.0.0.1&lt;/code&gt;" - looks useful. &lt;code&gt;xip.io&lt;/code&gt; is a different service that does the same thing. Being able to put anything at the start looks handy for testing systems that handle different subdomains.


    &lt;p&gt;Tags: &lt;a href="https://simonwillison.net/tags/dns"&gt;dns&lt;/a&gt;&lt;/p&gt;



</summary><category term="dns"/></entry><entry><title>The death of a TLD</title><link href="https://simonwillison.net/2018/Jul/28/death-tld/#atom-tag" rel="alternate"/><published>2018-07-28T20:07:00+00:00</published><updated>2018-07-28T20:07:00+00:00</updated><id>https://simonwillison.net/2018/Jul/28/death-tld/#atom-tag</id><summary type="html">
    
&lt;p&gt;&lt;strong&gt;&lt;a href="https://blog.benjojo.co.uk/post/the-death-of-a-tld"&gt;The death of a TLD&lt;/a&gt;&lt;/strong&gt;&lt;/p&gt;
Sony have terminated their .xperia TLD. Ben Cox used Certificate Transparency logs to evaluate the 11 total TLDs that have been abandoned since the gTLD gold rush started—since HTTPS is becoming the default now these logs of issued certificates are a great indicator of which domains (or TLDs) are being actively used. The only deleted TLD with legitimate looking certificates (apparently for a  mail server) was .mcdonalds


    &lt;p&gt;Tags: &lt;a href="https://simonwillison.net/tags/certificates"&gt;certificates&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/dns"&gt;dns&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/domains"&gt;domains&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/tls"&gt;tls&lt;/a&gt;&lt;/p&gt;



</summary><category term="certificates"/><category term="dns"/><category term="domains"/><category term="tls"/></entry><entry><title>Use a .dev domain? Not anymore</title><link href="https://simonwillison.net/2017/Dec/6/dev/#atom-tag" rel="alternate"/><published>2017-12-06T18:42:04+00:00</published><updated>2017-12-06T18:42:04+00:00</updated><id>https://simonwillison.net/2017/Dec/6/dev/#atom-tag</id><summary type="html">
    
&lt;p&gt;&lt;strong&gt;&lt;a href="https://medium.engineering/use-a-dev-domain-not-anymore-95219778e6fd"&gt;Use a .dev domain? Not anymore&lt;/a&gt;&lt;/strong&gt;&lt;/p&gt;
Google  bought the .dev gTLD a few years ago for their own internal usage and in a few weeks time Chrome will start shipping a HSTS preload list rule that says that .dev must be served over HTTPS. This means that if you’re using a .dev domain in your /etc/hosts file you’ll need to switch to .test or .localhost (or set up a self-signed certificate) or your development environment will refuse to load.


    &lt;p&gt;Tags: &lt;a href="https://simonwillison.net/tags/dns"&gt;dns&lt;/a&gt;&lt;/p&gt;



</summary><category term="dns"/></entry><entry><title>DNS Prefetching Implications</title><link href="https://simonwillison.net/2011/Mar/9/dns/#atom-tag" rel="alternate"/><published>2011-03-09T22:54:00+00:00</published><updated>2011-03-09T22:54:00+00:00</updated><id>https://simonwillison.net/2011/Mar/9/dns/#atom-tag</id><summary type="html">
    
&lt;p&gt;&lt;strong&gt;&lt;a href="http://www.pinkbike.com/news/DNS-Prefetching-implications.html"&gt;DNS Prefetching Implications&lt;/a&gt;&lt;/strong&gt;&lt;/p&gt;
deviantart use a subdomain per user, which meant the DNS prefetching feature in Firefox and Chrome was costing them an extra 10 billion DNS queries per month. Disabling it with a meta tag saves them $1600/month in DNS service charges.


    &lt;p&gt;Tags: &lt;a href="https://simonwillison.net/tags/dns"&gt;dns&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/recovered"&gt;recovered&lt;/a&gt;&lt;/p&gt;



</summary><category term="dns"/><category term="recovered"/></entry><entry><title>jsondns</title><link href="https://simonwillison.net/2009/Dec/30/jsondns/#atom-tag" rel="alternate"/><published>2009-12-30T17:37:16+00:00</published><updated>2009-12-30T17:37:16+00:00</updated><id>https://simonwillison.net/2009/Dec/30/jsondns/#atom-tag</id><summary type="html">
    
&lt;p&gt;&lt;strong&gt;&lt;a href="http://dig.jsondns.org/"&gt;jsondns&lt;/a&gt;&lt;/strong&gt;&lt;/p&gt;
A JSONP API for making DNS queries, with a nice URL structure.


    &lt;p&gt;Tags: &lt;a href="https://simonwillison.net/tags/api"&gt;api&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/dns"&gt;dns&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/json"&gt;json&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/jsonp"&gt;jsonp&lt;/a&gt;&lt;/p&gt;



</summary><category term="api"/><category term="dns"/><category term="json"/><category term="jsonp"/></entry><entry><title>node.js</title><link href="https://simonwillison.net/2009/Nov/9/node/#atom-tag" rel="alternate"/><published>2009-11-09T23:25:47+00:00</published><updated>2009-11-09T23:25:47+00:00</updated><id>https://simonwillison.net/2009/Nov/9/node/#atom-tag</id><summary type="html">
    
&lt;p&gt;&lt;strong&gt;&lt;a href="http://nodejs.org/"&gt;node.js&lt;/a&gt;&lt;/strong&gt;&lt;/p&gt;
“Evented I/O for V8 JavaScript”—a JavaScript environment built on top of the super-fast V8 engine which provides event-based IO functionality for building highly concurrent TCP and HTTP servers. The API design is superb—everything is achieved using JavaScript events and callbacks (even regular file IO) and the small standard library ships with comprehensive support for HTTP and DNS. Overall it’s very similar to Twisted and friends, but JavaScript’s anonymous function syntax feels more natural than the Python equivalent. It compiles cleanly on Snow Leopard. Definitely a project to watch.


    &lt;p&gt;Tags: &lt;a href="https://simonwillison.net/tags/dns"&gt;dns&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/eventbasedio"&gt;eventbasedio&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/http"&gt;http&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/io"&gt;io&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/javascript"&gt;javascript&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/nodejs"&gt;nodejs&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/twisted"&gt;twisted&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/v8"&gt;v8&lt;/a&gt;&lt;/p&gt;



</summary><category term="dns"/><category term="eventbasedio"/><category term="http"/><category term="io"/><category term="javascript"/><category term="nodejs"/><category term="twisted"/><category term="v8"/></entry><entry><title>Imminent Death of the Net Predicted</title><link href="https://simonwillison.net/2009/Mar/5/drplokta/#atom-tag" rel="alternate"/><published>2009-03-05T09:50:12+00:00</published><updated>2009-03-05T09:50:12+00:00</updated><id>https://simonwillison.net/2009/Mar/5/drplokta/#atom-tag</id><summary type="html">
    
&lt;p&gt;&lt;strong&gt;&lt;a href="http://drplokta.livejournal.com/109267.html"&gt;Imminent Death of the Net Predicted&lt;/a&gt;&lt;/strong&gt;&lt;/p&gt;
Well, maybe not, but the way Windows Vista deals with round-robin DNS A records (using a new IPv6 algorithm from RFC3484 backported to IPv4) means that domains that serve up multiple A records to load balance between data centres will find that the IP nearest to the 192.168.* range will get the vast majority of Vista traffic.


    &lt;p&gt;Tags: &lt;a href="https://simonwillison.net/tags/dns"&gt;dns&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/microsoft"&gt;microsoft&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/networking"&gt;networking&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/vista"&gt;vista&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/windows"&gt;windows&lt;/a&gt;&lt;/p&gt;



</summary><category term="dns"/><category term="microsoft"/><category term="networking"/><category term="vista"/><category term="windows"/></entry><entry><title>Wikipedia over DNS</title><link href="https://simonwillison.net/2009/Jan/2/dgl/#atom-tag" rel="alternate"/><published>2009-01-02T11:29:22+00:00</published><updated>2009-01-02T11:29:22+00:00</updated><id>https://simonwillison.net/2009/Jan/2/dgl/#atom-tag</id><summary type="html">
    
&lt;p&gt;&lt;strong&gt;&lt;a href="https://dgl.cx/wikipedia-dns"&gt;Wikipedia over DNS&lt;/a&gt;&lt;/strong&gt;&lt;/p&gt;
Added to my ~/bin/ directory as dns-wikipedia.sh: host -t txt $1.wp.dg.cx


    &lt;p&gt;Tags: &lt;a href="https://simonwillison.net/tags/dns"&gt;dns&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/wikipedia"&gt;wikipedia&lt;/a&gt;&lt;/p&gt;



</summary><category term="dns"/><category term="wikipedia"/></entry><entry><title>Secret Geek A-Team Hacks Back, Defends Worldwide Web</title><link href="https://simonwillison.net/2008/Dec/3/secret/#atom-tag" rel="alternate"/><published>2008-12-03T11:10:22+00:00</published><updated>2008-12-03T11:10:22+00:00</updated><id>https://simonwillison.net/2008/Dec/3/secret/#atom-tag</id><summary type="html">
    
&lt;p&gt;&lt;strong&gt;&lt;a href="http://www.wired.com/techbiz/people/magazine/16-12/ff_kaminsky"&gt;Secret Geek A-Team Hacks Back, Defends Worldwide Web&lt;/a&gt;&lt;/strong&gt;&lt;/p&gt;
Wired’s take on the story of Dan Kaminsky’s breaking-the-internet DNS vulnerability. Horrible headline.


    &lt;p&gt;Tags: &lt;a href="https://simonwillison.net/tags/dan-kaminsky"&gt;dan-kaminsky&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/dns"&gt;dns&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/security"&gt;security&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/wired"&gt;wired&lt;/a&gt;&lt;/p&gt;



</summary><category term="dan-kaminsky"/><category term="dns"/><category term="security"/><category term="wired"/></entry><entry><title>Censoring the Internet at Paraguay</title><link href="https://simonwillison.net/2008/Jun/13/censoring/#atom-tag" rel="alternate"/><published>2008-06-13T15:24:40+00:00</published><updated>2008-06-13T15:24:40+00:00</updated><id>https://simonwillison.net/2008/Jun/13/censoring/#atom-tag</id><summary type="html">
    
&lt;p&gt;&lt;strong&gt;&lt;a href="http://public.icann.org/node/695"&gt;Censoring the Internet at Paraguay&lt;/a&gt;&lt;/strong&gt;&lt;/p&gt;
The state owned telecommunication company DNS hijacked the opposition party’s domain to point at a porn site during the election back in April. Maybe we don’t want a django.py vanity domain after all...


    &lt;p&gt;Tags: &lt;a href="https://simonwillison.net/tags/censorship"&gt;censorship&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/django"&gt;django&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/dns"&gt;dns&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/paraguay"&gt;paraguay&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/python"&gt;python&lt;/a&gt;&lt;/p&gt;



</summary><category term="censorship"/><category term="django"/><category term="dns"/><category term="paraguay"/><category term="python"/></entry><entry><title>ISPs' Error Page Ads Let Hackers Hijack Entire Web</title><link href="https://simonwillison.net/2008/Apr/21/isps/#atom-tag" rel="alternate"/><published>2008-04-21T06:51:55+00:00</published><updated>2008-04-21T06:51:55+00:00</updated><id>https://simonwillison.net/2008/Apr/21/isps/#atom-tag</id><summary type="html">
    
&lt;p&gt;&lt;strong&gt;&lt;a href="http://blog.wired.com/27bstroke6/2008/04/isps-error-page.html"&gt;ISPs&amp;#x27; Error Page Ads Let Hackers Hijack Entire Web&lt;/a&gt;&lt;/strong&gt;&lt;/p&gt;
Earthlink in the US served “helpful” links and ads on subdomains that failed to resolve, but the ad serving pages had XSS holes which could be used to launch phishing attacks the principle domain (and I imagine could be used to steal cookies, although the story doesn’t mention that). Seems like a good reason to start using wildcard DNS to protect your subdomains from ISP inteference.

    &lt;p&gt;&lt;small&gt;&lt;/small&gt;Via &lt;a href="http://rc3.org/2008/04/20/the-risks-of-monkeying-with-dns/"&gt;Rafe&lt;/a&gt;&lt;/small&gt;&lt;/p&gt;


    &lt;p&gt;Tags: &lt;a href="https://simonwillison.net/tags/dns"&gt;dns&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/earthlink"&gt;earthlink&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/isp"&gt;isp&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/security"&gt;security&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/subdomains"&gt;subdomains&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/wildcarddns"&gt;wildcarddns&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/xss"&gt;xss&lt;/a&gt;&lt;/p&gt;



</summary><category term="dns"/><category term="earthlink"/><category term="isp"/><category term="security"/><category term="subdomains"/><category term="wildcarddns"/><category term="xss"/></entry><entry><title>UK domain registrar 123-Reg crashes and burns, taking its customers with it</title><link href="https://simonwillison.net/2007/Nov/18/uk/#atom-tag" rel="alternate"/><published>2007-11-18T11:24:07+00:00</published><updated>2007-11-18T11:24:07+00:00</updated><id>https://simonwillison.net/2007/Nov/18/uk/#atom-tag</id><summary type="html">
    
&lt;p&gt;&lt;strong&gt;&lt;a href="http://blogs.cnet.com/8301-13505_1-9819551-16.html"&gt;UK domain registrar 123-Reg crashes and burns, taking its customers with it&lt;/a&gt;&lt;/strong&gt;&lt;/p&gt;
I was hit by this yesterday: can anyone recommend an alternative DNS host with a really easy to use interface (I’ve made mistakes modifying DNS in the past) and rock-solid reliability?


    &lt;p&gt;Tags: &lt;a href="https://simonwillison.net/tags/123reg"&gt;123reg&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/dns"&gt;dns&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/domains"&gt;domains&lt;/a&gt;&lt;/p&gt;



</summary><category term="123reg"/><category term="dns"/><category term="domains"/></entry><entry><title>Email addresses your OpenID via DNS</title><link href="https://simonwillison.net/2007/Sep/30/sam/#atom-tag" rel="alternate"/><published>2007-09-30T21:36:27+00:00</published><updated>2007-09-30T21:36:27+00:00</updated><id>https://simonwillison.net/2007/Sep/30/sam/#atom-tag</id><summary type="html">
    
&lt;p&gt;&lt;strong&gt;&lt;a href="http://intertwingly.net/blog/2007/09/28/Email-addresses-your-OpenID-via-DNS"&gt;Email addresses your OpenID via DNS&lt;/a&gt;&lt;/strong&gt;&lt;/p&gt;
Sam Ruby has warmed to the idea of making e-mail addresses usable as OpenIDs via a DNS SRV record.


    &lt;p&gt;Tags: &lt;a href="https://simonwillison.net/tags/dns"&gt;dns&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/email"&gt;email&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/openid"&gt;openid&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/sam-ruby"&gt;sam-ruby&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/srv"&gt;srv&lt;/a&gt;&lt;/p&gt;



</summary><category term="dns"/><category term="email"/><category term="openid"/><category term="sam-ruby"/><category term="srv"/></entry><entry><title>dnspython</title><link href="https://simonwillison.net/2007/Jul/1/dnspython/#atom-tag" rel="alternate"/><published>2007-07-01T11:55:34+00:00</published><updated>2007-07-01T11:55:34+00:00</updated><id>https://simonwillison.net/2007/Jul/1/dnspython/#atom-tag</id><summary type="html">
    
&lt;p&gt;&lt;strong&gt;&lt;a href="http://www.dnspython.org/"&gt;dnspython&lt;/a&gt;&lt;/strong&gt;&lt;/p&gt;
Python DNS toolkit—seems like the kind of thing that should be in the standard library.


    &lt;p&gt;Tags: &lt;a href="https://simonwillison.net/tags/dns"&gt;dns&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/python"&gt;python&lt;/a&gt;&lt;/p&gt;



</summary><category term="dns"/><category term="python"/></entry><entry><title>What I did at Hack Day</title><link href="https://simonwillison.net/2007/Jun/19/blog/#atom-tag" rel="alternate"/><published>2007-06-19T10:32:14+00:00</published><updated>2007-06-19T10:32:14+00:00</updated><id>https://simonwillison.net/2007/Jun/19/blog/#atom-tag</id><summary type="html">
    
&lt;p&gt;&lt;strong&gt;&lt;a href="http://blog.johnmckerrell.com/2007/06/17/what-i-did-at-hack-day/"&gt;What I did at Hack Day&lt;/a&gt;&lt;/strong&gt;&lt;/p&gt;
John McKerrell made a tool for updating your FireEagle location through a DNS query, useful for sneaking around for-pay WiFi nodes.


    &lt;p&gt;Tags: &lt;a href="https://simonwillison.net/tags/dns"&gt;dns&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/fireeagle"&gt;fireeagle&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/hackdaylondon"&gt;hackdaylondon&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/john-mckerrell"&gt;john-mckerrell&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/wifi"&gt;wifi&lt;/a&gt;&lt;/p&gt;



</summary><category term="dns"/><category term="fireeagle"/><category term="hackdaylondon"/><category term="john-mckerrell"/><category term="wifi"/></entry><entry><title>IE and 2-letter domain-names</title><link href="https://simonwillison.net/2007/Feb/15/ie/#atom-tag" rel="alternate"/><published>2007-02-15T00:33:13+00:00</published><updated>2007-02-15T00:33:13+00:00</updated><id>https://simonwillison.net/2007/Feb/15/ie/#atom-tag</id><summary type="html">
    
&lt;p&gt;&lt;strong&gt;&lt;a href="http://therealcrisp.xs4all.nl/blog/2007/02/12/ie-and-2-letter-domain-names/"&gt;IE and 2-letter domain-names&lt;/a&gt;&lt;/strong&gt;&lt;/p&gt;
IE won’t let you set a cookie on XX.YY, where YY is anything other than .pl or .gr. Other browsers have better exception lists.

    &lt;p&gt;&lt;small&gt;&lt;/small&gt;Via &lt;a href="http://diveintomark.org/archives/2007/02/14/links-for-2007-02-14"&gt;Mark Pilgrim&lt;/a&gt;&lt;/small&gt;&lt;/p&gt;


    &lt;p&gt;Tags: &lt;a href="https://simonwillison.net/tags/cookies"&gt;cookies&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/dns"&gt;dns&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/internet-explorer"&gt;internet-explorer&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/mark-pilgrim"&gt;mark-pilgrim&lt;/a&gt;&lt;/p&gt;



</summary><category term="cookies"/><category term="dns"/><category term="internet-explorer"/><category term="mark-pilgrim"/></entry></feed>