I'll never cease to be amazed at what large companies will throw hundreds of thousands of dollars at just to _apply_ for a new gTLD. I mean what's the demand for whatever.superintelligence? Nobody is going to type that or notice it in a URL bar and think anything but "damn, that's a long TLD" while the dozens of other shorter AI focused TLDs sit there too.
It is not an exaggeration that tech companies have far, far more money than they know what to do with. Not all spending looks good to investors, so layoffs must happen, but this is nothing compared to the amounts of money Google, Meta, etc, blow on completely inexplicable / SVP vanity projects every year.
Non-tech companies are getting sucked in, too - see, for example, the applications for .airliquide, .capitalgroup, .dinebrands, .massimodutti, .newbalance, .stubhub, .warhammer, .zarahome, and so on.
From what I've seen thus far, most brand TLDs never get used. (The only significant exception that comes to mind is .google, and even they never really committed to using it.) Who's been going around convincing these companies to apply for this round?
Ah, that answers something I was wondering about that the article didn't answer, which is how you can lift a car by its tyres without starting already under the tyre and without friction or forcing them to rotate.
Looks like the answer is (at least for this older system), come in from both sides of the tyre with two separate arms, and have each of those arms have their own little wheels on, so as you move inwards it lifts up the tyre and just rolls your mini wheels a little bit. Clever.
This is the video of the 11+ year old system installed in Århus Denmark by Lödige Industries from Germany.
Lödige Industries more recent solution is actually moving the whole pallet you park on, so you can also plug your car into it: https://youtu.be/-_ZxnDrfwGk?t=46
The system in London Gatwick UK is done by Stanley Robotics from France (which was acquired by HL Robotics from South Korea in 2024), but it could be similar.
Sorry yeah, I understood that they're not the same company or system, but I couldn't think of any way it could be done (aside from, as you say, parking already on it) so it was nice to see at least one solution.
> Further, native apps can generate a unique self-signed certificate.
Just creating a certificate will not work, unless it's installed as root CA certificates in all browser trust-stores on the machine. And if the private key of the root CA is not secured correctly, one could MitM any websites. So at least you want it name constrained (https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1....), but at least in Chrome until 2023 (v112) that did not work on root CA's (https://alexsci.com/blog/name-non-constraint/), so you had to add an intermediate CA and add the constrain there. Of course, you should also just throw away the key of the root CA.
I will admit I once added basic constrains in some project with a local root CA (2020-2022), but 'incorrectly' to the root CA, and did not test it in all browsers.
I will hijack this post to point out CloudFlare really doesn't understand RFC1034, their DNS authoritative interface only blocks A and AAAA if there is a CNAME defined, e.g. see this:
$ echo "A AAAA CAA CNAME DS HTTPS LOC MX NS TXT" | sed -r 's/ /\n/g' | sed -r 's/^/rfc1034.wlbd.nl /g' | xargs dig +norec +noall +question +answer +authority @coco.ns.cloudflare.com
;rfc1034.wlbd.nl. IN A
rfc1034.wlbd.nl. 300 IN CNAME www.example.org.
;rfc1034.wlbd.nl. IN AAAA
rfc1034.wlbd.nl. 300 IN CNAME www.example.org.
;rfc1034.wlbd.nl. IN CAA
rfc1034.wlbd.nl. 300 IN CAA 0 issue "really"
;rfc1034.wlbd.nl. IN CNAME
rfc1034.wlbd.nl. 300 IN CNAME www.example.org.
;rfc1034.wlbd.nl. IN DS
rfc1034.wlbd.nl. 300 IN DS 0 13 2 21A21D53B97D44AD49676B9476F312BA3CEDB11DDC3EC8D9C7AC6BAC A84271AE
;rfc1034.wlbd.nl. IN HTTPS
rfc1034.wlbd.nl. 300 IN HTTPS 1 . alpn="h3"
;rfc1034.wlbd.nl. IN LOC
rfc1034.wlbd.nl. 300 IN LOC 0 0 0.000 N 0 0 0.000 E 0.00m 0.00m 0.00m 0.00m
;rfc1034.wlbd.nl. IN MX
rfc1034.wlbd.nl. 300 IN MX 0 .
;rfc1034.wlbd.nl. IN NS
rfc1034.wlbd.nl. 300 IN NS rfc1034.wlbd.nl.
;rfc1034.wlbd.nl. IN TXT
rfc1034.wlbd.nl. 300 IN TXT "Check my cool label serving TXT and a CNAME, in violation with RFC1034"
The result is DNS resolvers (including CloudFlare Public DNS) will have a cache dependent result if you query e.g. a TXT record (depending if it has the CNAME cached).
At internet.nl (https://github.com/internetstandards/) we found out because some people claimed to have some TXT DMARC record, while also CNAMEing this record (which results in cache dependent results, and since internet.nl uses RFC 9156 QName Minimisation, if first resolves A, and therefor caches the CNAME and will never see the TXT). People configure things similar to https://mxtoolbox.com/dmarc/dmarc-setup-cname instructions (which I find in conflict with RFC1034).
I don't think they're advising anyone create both a CNAME and TXT at the same label - but it certainly looks like that from the weird screenshot at step 5 (which doesn't match the text).
I think it's mistakenly a mish-mash of two different guides, one for 'how to use a CNAME to point to a third party DMARC service entirely' and one for 'how to host the DMARC record yourself' (irrespective of where the RUA goes).
I'm not sure, but we're seeing this specifically with _dmarc CNAMEing to '.hosted.dmarc-report.com' together with a TXT record type, also see this discussion users asking for this at deSEC: https://talk.desec.io/t/cannot-create-cname-and-txt-record-f...
My main point was however that it's really not okay that CloudFlare allows setting up other record types (e.g. TXT, but basically any) next to a CNAME.
Yes. This type of behavior was what I was referring to in an earlier comment mentioning flashbacks to seeing logs from named filled with "cannot have cname and other data", and slapping my forehead asking "who keeps doing this?", in the days when editing files by hand was the norm. And then, of course having repeats of this feeling as tools were built, automations became increasingly common, and large service providers "standardized" interfaces (ostensibly to ensure correctness) allowing or even encouraging creation of bad zone configurations.
The more things change, the more things stay the same. :-)
I've one ticket for sale (€190-255), since I bought two tickets (one € 255 supporter for myself and € 190 for partner) but also got a speaker ticket (https://fahrplan.events.ccc.de/congress/2025/fahrplan/event/...), since speaker announcement was after the first round of sales via vouchers.
So let me know if someone is interested in this ticket, see my GitHub for mail address. I know other speakers where even unaware of this (so I might know another ticket for sale).
Tickets are sold (to the first email that arrived at 10:25 CEST, and the second ticket of a friend who's also a speaker to the second mailer at 11:11 CEST).
It falls into the category that most people think they understand DNS, the same as JavaScript, or e.g. elections, but the devil is in the detail. And I can tell you, at least for DNS (and Dutch Elections), it's kind of tricky, see fun cases like https://github.com/internetstandards/Internet.nl/issues/1370 and I thought the same before I had my current job which involves quite some tricky DNS stuff (and regarding this we also sometimes encounter bugs in unbound https://github.com/internetstandards/Internet.nl/issues/1803 )
There is this list of things tech people think they understand (DNS, javascript), and more common you can see this with everyday people, e.g. with stuff like elections: the basic concept is clear, understandable, but the devil/complexity is in the detail, how to handle certain exceptions. I was employed by the Election Management Body of The Netherlands for a few years, so I can only vouch for the complexity of that relatively simple election system, but I'm pretty sure it will hold for about every country ;)
Charleston Road Registry Inc. (doing business as Google Registry): agent, alphabet, api, ask, beam, browser, cast, chromebook, chromium, classroom, deepmind, find, fitbit, gem, gemini, gemma, genie, gke, intelligence, keep, lens, lesson, lyria, maps, mcp, nest, pixel, share, sheets, shorts, slides, teach, ultra, veo, vids, waymo, waze, wear, workspace