If you operate your own DNS, choose an NS within the same TLD als the domain you resolve: `example.COM` -> `ns.example.COM`, `example.NET` -> `ns.example.NET`, `example.ORG` -> `ns.example.ORG`
It'd be great if a CDN like Cloudflare handed out matching NS records for their most popular TLDs. This would probably speed up DNS resolution time (a little).
So e.g. `*.ns.cloudflare.com` for COM, `*.ns.cloudflare.net` for NET, `*.ns.cloudflare.org` for ORG, etc.
At least for Cloudflare, I believe they have these domains (`cloudflare.TLD`) for most of the important TLDs anyway. And the actual resolvers could be the same servers/IPs, afaict. It's mostly _just_ the (glue) records.
(I know, nothing is _just_ done on a CDN scale. Like, they'd need to also add the logic for handing out the correct NS names for the respective TLDs, which NS.TLD to fall back on for TLDs that they don't operate their own NS in, how to handle this for their bring-your-own-* customers, etc.)
I'm thinking similarly, but not via PCIe, but via USB: There are plenty of USB->VGA and USB->HDMI adapters that contain a dumb graphics card. So, embedd one of these and grab the video signal internally.
Thereby, plugging in just a single USB cable would deliver the power needed, keyboard, video and mouse. And bonus for an emulated USB-Stick/DVD drive.
What I don't know if these USB video cards are initialized during early boot and usable during the UEFI/BIOS phase. Is that why they grab the HDMI?
The OS of PS4 and PS5 is apparently based on FreeBSD. Netflix uses FreeBSD for its CDN servers. pfSense and OPNsense are popular firewalls that are based on FreeBSD.
I think it's good advice to not pass secrets through environment variables. Env vars leak a lot. Think php_info, Sentry, java vm dumps, etc. Also, env vars leak into sub-processes if you don't pay extra attention. Instead, read secrets from a vault or from a file-system from _inside_ your process. See also [1] (or [2] which discusses [1]). Dotnet does this pretty good with user secrets [3].
Yes, and I like to combine two established concepts instead of rolling my own: URI and UUIDv7. So my IDs become `uri:customer_shortname:product_or_project_name:entity_type:uuid`. An example ID could be `uri:cust:super_duper_erp:invoice:018fe87b-b1fc-7b6f-a09c-74b9ef7f4196`.
It's even possible to cascade such IDs, for example: `uri:cust:super_duper_erp:invoice:018fe87b-b1fc-7b6f-a09c-74b9ef7f4196:line_item:018fe882-43b2-77bb-8050-a1139303bb65`.
It's immediately clear, when I see an ID in a log somewhere or when a customer sends me an ID to debug something, to which customer, system and entity such an ID belongs.
UUIDv7 is monotonic, so it's nice for the database. Those IDs are not as 'human-readable' for the average Joe, but for me as an engineer it's a bliss.
Often I also encode ID's I retrieve from external systems this way: `uri:3rd_party_vendor:system_name:entity_type:external_id` (e.g. `uri:ycombinator:hackernews:item:40580549:comment:40582365` might refer to this comment).
> And another one! I actually used this regularly on my PC to remember places I'd gone to on trips, or back in time.
Me too. High-noon to engage Google Takeout [1] – so that I at least have a copy of all that data.
Off-topic: TIL, that Google Takeout can do regular backups automatically for up to one year when you link it to some cloud storage account (GDrive, Dropbox, One Drive, Box).
So, this begs the question when we'll see ML put in place to avoid AdBlocker detection. Or ads as we know them just disappear from the web and are replaced with other kinds of ML-enabled ads. I imagine deep-fake models used for interchangeable product placement in videos or pictures or so.
I often hit CTRL-R to reload a services config. I press `CTRL+R`, enter `reload`, and continue to hit `CTRL+R` until the right service appears. Enter. Done. Usually way quicker, especially when switching between distros. As one calls it httpd and one apache, once it's systemd and once it's and init script, and so on.
Devices should offer a quick way too disable the feature for a limited amount of time, so that people don't forget to turn it back on. Like it's possible with Do Not Disturb features. Perhaps that could be called Action Mode.
Good point. So there is more to it, which I didn't consider before. As I understand [1], the client uses the public key of the key pair used by the SNI to encrypt the SNI value, additionally to any TLS encryption. Only the actual SNI has the private key to decrypt the SNI value.
The client must look up the public key in the DNS (I guess at least if it doesn't know the key already, which it could have in the cache).
This whole thing is still a draft RFC [2] and currently called encrypted client hello.
What I don't get: The client will have to disclose, which public key it used to encrypt the client hello / SNI value. But don't we know "all" the public keys from the certificate transparency logs? Usually a public key is only valid for a limited set of domains, so it would be easy to associate the public key used for encrypting the SNI value with the relevant service. Just look up the public key, read it's SAN or CN, and you pretty much know the SNI value. Or at least the service, which might be good enough. What am I missing?
As I understand, the public key that is used for authenticity is not the same as the one being used for encryption — at least since TLS 1.3, before it depends.
The scheme is known as forward secrecy. For the encryption, an ephemeral key pair is used on both sides. These pairs are only used for the Diffie-Helman (or similar) key exchange. Therefore an encrypted connection can be established, then SNI can be exchanged over the encrypted connection, and then the remote can provide the signed nonce together with it's PKI public key, with which it establishes trust respective to the SNI.
If you operate your own DNS, choose an NS within the same TLD als the domain you resolve: `example.COM` -> `ns.example.COM`, `example.NET` -> `ns.example.NET`, `example.ORG` -> `ns.example.ORG`
It'd be great if a CDN like Cloudflare handed out matching NS records for their most popular TLDs. This would probably speed up DNS resolution time (a little).
So e.g. `*.ns.cloudflare.com` for COM, `*.ns.cloudflare.net` for NET, `*.ns.cloudflare.org` for ORG, etc.
At least for Cloudflare, I believe they have these domains (`cloudflare.TLD`) for most of the important TLDs anyway. And the actual resolvers could be the same servers/IPs, afaict. It's mostly _just_ the (glue) records.
(I know, nothing is _just_ done on a CDN scale. Like, they'd need to also add the logic for handing out the correct NS names for the respective TLDs, which NS.TLD to fall back on for TLDs that they don't operate their own NS in, how to handle this for their bring-your-own-* customers, etc.)