> Cloudflare Workers and Deno Deploy are ephemeral, as in, the process that serves client request is not long-lived, and in fact, two back-to-back requests may be served by two different isolates (processes)
I suspect this would impact latency. Any benchmarks done to compare Cloudflare workers, Deno and fly.io for this specific application (i don't think ping alone is fair)? I'm guessing fly.io is more suitable here. Also, DoH clients generally maintain a pool of connections to the DoH server i'm not completely sure how this is handled with something like Cloudflare workers.
Cloudflare Workers uses isolates, not processes.[0] They start much faster, typically in single-digit milliseconds.
In fact, Workers can usually spin up an isolate in parallel with the TLS handshake.[1] After receiving the SNI packet containing a hostname, it'll go start up the isolate for that host, if it isn't running already. TLS typically needs another round trip from there to do a key exchange before application data starts flowing, by that time the isolate is ready to serve. In that case, there is no added latency.
Thanks for the article link. It is quite interesting to me that is only possible because we all need to trust the V8 sandboxing anyways. It makes sense since it should not be compromised on the other end of the connection either. However, one should still probably be aware that any exploit would be probably much more practical than e.g. a spectre attack.
We already built a separate application and wanted to avoid making a browser for a while. The idea for Beacon started when we wanted decent support for iOS and android, which nowadays is like the majority of users.
It's easy to install an app and start browsing. No hacks or workarounds and the UX can be much more tailored (even for desktop).
> Why are you swallowing "error" from invoking the "reall" tool? That seems like a great way to make contributors really frustrated
Glad you're looking at the code! There's still some refactoring needed for butil. It will get more polished soon ;)
> This trend of "I'm going to invent some build tool because there are not enough build tools in the world" is evidently leaking out of the node ecosystem
butil applies string replacements, patches and overrides all under one tool using a statically typed language but still usable like a scripting lang since it can rebuild the actual tool as needed. You can technically do something similar with various python scripts I suppose and use chromium's GN build system . GN would just end up calling various scripts so I think i prefer this more unless you have some other ideas.
It may be "statically typed" but from a consumer's PoV, 100% opaque. My first question when trying to build any project is "what is this going to do to my machine" and with some golang based build system, you're asking for a lot of trust on two different levels: 1. go install something (so now I need to read its source) 2. oh, turns out it actually delegates to an entirely separate binary that I now need to separately read
And I hear you about "but scripting!!1", however, using one of the existing tools means there is a non-zero chance of someone having experience with them and maybe even having reasonable editor support for it
It's your project, so I know I'm just some rando on the Internet, but I wanted to make sure you were choosing the contribution path you wanted to build upon, and not just hacking something together for expedience that then has to be unwound later. In this specific case, that goes double because it already has tight coupling to GN due to Chromium
Something to consider in the future is implementing RFC9102[0] which is an experimental TLS extension for embedding the DNSSEC chain this should significantly improve TTFB. It'll still need to request the DS record/trust anchor from the p2p client.
yeah the initial standard was dropped by tls-wg. RFC9102 is more recent/an independent submission.
> 3. An attacker with a valid certificate can strip dnssec-chain-extension out of a TLS handshake.
That's true but decentralized namespaces are at least starting with a clean slate they could require this extension no CA is issuing names for those anyway.
For names that rely on WebPKI this standard could be less strict about pinning initially (treating DNSSEC as just another CA). Once there's more adoption in a few years browsers should look for it and fallback to querying the DNSSEC chain (could be included with an edns option RFC7901).
Browser vendors (notably Chromium) have already acknowledged that the best they'll be able to do is treat DANE like another CA, which leaves open the question of why they'd bother supporting a TLS extension that doesn't improve the status quo. It's not going to happen.
The "decentralized namespaces" stuff is interesting, because, of course, it gives away that game that a substantial amount of DNSSEC/DANE advocacy is coming from people speculating on a premined crypto-token that purports to replace the DNS, linking to it (after a fashion) with DANE. Also not going to happen (but if it does, I'm going to pre-mine an ARP coin, so I win either way).
It uses WKNavigationDelegate[0] it allows responding to authentication challenges by accepting/rejecting certificates or continuing with default handling. This is used to do certificate pinning. DS records are stored on chain and requested via the P2P client. The DS record is used to verify DNSSEC and to obtain a certificate hash/TLSA record.
I have been following Gio development for quite some time, and it's still in the early stages. Text selection was added recently. It could be better but it's a good start.
Double click to select a word and triple click to select paragraph doesn't work for me either but can't reproduce some of the other issues running it natively.
Creating an alternative or an extension to the DNS root is pretty ambitious. If they had chosen a TLD similar to .eth, .bit ... etc., it would have been more manageable, and they could've avoided issues with name collisions.
However, there are some advantages to decentralizing trust in the root since there won't be a need for a root KSK[0] or a central entity that manages the root zone making DNSSEC + DANE more appealing even for existing TLDs.
The central KSK is a reason for normal users to dislike DNSSEC, but it's not why virtually nobody in the industry has deployed it, even though we're rapidly closing in on 3 decades of standardization effort for it.
Handshake is a deeply silly idea; literally, the Internet analog of selling the Brooklyn Bridge.
> The central KSK is a reason for normal users to dislike DNSSEC, but it's not why virtually nobody in the industry has deployed it, even though we're rapidly closing in on 3 decades of standardization effort for it.
I'm aware of the complexity DNSSEC adds and your opinions on it ;) it's getting easier to deploy with modern resolvers (also ed25519 is now more widely supported)
I still think it makes sense to cut the middleman (certificate authorities) one day and rely directly on DNS (whether its DNSSEC, DNSCurve, or some other way).
> Handshake is a deeply silly idea; literally, the Internet analog of selling the Brooklyn Bridge.
I think seeing whether a blockchain (specifically made for DNS) is suitable for this problem is more important at this point. At the end of the day, if you don't like name collisions with ICANN, you can add a suffix to the namespace like `.hns` (using some proxy) or just prefer ICANN TLDs in the resolver.
A blockchain-based TLD like dot-hns would be one thing, but that's not what Handshake is, right? Handshake looks at the existing DNS infrastructure built over the last 35 years or so, says "oh, that's ours", and sells shares in it.
I believe they distributed around 70% of the coin supply to open source developers (I think only a small percentage claimed so far). The names are sold in auctions and the coins are burned after the winner is declared (I understand that early adopters will still benefit from that).
It's decentralized, and ultimately, users will decide how they value those names, though. So, for example, they can put them under dot-hns or prioritize ICANN TLDs in case of a name collision. Some existing TLDs may decide to claim their name if they disagree with a centralized root. IMO, It's flexible and pretty experimental for now
If I try to sell you shares in the Brooklyn Bridge, it doesn't so much matter if I've distributed many or even most of the shares to open source developers. I don't own the bridge.
yeah that's the thing who owns the bridge? some may argue that control of ownership should be decentralized and some may disagree. but like I said it wouldn't be too bad if users ended up using it under some TLD but that's my opinion
I don't know who owns the bridge. What I know is that these people don't. Literally their only claim to it is deciding it's theirs to sell. It's a batshit plan and it's shocking to me that anyone takes it seriously. I want to do the same thing with ARP. You gotta pay me to talk to your Wi-Fi router. Affordable and convenient payment plans are available.
I think the analogy here is weak. A blockchain-based naming system is different, though. It's governed by consensus. The majority of users must agree on who owns a particular name or at least that's how it should work.
Don't know of any other way to create a decentralized name system without doing something similar (regardless if it's top level or secondary level names)
The A record was never in the root zone. The root zone has an NS record for ai TLD which delegates authority to ai nameservers.
You can try `dig @a.root-servers.net ai NS` to get the nameserver `a.lactld.org.` which is authoritative for ai. You can now try `dig @a.lactld.org ai A` to get it (that's how recursive resolves generally work)
Yeah, so I think I'm seeing something weird where some software isn't allowing this particular recursive query? I'll dig into it more.
By the way:
> The A record was never in the root zone.
Are you sure of that? I don't have any proof, but my impression was that the DNS registry for ai (which was also just Vince Cate...) was able to ask for it because at one time the root zone was less restrictive in what RRtypes could be placed there for TLDs. But that might just be repeating someone else's mistaken impression.
and this version of the root zone from 2009 does indeed not have an A record for ai, just ordinary NS delegations. So it seems like your explanation is confirmed, and there must be a change in some recursive resolver behavior. (I tried from four different Linux systems on different networks and all refused to resolve it, so there really must be something that's changed more widely, not just my home router.)
I checked an archive of root zone data from June 1999 to May 2021[0], and there don't seem to be A records for any TLD. Not sure why you're having this issue, but I'm curious to know which Linux distro/software doesn't resolve ai.
It looks like it's systemd-resolve. I just checked on several machines and, when using nslookup to query the recursive nameserver that systemd-resolve is forwarding to, the ai A record does resolve, while when using systemd-resolve itself, or the local instance on 127.0.0.53 configured via /etc/resolv.conf, it returns a failure every time.
I'll have to look into this some more.
Edit: I think I found it! From systemd-resolved.service(8):
· Single-label names are routed to all local interfaces capable of IP
multicasting, using the LLMNR protocol. Lookups for IPv4 addresses
are only sent via LLMNR on IPv4, and lookups for IPv6 addresses are
only sent via LLMNR on IPv6. Lookups for the locally configured
host name and the "_gateway" host name are never routed to LLMNR.
· Multi-label names are routed to all local interfaces that have a
DNS server configured, plus the globally configured DNS server if
there is one. Address lookups from the link-local address range are
never routed to DNS.
The last time I went to Fry's was four years ago. They had servo motors, gears, structural aluminum plates, and lots of electronics parts that you could use to build robots or other cool things. You can get the same parts online from stores like servocity, but browsing and buying stuff in real life without having to wait for shipping was awesome so sad to see it close :(
I was curious why a "null MX" is even needed. If there are no MX rrs it would mean that this domain doesn't handle mail, right? It's actually because of the "implicit MX" rule defined in rfc5321[0]. If there are no MX rrs, the SMTP client will still try to use the A or AAAA records to see if there are any SMTP listeners. Adding a null MX "0 ." will cause the delivery to fail immediately.
I suspect this would impact latency. Any benchmarks done to compare Cloudflare workers, Deno and fly.io for this specific application (i don't think ping alone is fair)? I'm guessing fly.io is more suitable here. Also, DoH clients generally maintain a pool of connections to the DoH server i'm not completely sure how this is handled with something like Cloudflare workers.