What?!

It is yet another of those baroque standards which spits out things like:

cid.uri.arpa.
;;       order pref flags service        regexp           replacement
IN NAPTR 100   10   ""    ""  "!^cid:.+@([^\.]+\.)(.*)$!\2!i"    .

Essentially, it is a way to store contact details within a DNS record (rather than in a WHOIS record).

Back in the early 2000s, the dotTel company opened the .tel TLD with a promise that it could be used to store your contact details in DNS⁰. The idea was simple, rather than storing my phone number in your address book, you'd store my domain name - https://edent.tel/

If I updated my phone number, changed my avatar, or deleted an old email address - your address book would automatically update via DNS. Nifty!

If you didn't know a company's phone number, you'd dial example.com on your phone and it would grab the phone numbers from DNS. Wowsers trousers!

You can see an example by running:

dig justin.tel NAPTR

You'll get back something like:

NAPTR   100 101 "u" "E2U+web:http" "!^.*$!http://justinkhayward.com!" 

A phone number stored in a NAPTR would look something like:

NAPTR   100 100 "u" "E2U+voice:tel" "!^.*$!tel:+442074676450!" .

Brilliant! But there's a problem - aside from the somewhat obtuse syntax! - and that problem is spam.

Those of you old enough to remember putting your unexpurgated contact details into WHOIS know that the minute it went live you were bombarded with sales calls and scammy emails. So putting your details directly into DNS is a bad idea, right?

.tel thought they'd come up with a clever hack to prevent that. As they explain in the .tel privacy paper, records can be individually encrypted.

• Alice has her contact details on alice.tel
• Bob has his contact details on bob.tel
• Alice agrees to share her phone number with Bob.
• Alice looks up Bob's public key from bob.tel.
• Alice encrypts her phone number.
• Alice generates a new DNS record specifically for Bob - bob123456.alice.tel
• Alice shares the name of the new record with Bob.
• Bob downloads the NAPTR from bob123456.alice.tel and decrypts it with his private key.
• Bob periodically checks for updates.
• Alice can decide to revoke Bob's access by removing the data or subdomain.

Clever! If convoluted. You can read more about the way friendships and public keys were managed and some more technical details.

Are there better ways?

Multi Recipient Encryption

When people say "you can't give Government a secret key to your private messages" they are technically incorrect¹. Multi Recipient Encryption is a thing.

Here's a very simplified and subtly wrong explanation:

• Alice creates a temporary public/private keypair.
• Alice encrypts some text with her temporary public key - resulting in e.
• Alice encrypts the temporary private key with Bob's public key - resulting in k1.
• Alice encrypts the temporary private key with Charlie's public key - resulting in k2.
• Alice publishes the concatenation of e+k1+k2
• Bob downloads the file, decrypts his version of the key, and uses that to decrypt the message.
• Charlie does the same.

In this way, both recipients are able to decipher the text but no one else can. So can we just shove an encrypted record in the NAPTR? Not quite.

There are two main problems with this for DNS purposes.

1. The encrypted size grows with every recipient.
2. Every time a new recipient is added, everyone needs to download the data again even if it is unchanged.

Generally speaking, DNS records are a maximum of 255 characters - although they can be concatenated.

An extra record could be used to say when the plaintext was last updated - which would let existing recipients know not to download it again.

Monitoring for changes would allow a user to know roughly how many recipients had been added or removed.

What other ways could there be?

What else could be done?

Here's the user story.

• I want a friend to subscribe to my [phone|email|street|social media] address(es).
• I must be able to pre-approve access.
• When I change my address, my friend should get my new details.
• I need to be able to revoke people's access.
• This should be done via DNS².

Using an API this would be playing on easy mode. A friend (or rather, their app) would request an API key from my service. I would approve it, and then ✨magic✨.

DNS isn't technically an API although, with enough effort, you could make it behave like one³.

So - how would you do it?

Domain names, like www.example.com usually resolve to servers. As much as we think of "the cloud" as being some intangible morass of ethereal Turing-machines floating in probability space, the more prosaic reality is that they're just boxen in data centres. They have a physical location.

Got a tricky machine which is playing silly-buggers? Wouldn't it be nice to know exactly where it is? That way you can visit and give it some percussive maintenance.

Enter the DNS LOC record!

The snappily titled RFC 1876 is an experimental standard. It allows you to create a DNS record which specifies the latitude and longitude of your server. Of course, some data-centres are very tall and some are underground. So it also contains an altitude parameter.

The standard allows for a minimum altitude of -100,000 metres - deep enough for any bunker! The maximum altitude is 42,849,672 metres which is high enough to allow it to be used on satellites in geostationary orbit.

So, as a bit of fun, I decided to create where-is-the-iss.dedyn.io

It isn't a website. You can't ping it. There's no way to interact with it except by using DNS. Yup! You can use a DNS query to get the (approximate) location of the International Space Station!

Linux and Mac users⁰ can run:

dig where-is-the-iss.dedyn.io LOC

And receive back the latest position of the ISS:

;; ANSWER SECTION:
where-is-the-iss.dedyn.io. 1066 IN  LOC 47 24 53.500 N 66 12 12.070 W 430520m 10000m 10000m 10000m

The DNS records are updated every 15 minutes on a best-effort basis¹.

How

The lovely people at N2YO have a website which allows you to track loads of objects in orbit. They also have an easy to use API with a generous free tier.

Calling https://api.n2yo.com/rest/v1/satellite/positions/25544/0/0/0/1/&apiKey=_____ gets back the latest position:

{
    "info": {
        "satname": "SPACE STATION",
        "satid": 25544,
        "transactionscount": 7
    },
    "positions": [
        {
            "satlatitude": -21.25409321,
            "satlongitude": 140.3335763,
            "sataltitude": 420.09,
            "azimuth": 292.92,
            "elevation": -70.95,
            "ra": 202.69300845,
            "dec": -32.16097472,
            "timestamp": 1751366048,
            "eclipsed": true
        }
    ]
}

Note that the altitude is in Km, whereas the LOC format requires m.

The latitude and longitude are in decimal format - they need to be converted to Degrees, Minutes, and Seconds.

There were only a few free domain name providers who offer an API for updating LOC records. I went for deSEC a charity from Berlin. They have comprehensive API documentation.

Adding the initial LOC record is done with:

curl https://desec.io/api/v1/domains/where-is-the-iss.dedyn.io/rrsets/ \
    --header "Authorization: Token _______" \
    --header "Content-Type: application/json" --data @- <<< \
    '{"type": "LOC", "records": ["40 16 25.712 S 29 32 36.243 W 427550m 0.00m 10000m 10m"], "ttl": 900}'

However, updating the record is a little trickier. it needs to be sent as an HTTP PATCH to a subtly different URl. The PATCH only needs to send the data which have changed.

curl -X PATCH https://desec.io/api/v1/domains/where-is-the-iss.dedyn.io/rrsets/@/LOC/ \
    --header "Authorization: Token _______" \
    --header "Content-Type: application/json" --data @- <<< \
    '{"records": ["40 16 25.712 S 29 32 36.243 W 427550m 0.00m 10000m 10m"]}'

I set the Time To Live at 900 seconds. Every 15 minutes my code runs to update the record². That keeps me well within the API limits for both services. I could add TXT records showing when it was last updated, or other sorts of unstructured data, but I think this is enough for a quick proof-of-concept.

There you have it! A complex and silly way to demonstrate how DNS can be used to hold the most unlikely of records³. Say, I wonder how you'd represent the co-ordinates of the Mars Rover…?

Further Reading

For more DNS weirdness, please see my other posts:

• BIMI - SVG in DNS TXT WTF?!
• Why you can't dig Switzerland

The pitch is simple. A website owner places a single new line in their HTML's <head> - something like this:

<link rel="monetization" href="https://wallet.example.com/edent" />

That address is a "Payment Pointer". As a user browses the web, their browser takes note of all the sites they've visited. At the end of the month, the funds in the user's digital wallet are split proportionally between the sites which have enabled WebMonetization. The user's budget is under their control and there are various technical measures to stop websites hijacking funds.

This could be revolutionary⁰.

But there are some interesting fraud angles to consider. Let me give you a couple of examples.

Pointer Hijacking

Suppose I hacked into a popular site like BBC.co.uk and surreptitiously included my link in their HTML. Even if I was successful for just a few minutes, I could syphon off a significant amount of money.

At the moment, the WebMonetization plugin only looks at the page's HTML to find payment pointers. There's no way to say "This site doesn't use WebMonetization" or an out-of-band way to signal which Payment Pointer is correct. Obviously there are lots of ways to profit from hacking a website - but most of them are ostentatious or require the user to interact. This is subtle and silent.

How long would it take you to notice that a single meta element had snuck into some complex markup? When you discover it, what can you do? Money sent to that wallet can be transferred out in an instant. You might be able to get the wallet provider to freeze the funds or suspend the account, but that may not get you any money back.

Similarly, a Web Extension like Honey could re-write the page's source code to remove or change an existing payment pointer.

Possible Solutions

Perhaps the username associated with a Payment Pointer should be that of the website it uses? something like href="https://wallet.example.com/shkspr.mobi"

That's superficially attractive, but comes with issues. I might have several domains - do I want to create a pointer for each of them?

There's also a legitimate use-case for having my pointer on someone else's site. Suppose I write a guest article for someone - their website might contain:

<link rel="monetization" href="https://wallet.example.com/edent" />
<link rel="monetization" href="https://wallet.coin_base.biz/BigSite" />

Which would allow us to split the revenue.

Similarly, a site like GitHub might let me use my Payment Pointer when people are visiting my specific page.

So, perhaps site owners should add a .well-known directive which lists acceptable Pointers? Well, if I have the ability to add arbitrary HTML to a site, I might also be able to upload files. So it isn't particularly robust protection.

Alright, what are other ways typically used to prove the legitimacy of data? DNS maybe? As the popular meme goes:

@atax1a@infosec.exchange

mx alex tax1a - 2020 (5)

@jwz @grumpybozo just one more public key in a TXT record, that'll fix email, just gotta add one more TXT record bro

---

Someone with the ability to publish on a website is less likely to have access to DNS records. So having (yet another) DNS record could provide some protection. But DNS is tricky to get right, annoying to update, and a pain to repeatedly configure if you're constantly adding and removing legitimate users.

Reputation Hijacking

Suppose the propaganda experts in The People's Republic of Blefuscu decide to launch a fake site for your favourite political cause. It contains all sorts of horrible lies about a political candidate and tarnishes the reputation of something you hold dear. The sneaky tricksters put in a Payment Pointer which is the same as the legitimate site.

"This must be an official site," people say. "Look! It even funnels money to the same wallet as the other official sites!"

There's no way to disclaim money sent to you. Perhaps a political opponent operates an illegal Bonsai Kitten farm - but puts your Payment Pointer on it.

"I don't squash kittens into jars!" You cry as they drag you away. The police are unconvinced "Then why are you profiting from it?"

Possible Solutions

A wallet provider needs to be able to list which sites are your sites.

You log in to your wallet provider and fill in a list of websites you want your Payment Pointer to work on. Add your blog, your recipe site, your homemade video forum etc. When a user browses a website, they see the Payment Pointer and ask it for a list of valid sites. If "BonsaiKitten.biz" isn't on there, no payment is sent.

Much like OAuth, there is an administrative hassle to this. You may need to regularly update the sites you use, and hope that your forgetfulness doesn't cost you in lost income.

Final Thoughts

I'm moderately excited about WebMonetization. If it lives up to its promises, it could unleash a new wave of sustainable creativity across the web. If it is easier to make micropayments or donations to sites you like, without being subject to the invasive tracking of adverts, that would be brilliant.

The problems I've identified above are (I hope) minor. Someone sending you money without your consent may be concerning, but there's not much of an economic incentive to enrich your foes.

Think I'm wrong? Reckon you've found another fraudulent avenue? Want to argue about whether this is a likely problem? Stick a comment in the box.

I thought it might be fun to grab all the BIMI images from the most popular websites, so I can potentially use them in my SuperTinyIcons project.

BIMI images are SVGs. Links to a site's BIMI are stored in a domain's DNS records. All BIMI records must be on a default._bimi. subdomain.

If you run dig TXT default._bimi.linkedin.com you'll receive back:

;; ANSWER SECTION:
default._bimi.linkedin.com. 3600 IN TXT "v=BIMI1; l=https://media.licdn.com/media/AAYQAQQhAAgAAQAAAAAAABrLiVuNIZ3fRKGlFSn4hGZubg.svg; a=https://media.licdn.com/media/AAYAAQQhAAgAAQAAAAAAALe_JUaW1k4JTw6eZ_Gtj2raUw.pem;"

Awesome! We can grab the .svg URl and download the file.

Getting a list of BIMI enabled domains is difficult. Thankfully, Freddie Leeman has done some excellent analysis work and was happy to share a list of over 7,000 domains which have BIMI.

Let's get cracking with a little Python. First up, install DNSPython if you don't already have it.

This gets the TXT record from the domain name:

import socket
import dns.resolver

response = dns.resolver.query('default._bimi.linkedin.com', 'TXT')
result = response.rrset.to_text()
print(result)

There are various ways of extracting the URl. I decided to be lazy and use a regex. Sue me.

import re

pattern = r'l=(https[^;"]*[;"])'
match = re.search(pattern, result)
if match:
   # Remove the trailing semicolon or quote mark
   url = match.group(1).rstrip(';\"')
   print(f'Matched URL: {url}')
else:
   print(f'No match: {result}')

Putting it all together, this reads in the list of domains, finds the BIMI TXT record, grabs the URl, and saves the SVG.

import socket
import dns.resolver
import re
import requests

headers = {
  'User-Agent': 'Mozilla/5.0 (Windows NT 10.0; rv:91.0) Gecko/20100101 Firefox/91.0'
}

pattern = r'l=(https[^;"]*[;"])'

domain_file = open('domains.txt', 'r')
domains = domain_file.readlines()
domains.sort()

for domain in domains:
   bimi_domain = "default._bimi." + domain.strip()
   try:
      response = dns.resolver.query(bimi_domain, 'TXT')
      result = response.rrset.to_text()
      match = re.search(pattern, result)
      if match:
         # Remove the trailing semicolon or quote mark
         svg_url = match.group(1).rstrip(';\"')
         print(f'Downloading: {svg_url}')
         try:
            svg = requests.get(svg_url, allow_redirects=True, timeout=30, headers=headers)
            open(domain.strip() +'.svg', 'wb').write(svg.content)
         except:
            print(f'Error with {domain}: {result}')
      else:
         print(f'No match from {domain}: {result}')
   except:
      print(f'DNS error with {bimi_domain}')

Obviously, it could be made a lot more efficient and download the files in parallel.

I found a few bugs in various BIMI implementations, including:

• ted.com and homeadvisor.com uses a http URl
• consumerreports.org and sleepfoundation.org has a misplaced space in their TXT record
• audubon.org had an invalid certificate
• mac.com was blank - as was discogs.com, livechatinc.com, icloud.com, me.com, lung.org, miro.com, protonmail.ch and many others.
• alabama.gov had a timeout - as did nebraska.gov, uclahealth.org and several others.
• politico.com had a 404 for their BIMI - as do lots of others.
• coopersurgical.com is 8MB!
• There are loads of SVGs which bust the 32KB maximum size requirement - some by multiple megabytes.

I might spend some time over the next few weeks optimising the code and looking for any other snafus. I didn't find any with ECMAScript in them. Yet!

The answer is... A big list. The HTTP Strict Transport Security (HSTS) list is a list of domain names which have told Google that they always want their website served over https. If the user tries to manually request the insecure version, the browser won't let them. This means that a user's connection to, for example, their bank cannot be hijacked. A dodgy WiFi network cannot force the user to visit an insecure and fraudulent version of a site.

After about a decade of use, the list is now 14MB in size, with around 130,000 entries in it. You can view the list online or download it.

The format is relatively straightforward:

{
 "name": "example.com",
 "policy": "bulk-1-year",
 "mode": "force-https",
 "include_subdomains": true 
},

When the list is updated, Chrome creates a trie with Huffman coding compression - so it doesn't have to parse that monster file each time.

A rummage inside

The most popular (over 1,000 entries) TLDs / Public Suffixes are:

After .com, the free .tk domain names absolutely dominate. I wonder how many of them are fraudulent?

There are 2,676 .uk domain names - only 537 of which aren't on .co.uk.

Going a bit further, there are 418 IDNs (which start with xn--).

And about 187 have "porn" in the domain.

You can't really extrapolate much from this as a data set. Lots of the domains seem to have expired or otherwise no longer work. Reading around https://hstspreload.org it notes that because this list is hard-coded into Chrome it can take months before a site is added. Similarly, removal can take a long time as well.

I can't help feeling that there should be a better way to manage all this though.

http://↑↑↓↓←→←→ba.tk/

Yup, copy and paste that into your browser and it will resolve. Update: The free .tk domain service no longer works.

For now, it just redirects to a Wikipedia article. If you can think of a better use for it, please let me know. I wonder how mail clients do at sending emails to it?

Interestingly, Chrome sometimes throws up a warning that this is a "Fake Site" saying "Attackers sometimes mimic sites by making small, hard-to-see changes to the URL." I suspect that's because of the mixture of English characters and symbols.

I was inspired by the (slightly weird) http://↓.tk website.

Way back in the early 2000s, I started this website - shkspr.mobi. A few years later, I added a blog. I could have used the main domain, or created a subdomain like blog.shkspr.mobi. In the end, I chose a subdirectory of shkspr.mobi/blog

I don't know if that was the right choice back then, but it is looking like the wrong choice now.

I want to be a "first class" citizen of the Fediverse. I want a dozen different apps installed on my little slice of the Internet. I want a fairly consistent online identity. What's the best way to do that?

Buy a new domain for every app!

No. This is impractical for two reasons.

1. It's expensive.
2. Nothing ties together my_awesome_photos.biz to read_my_blog.com.

Subdirectories

I currently have /blog. Should I also have /mastodon and /pixelfed and /yet_another_cool_service and...

Maybe? The problem is, most of these new services assume that they're going to be on their own domain. Usernames are based on domains - so I guess I'd end up with @edent-mastodon@shkspr.mobi and @edent-pixelfed@shkspr.mobi? That just looks ugly.

Subdomains

Adding sub-domains is free and easy.

mastodon.shkspr.mobi and pixelfed.shkspr.mobi - done!

But there are a couple of issues.

1. Do I want to name them after the app, or something more generic in case I switch later? Perhaps posts.shkspr.mobi and pictures.shkspr.mobi?
2. Do users understand that they need to follow @edent@location.shkspr.mobi for my Foursquare-style check-ins and @edent@beer.shkspr.mobi for my beer reviews?

One Domain To Rule Them All

Perhaps I'll just have everything on my main domain? That also comes with a few problems! I'll need to install the apps somewhere and then work out how to redirect users to the correct app based on... what? And it still doesn't resolve the username issue.

Just treat everything as a single ActivityPub feed

I think this is where I'm heading.

I've written before about my perfect social network.

• I post items tagged work, tech, sport, politics, etc.
• You decide which of those channels you want to subscribe to.

If you only want to read my sport punditry, subscribe to that channel. If you want everything except my political views, ignore that specific channel.

I could publish everything on a single feed. It is then up to you or your client to work out how to filter that.

I'm still not sure how that would work! Perhaps clients will be smart enough to ignore statuses which don't fit their model? Perhaps users will manually choose what to follow?

That's sort of how Aaron Parecki's unified view works.

What would you do?

If you've done this successfully - or have particularly strong opinions - please let me know!

And that got me wondering… what other abuses of the Punycode algorithm can I whack into DNS? Well, here's some I whipped up using FreeNom - they offer free domain names on the .ga TLD (and a few others) and are very liberal in accepting Punycode domains.

There's millions of domains all under one roof

For some reason, the children's retailer "Toys 'R' Us" uses a backwards R in their logo. Presumably because they think kids are stupid and don't know how to form letters.

Or, maybe they're big fans of the reversed letter ᴙ? Either way, Punycode supports that!

I present to you:

https://ToysᴙUs.ga/

Yup! Copy and paste that and it'll work. Webkit based browsers should show the ᴙ in the URl bar - others might show Punycode.

NB: This is not the Cyrillic ya - it is, instead, a homoglyph.

Touch a Touch a Touch a Touch Me

I think this is the world's first domain name written in Braille.

https://⠠⠃⠗⠇.ga

That uses Unified English Braille - with a Grade Two contraction.

Interestingly, I couldn't get any browser to display Braille in the URl bar. The other domains on this page work - but this one just gave the Punycode representation xn--9iii1c8a.ga

These domains go up to 11

Without a doubt, the loudest band in rock and/or roll are the legendary "Spın̈al Tap" - note the dotless I and the heavy-metal umlaut over the N.

Again, Punycode supports that!

https://Spın̈alTap.ga/

Interestingly, this was the only domain that Firefox displayed without converting to Punycode.

Some kind of Einstein

This one combines another trick. As I pointed out in my post about buying a single character domain name, we can abuse Unicode normalisation in our domain names. So the Unicode Superscript block gets automatically converted to regular text.

This means we can have a domain of:

https://e꞊mc².ga/

The "equals" is really "modifier letter short equals sign (U+A78A)" which, surprisingly, doesn't undergo normalisation.

What didn't work

It's always good to share the experiments which didn't produce anything useful. Negative results are results too!

• Zalgo Text doesn't work.
• 🂡 and other playing cards don't work.
• I figured trying to use something like xn--hsbccom-oy9d61a would probably get me banned from the Internet pretty quickly!
• This didn't open up a portal to the Dark Dimension from which all madness stems. Oh well.

Up next?

If you manage to generate any weird and wonderful domain names, please leave a comment.

So I recently started renewing them for as long as possible. It turns out that most domains can be registered for a maximum of 10 years⁰.

A typical .uk domain will set you back the thick end of a hundred quid if you want it for a decade! Can I find something cheaper?

There are some free domain services like freenom.com. They'll give you a .ml domain for free. But you'll have to log in every year if you want to renew it. And, as I recently found out, they will sometimes just take away your free name and try to charge you for it.

Similarly, .pp.ua offers free domains to people in Ukraine. They can only be registered for a single year at a time though.

If you want a Top Level Domain which you can renew for a decade, the cheapest appears to be .feedback which costs a smidge under £13 for 10 years.

But, of course, there is a catch! You have to use the .feedback website hosting service which, frankly, looks rubbish.

It doesn't seem to be receiving any updates. I've tried contacting them to see if any improvements are planned, but didn't receive a reply. You can't set your own nameservers, nor can you add MX records or anything useful like that.

The cheapest fully functional domain which you can register for a decade appears to be .cyou from Sav.com at about £23 (US$27.60).

Up next is .stream from Porkbun - you can buy a 10 year domain for ~£30 (US$35.60).

As pointed out on the HackerNews discussion on this post, you can register a .in domain for 10 years for £37.

So, there you have it. For between £23 - £40 you can buy a useful domain name which will stay registered to you for a decade. If you can find anything cheaper - please let me know in the comments.

Of course, paying for hosting for a decade is a different matter!

BIMI (Brand Indicators for Message Identification) is a new standard that can curb the issue of online impersonators. ... BIMI is a new standard that enables you to include your company’s logo alongside the emails you send. That way, your brand stands out among other emails, and your customers are sure that the emails are legitimate.

How To Create a BIMI record

Wow! Much innovation! Such security! There's no way a fraudster could put a bank's logo on their dodgy spam, right?

*sigh*

OK, so in order for this not to be abused, most email providers require brands to pay for an expensive Verified Mark Certificate (VMC) - a digital certificate which says that you are the trademark owner of the logo.

How much does it cost?

US$1,499.00

Per year! No wonder no one is using BIMI.

Then it's just a case of sticking something like this in your DNS TXT records:

v=BIMI1;
l=https://example.com/logo.svg;
a=https://example.com/certificate.pem

That's nice, and all, but I don't think I've ever seen one in the wild. Even the BIMI Group haven't bothered paying for the VMC!

One of the few organisations who have set this up correctly is DigiCert. Because they're one of the orgs you can buy this service from.

dig txt default._bimi.digicert.com will get you:

;; ANSWER SECTION:
default._bimi.digicert.com. 3600 IN TXT 
   "v=BIMI1; 
    l=https://www.digicert.com/resources/DigiCertLogo_WhiteOnBlue.svg; 
    a=https://cacerts.digicert.com/digicert_com_vmc_WhiteOnBlue.pem"

You can read the PEM certificate using: openssl x509 -in digicert_com_vmc_WhiteOnBlue.pem -noout -text

Inside, you'll find this nugget:

data:image/svg+xml;base64,H4sIAAAAAAAACo1XXW/jRhJ8tn8FwzwF4NDzzaFhb3BRckmADRAgwL4eHFoxhePZhqiVN/…

Hmmm… H4sIAAA is the start of a base64 encoded zipped string.

Once decoded and unzipped, we find… the SVG logo!

It's fairly obvious that people want a nice logo next to their email in your inbox. If you're on GMail, you're probably used to seeing your friends faces smiling back at you. But that only works if everyone is on the same email system. So BIMI is a reasonable idea for a cross-provider standard.

Downsides

There are several problems with BIMI.

The first is cost. If it were free then AbsolutelyYourBank@trust_me.biz could use the HSBC logo with impunity. I'm sure an extremely dedicated fraudster could spend the $1.5k and fool DigiCert into certifying their illegitimate use of someone else's logo. But it's unlikely to happen.

There's also a privacy issue. Because the BIMI logos are stored on a website, the website owner could track when they were downloaded and use that to work out who was reading their emails. Thankfully, both GMail and Yahoo proxy the images - so the provider doesn't get any additional analytics benefit.

Support is poor in GMail. Here's an email from LinkedIn: As you can see, the BIMI logo is displayed by the email address - but is absent in the contact view.

Finally, DNS TXT records are limited to 255 bytes of data. That's why logos are restricted to being (fairly short) links.

Is it worth it?

I think the marketplace of ideas has answered this with a fairly resounding "no".

You can track adoption at BIMIBRadar.

It would be great to stick your face, logo, or picture next to every email you send. But the risk from fraudsters is just too high.

The cost of certification is necessary to stop misuse - but that also means that smaller brands and individuals are locked out. Which isn't what we want from an open Internet.

There's no worldwide brand registry which can certify your use of an image. And, even if there were, it would be a huge single-point-of-failure.

The conversation about BIMI chugs on in IETF mailing lists. Do get involved if you think you have something of value to add.

The humble unix dig command allows you to query all sort of DNS information. For example, to see name server records for the BBC website, you can run:

dig bbc.co.uk NS

Which will get you:

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35614
;; flags: qr rd ra; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 17

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 097db2ee4c92b84982083ecf62b5b5f2007906e616035113 (good)
;; QUESTION SECTION:
;bbc.co.uk.         IN  NS

;; ANSWER SECTION:
bbc.co.uk.      900 IN  NS  ddns1.bbc.com.
bbc.co.uk.      900 IN  NS  dns0.bbc.co.uk.
bbc.co.uk.      900 IN  NS  ddns1.bbc.co.uk.
...

And a whole lot more. But you can go further down the DNS tree. What are the nameservers for .co.uk?

dig co.uk NS

And you'll get your answer. You can go one further and see the nameservers for the Top Level Domain:

dig uk NS

Which replies with:

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54061
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 17

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 880427eda8ff71de2ab4f43862b5b65f95e317d29cc10a8e (good)
;; QUESTION SECTION:
;uk.                IN  NS

;; ANSWER SECTION:
uk.         159692  IN  NS  nsc.nic.uk.
uk.         159692  IN  NS  dns1.nic.uk.
uk.         159692  IN  NS  nsd.nic.uk.
...

And that works with every TLD. Countries like de, generic names like museum, and internationalised domains like 在线. All of them work!

Except Switzerland.

Switzerland's country code is ch - after the name Confoederatio Helvetica. Let's run the dig on it: dig ch NS

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 31910
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

We have been refused and warned. But why does this only happen with Switzerland?

The blame - as with most modern ills - lies in the mid-1970s. The Bee Gees were storming the charts with "Jive Talkin'", the Rocky Horror Picture Show was gathering a cult following, and MIT scientists were causing chaos. Literally.

Chaosnet was an early network protocol designed for local networks. It was technically very clever but, sadly, never really took off.

However, it found its way into DNS records. Let's go back to the answer to dig bbc.co.uk NS:

;; ANSWER SECTION:
bbc.co.uk.      900 IN  NS  ddns1.bbc.com.

OK, the first part is the domain name. The number is the TTL. The IN is the class. The NS says this is a nameserver record. And, finally, we get the domain of the nameserver.

But, in the class, what does IN stand for?

"Internet", obviously. Wait... Isn't the DNS on the Internet? Why do we need to specify that these DNS records are for Internet?

Well, isn't it obvious? Because you might want records of a different network. Like, for example, Chaosnet.

And if Internet is abbreviated to IN, what is Chaosnet shortened to? That's right! CH.

So, dig sees you enter ch for Switzerland, but thinks you're asking about CH for Chaosnet. And so it fails.

In order to query the records for ch we need to provide an absolutely fully-qualified domain name. It's as simple as sticking a dot at the end of the domain name:

dig ch. NS

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64932
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 11

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: e19b9c23cdfa0f7bcf82750462b5c16b47744386c7974ffb (good)
;; QUESTION SECTION:
;ch.                IN  NS

;; ANSWER SECTION:
ch.         164894  IN  NS  e.nic.ch.
ch.         164894  IN  NS  a.nic.ch.
ch.         164894  IN  NS  f.nic.ch.

And there we go. A failed 1970s experiment like bell-bottoms and Betamax videos - but with much longer lasting consequences.

You can see some CH records by running like:

dig ch txt @f.root-servers.net version.bind

That will get you something like:

;; ANSWER SECTION:
version.bind.       86400   CH  TXT "cloudflare-f-root-20190930"

Of course, DNS doesn't only have IN and CH class records.

There's also Hesiod - HS. But you already knew that, right...?

tl;dr you can't register Punycode .ss domains.

This also means Internet users in South Sudan can't register domains using their own writing system.

Background

The Republic of South Sudan became independent and joined the United Nations back in 2011. A decade later, and it's now possible to register .ss domains.

Partly due to the history of the letters SS, and partly because of the way domains are usually organised, you cannot register a .ss domain directly. You can have .com.ss, .edu.ss, .biz.ss, .sch.ss, .gov.ss, .net.ss, and - my new favourite - .me.ss!

This allows for some interesting domain hacks. Perhaps host a recipe page for Eton Mess? Or complain about trash at your_town.me.ss?

I was looking at hot.me.ss - but someone already snapped that up. However, the registrar said they allowed Punycode registration. Which means... EMOJI DOMAINS!

So, for €24, Afriregister.com.ss sold me...

🔥.me.ss

For the Punycode minded among you, that's xn--4v8h.me.ss

The process

This wasn't quite as simple as I hoped. There are several registries which claim to support .me.ss - but halfway through the process, they'd decide that they couldn't register it. Some of the registrars outside of Africa wanted extortionate prices for domains. But Afriregister.com.ss were relatively cheap and hassle-free. They let you pay via PayPal.

Domains have to be approved. There is a long list of banned terms. Some of those restrictions are very specific to the people of South Sudan - so it is worth reading.

The failure

The registration still hadn't completed after 12 hours. So the next day I chatted to the registrar.

Damnit!

Looking more closely at nic.ss's registration policies, they say

4.1 All .SS Domain Names MUST have a minimum of THREE (3) characters. 4.2 All .SS Domain Names should not have more than 63 characters. 4.3 All .SS Domain Names should have a syntax pattern of [a-z 0-9].

It didn't explicitly allow or deny hyphens - so I thought I'd risk it.

Oh well, that would have been fun if it worked.

As I said, it's important to publish about things which don't work. It stops other people from wasting their time on futile pursuits.

So, I've now got credit with the registrar. What .me.ss domain should I get?

Background

Virgin have a spammy DNS hijacking service. If you accidentally misspell a domain - for example example.coom - Virgin will pretend that the domain exists and serve you up an advertising page.

Yahoo powered! Yeuch! This means my data is sent to these advertisers without consent.

For the technically minded, the Virgin Media DNS should return NXDOMAIN instead it fraudulently returns NOERROR and redirects the user to the spam site.

Don't worry, there's a link to switch off the service.

But it is broken. It always says "the advanced network error search is already switched off."

Lots of people report having this problem but Virgin don't have an official fix for it. It is possible to change your devices' DNS servers - but it is impossible to change the DNS on the SuperHub. But, frankly, you shouldn't have to. Virgin should provide a proper DNS service.

So, here's how I got them to fix it. I hope this works for you too.

Raise a complaint

I raised an issue in the community forums. That's generally the best way to get in touch with the UK-based support team.

Eventually someone contacted me there and I was able to explain the issue. They started raising it with their IT team. But were unable to fix it.

I also raised a complaint directly with Virgin's complaints team.

After two months of being ignored, lied to, and misdirected - I asked for a Deadlock Letter. That allows you to make a complaint to the dispute resolution service.

Sadly, Virgin refused to issue a Deadlock. But as it had been longer than eight weeks, I was able to complain directly vis https://www.cedr.com/consumer/cisas/.

A couple of weeks later, I got a notification that my complaint had been accepted by CISAS. By complete coincidence I received a phone call from Virgin the exact same day offering me a solution!

Apparently the only way to change this setting was for Virgin to delete my customer account and rebuild it from scratch. Yup, their solution was to literally turn my account off then on again. Their only other option was to release me from my contract without penalty. As they're the only fibre provider near me, I let them switch me off for a couple of hours.

It didn't work.

The Data Protection Angle

I reckoned that if Virgin were sending my browsing data to a 3rd party without my consent, that was a GDPR issue. So I emailed Virgin's Data Protection team saying:

Virgin Media have forcibly enrolled my account into their "Advanced Network Error Search" service.

When I mistype a domain name, Virgin redirects me to an advertising service powered by Yahoo.

I would like to understand on what legal basis are you sharing my data with Yahoo and the advertising partners on the service. I see no mention of it in https://www.virginmedia.com/shop/the-legal-stuff/privacy-policy

As per your policy, I wish to assert the following rights:

5. The right to restrict processing

I have repeatedly asked your technical team to remove me from the Advanced Network Error Search service. They have refused. I am therefore instructing you to restrict the processing of my data for the purposes of this service.

Please let me know your response by 1st March.

I didn't hear back.

So I found their Head of Data Protection on LinkedIn and politely asked him to take a look into it for me. He told me to email a generic address. I explained that I had already done so but received no reply, so he gave me his direct address. I forwarded him the above, and got a swift reply saying they'd look into it.

A week later, I got a weird email saying my Web Safe Parental Controls had been changed.

I hadn't changed them. But, obviously someone at Virgin had monkeyed around with my account - because the accursed Advanced Network Error Search had gone!!

They phoned me shortly afterwards and confirmed that the issue had finally been resolved.

And all it took was three-months of complaining...

Compensation

Virgin offered a one month bill refund - £48 - by way of an apology.

In light of the months of arguing back-and-forth and the amount of time I wasted trying to get this fixed, I asked for £300 of compensation. Which they paid. (!!!!!!)

They separately also gave me bill credit for the delay in processing the case.

What Have We Learned?

Virgin media have shitty customer service. Their backend systems are antiquated and unreliable. But they have fastest speeds in my area and low(ish) prices, so I'm stuck with them.

But, more importantly, the threat of GDPR is an excellent way to force companies to behave!

Join Virgin Media and get £50 bill credit

If you fancy putting up with this sort of nonsense, join Virgin Media and we both get £50.

1. Google forgot to renew a domain used in their documentation.
2. It was mildly embarrassing for them.
3. And possibly a minor security concern for some new G-Suite domain administrators

Background

Choosing a good example domain, to use in documentation, is hard. You want something which is obviously an example, so that users understand they have to substitute it for their own details. But it also needs to be a validly formatted domain, and shouldn't be used for anything important, and - most importantly - should be under your control.

In most of Google's domain documentation, they used SpottedFig.org - why? Who knows!

They used it across their support platform:

Yet, for some reason, they didn't renew it when it expired a couple of months ago.

So I bought it for £10. Cheap!

Security

Google's documentation said "To view DNS results for a domain already configured to use G Suite, enter spottedfig.org."

As I now have control of the domain, I could have entered malicious DNS information and convinced people to use it. Perhaps redirecting their email to my servers.

Impact

Look, this isn't in the same league as the chap who bought Google.com for $12. This is a minor domain with probably zero traffic until I stumbled upon it. Looking in the Wayback Machine, it appears that the site never had any meaningful content.

Because Google specifically advised users to check the DNS entries of SpottedFig.org, I thought there was a minor security risk that Google users could be tricked into entering incorrect DNS information. So I responsibly disclosed it to them.

Eventually, Google replaced most references to SpottedFig in their documentation. They inexplicably left this .com one though:

Timeline

• 2019-11-29 Found the domain while reading the documentation close to midnight.
• 2019-11-30 Purchased the domain. Wrote a badly worded vulnerability report at 1am and sent to Google.
• 2019-12-02 Marked as "infeasible" by Google. So I wrote a better explanation. Essentially "Google tells G-Suite admins to use my domain as a template for configuration."
• 2019-12-03 Google reconsidered! Said it probably wasn't eligible for a bounty (drat!) but they'd evaluate it.
• 2019-12-11 I noticed that Google had rewritten its documentation. All references to SpottedFig.org were removed and replaced with a domain they control - solarmora.com
• 2019-12-18 "As a part of our Vulnerability Reward Program, we decided that it does not meet the bar for a financial reward, but we would like to acknowledge your contribution to Google security in our Hall of Fame"
• 2020-01-14 Published this blog post.

How to prevent this happening to you?

I recommend using Little Warden to monitor your domains.

Nestling among the "Letterlike Symbols" are two curious entries. Both of these are single characters:

• Telephone symbol - ℡
• Numero Sign - №

What's interesting is both .tel and .no are Top-Level-Domains (TLD) on the Domain Name System (DNS).

So my contact site - https://edent.tel/ - can be written as - https://edent.℡/

And the Norwegian domain name registry NORID can be accessed at https://www.norid.№/

Copy and paste those links - they work in any browser!

Is this limited to TLDs?

No! This works ANYWHERE in a domain name. Copy and paste these examples:

• Script https://ℰ𝒳𝒜ℳ𝓟ℒℰ.𝒞𝓞ℳ/
• Math Bold https://𝐞𝐱𝐚𝐦𝐩𝐥𝐞.𝐜𝐨𝐦/
• Fraktur https://𝖊𝖝𝖆𝖒𝖕𝖑𝖊.𝖈𝖔𝖒/
• Math bold italic https://𝒆𝒙𝒂𝒎𝒑𝒍𝒆.𝒄𝒐𝒎/
• Math bold script https://𝓮𝔁𝓪𝓶𝓹𝓵𝓮.𝓬𝓸𝓶/
• Double struck https://𝕖𝕩𝕒𝕞𝕡𝕝𝕖.𝕔𝕠𝕞/
• Monospace https://𝚎𝚡𝚊𝚖𝚙𝚕𝚎.𝚌𝚘𝚖/
• Super script https://ᵉˣᵃᵐᵖˡᵉ.ᶜᵒᵐ/
• Sub script https://ₑₓₐₘₚₗₑ.cₒₘ/ NB not all characters supported
• Math sans bold https://𝗲𝘅𝗮𝗺𝗽𝗹𝗲.𝗰𝗼𝗺/
• Math sans bold italic https://𝙚𝙭𝙖𝙢𝙥𝙡𝙚.𝙘𝙤𝙢/
• Math sans italic https://𝘦𝘹𝘢𝘮𝘱𝘭𝘦.𝘤𝘰𝘮/
• Math Squared https://🄴🅇🄰🄼🄿🄻🄴.🄲🄾🄼/ NB the dot must not be squared
• Circled https://ⓔⓧⓐⓜⓟⓛⓔ.ⓒⓞⓜ/ NB the dot must not be circled

There are a whole bunch more miscellaneous characters you can use:

Christoph Päper 🇪🇺

@Cr1ss0v

Replying to @lambdalynx@lambdalynx @edent Wait, so one can use any of
㍳ ㏃ ㏇(!) ㏈ ffffifflfifl ㎇㎓㎬㏉ ㏋㍱㎐ ㎄㎅㎑㏍㏎㎸㎾ ㎃㎆㎒㎫㎹㎷㎿㎽ ㎁㎋№㎵㎻ ㍵ ㎀㎩㎊㏗㏙㏚㎴㎺ ₨ ℠ßst㏜ ℡㎔™ ㏝
ÅℬℂℭℰℱℐℑKℒℳℕℙℚℛℜℝℤℨ and more to leet-code URLs?
@urlstandard

---

How does this work?

Magic! Which is to say, I think it is the browser doing the conversion. DNS Servers don't successfully reply to queries about .℡ domains.

The browser sees the .℡ and then follows the IDNA2008 process listed in RFC5895 to normalise it:

map characters to the "Simple_Lowercase_Mapping" property (the fourteenth column) in <http://www.unicode.org/Public/UNIDATA/UnicodeData.txt>, if any.

The ℡ entry is:

2121;TELEPHONE SIGN;So;0;ON;<compat> 0054 0045 004C;;;;N;T E L SYMBOL;;;;

U+0054 is T, U+0045 is E, U+004C is L.

You can test this in Python using:

python -c 'import sys;print sys.argv[1].decode("utf-8").encode("idna")' "℡"

Does this work?

Yes! I asked people on Twitter whether they could access my website using a .℡ - and it appeared to work on every modern browser and operating system.

Terence Eden is on Mastodon

@edent

Hey gang! I have a little experiment for you 🙂

Does this URL resolve in your browser?
https://edent.℡/
(That's https:// edent. ℡ /)

If it does or doesn't, could you let me know which browser and operating system?

THANKS!

---

It even works on command line tools like wget and curl.

Mike

@6byNine

Replying to @edent@edent Things used to retrieve web pages rather than web browsers
curl 7.59, Linux - Yes
wget 1.19, Linux - Yes

---

It does fail in some circumstances:

Ricardo Sueiras (@094459@hachyderm.io)

@094459

Replying to @edent@edent Yes, Chrome/Safari/Firefox running on Mac. The TEL however changed from superscript to normal text. If I copied/pasted into Word and then into the browser, the superscript is preserved and it no longer resolves (takes you to the google page with this page being the first hit)

---

What are the limitations?

Two main ones:

• Sites like Twitter and Facebook don't recognise it as a valid URl and refuse to auto link it.
• Some command line tools like dig and host don't understand it

dig edent.℡

; <<>> DiG 9.10.6 <<>> edent.℡
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 55282

Is this useful?

Obviously yes. This may be the most important discovery of the decade. You get cool looking URls and get to save a couple of characters on specific domains, at the minor expense of working inconsistently.

It could also be used for evading URl filters.

Every modern browser supports these "fancy" domain names - but most websites won't automatically link to them. So sharing on Facebook doesn't work.

Where can it be used?

Here are the single characters which can be normalised down to a valid TLD. They're mostly country codes, but there are a few interesting exceptions:

• ㏕ - US Military
• ℡ - .tel registry
• № - Norway
• ㍳ - Australia
• ㍷ - Dominica
• ㎀ - Panama
• ㎁ - Namibia
• ㎃ - Morocco
• ㎊ - French Polynesia
• ㎋ - Norfolk Island
• ㎏ - Kyrgyzstan
• ㎖ - Mali
• ㎙ - Federated States of Micronesia
• fi - Finland
• ㎜ - Myanmar
• ㎝ - Cameroon
• ㎞ & ㏎ - Comoros
• ㎰ - Palestine
• ㎳ - Montserrat
• ㎷ & ㎹ - Republic of Maldives.
• ㎺ - Palau
• ㎽ & ㎿ - Malawi
• ㏄ - Cocos (Keeling) Islands
• ㏅ - Democratic Republic of Congo
• ㏉ - Guyana
• ㏗ - Philippines
• ㏘ - Saint Pierre and Miquelon
• ㏚ - Puerto Rico
• ㏛ - Suriname
• ㏜ - El Salvador
• ℠ - San Marino
• ™ - Turkmenistan
• st & ſt - São Tomé and Príncipe
• ㎇ - Great Britain (Obsolete)
• ß - South Sudan (Not available)
• ㏌ - India and Indiana (subdomain of .us)
• Ⅵ & ⅵ - Virgin Islands and Virginia (subdomain of .us)
• fl - Florida (subdomain of .us)
• ㎚ - New Mexico (subdomain of .us)
• ㎵ - Nevada (subdomain of .us)
• ㍵ - As part of .ovh

If you can find any more, please stick a comment in the box below.

You can always reach this blog post at:

https://🅂𝖍𝐤ₛᵖ𝒓.ⓜ𝕠𝒃𝓲/🆆🆃🅵/

What is .tel

Your address book is probably a mausoleum - stuffed with the rotting corpses of long dead phone numbers. Perhaps you took my business card back in 2002, duly entered it on your Palm Pilot, and never spoke to me again. That address book entry has a phone number I've not used for a decade, an email address provided by a defunct start-up, and a postal address for a country I no longer live in.

Isn't there a better way?

That's what .tel was supposed to be.

• I register a .tel domain - http://edent.tel
• I fill it with my contact details.
• You store my .tel in your address book.
• When I change my phone number, I update my .tel and your phonebook receives the changes.

The magic of .tel is that everything is stored in the DNS. It shouldn't matter if the website goes down - or even if you've got low connectivity. All you need to do to get my details is:

dig @8.8.8.8 edent.tel naptr

Or, to get everything in the DNS records:

dig +nocmd edent.tel any +multiline +noall +answer

The tragedy of .tel is that there was almost no UI customisation available. Every site looked close to identical, corporate colour schemes couldn't be easily integrated, and the design was limited.

This is what it looked like back in 2009:

Which, thankfully, had improved by 2013:

No further improvements were made.

So, how well did it work in practice?

Lack of critical mass

Back in 2012, there were 256k .tel domains. In 2016, it's a mere 105k domains. Those numbers need to be in the multi-millions in order to get the traction needed for success. In their original proposal, they were expecting 20 million registrations five years after launch.

As registrations fell, so did income. Senior staff left the .tel organisation, and the infrastructure was left to rot. There were no updates, and it looked like .tel might collapse - an unprecedented event in DNS history.

I worked in the mobile industry for a decade. I don't think I ever met anyone else with a .tel. I got mine when they first launched in 2009 - and have been lonely ever since.

As far as I can tell, no mobile phones were ever released which had .tel capable address books.

Relaunch!

Late last year, .tel owners were sent emails describing the upcoming relaunch and reinvigoration of the service.

• ✓ Lifting of usage restrictions.
• ✓ A new Telhosting platform.
• ✓ Android and iPhone apps.
• ✘ No porting of data!
• ✘ No sub-pages.
• ✘ No search.
• ✘ No advertising.
• ✘ Limited foreign language support.

It's a bit of a mixed bag. But, hopefully, there's enough to sustain numbers - if not increase them.

The most important is the lifting of hosting and design restrictions. Users will be able to point their .tel at any site they like. The idea of it just being an address book is disappearing.

For those people who do want to keep it as their virtual contact card - a new platform is being launched with an improved interface and fewer design restrictions. It will still be free of charge for domain owners.

As far as I can tell, this also means that sites can be secured with https - something which was unavailable on the old system.

Apps will be available for editing your site - but it would be a lot more useful to integrate with native address books.

It is downright odd that they're not automatically porting over peoples' data. There's going to be a one month grace period before launch in mid-March, but that isn't a huge amount of time.

The lack of sub-pages and search probably reflects how little those features were used. Removing Ad-Sense seems weird - but people can always add their own advertising.

They're also dropping support for "Arabic, Czech, Japanese, Korean, Portuguese and Russian" - I have no idea what those languages have in common! I assume they just mean that their hosting platform won't contain translations for those languages.

Is it enough?

I doubt it. Sorry to be so pessimistic - there are now literally hundreds of available top level domains. Including .mobi, .mobile, .phone, .call, .me - all of which could serve the same purpose.

If .tel had built on their early momentum - and perhaps done some deals with mobile networks or manufacturers - then perhaps .tel would be in a better position.

It is pretty neat that they can store data like this in the DNS, and it is more discoverable than .hcard or other microformats - but I fear that the idea of placing one's address details in DNS is doomed to failure.

Because they aren't porting existing data to the new system, I expect that a lot of existing .tel sites are going to be empty.

Bonus Retro Video

This is how .tel launched itself back in the day.

Bless!