that is not that either though or is it? i mean say i found my vehicle on some platform for sale and then located it with their service, now what? i call the cops i suppose, i dont see how this is much different to calling them once they agreed to meet somewhere.
> it’s more than that. it’s any device that can present itself as a possible base station.
can you elaborate on this a bit? what devices are able to to present themselves as possible base stations? do i need any form of entitlement to participate in the network or not? From past encounters with SS7 and its, uhm, capabilities, it seemed the hardest part would be getting access to the network, albeit not hard really, it sounds like you were hinting at possibly gaining access by participating in the network without any official entitlement, by posing as a base station.
its funny you call out Mullvad in this specific case because its the one thing i really dislike about their VPN service. It wont route DNS to the root server, or any designated server really. They redirect DNS queries to their cache indiscriminately. which actually will harm the success of setting up a recursive resolver. I get this is done to prevent leaks, i would just like the option to opt out of it. been customer for many years now though. I use unbound semi recursively resolving using a forwarder with DNS over TLS. So Mullvad is not burdened with what i resolve and the forwarder not with information on who.
For hard cutovers it might be a viable strategy to forward or redurect traffic inbetween changes. That is, either let the old destination forward to the new, or vice versa, then update the records to the new destination, or have an intermediary forwarding destination where you can change the destination address on an an instant and once settled move the record to that.
The recursive resolver you describe would adhere to the same TTL as would do any reasonable public resolver. The difference in cache behaviour, if any, only depends on if the resolver already has a cached record that's still valid or doesn't have it. That it won't have it just happens to be more likely as the amount of requests your resolver received is smaller as the case if you are it's sole user. It's possible to force the behaviour you described by using specialised tools that are meant to be used for analysis like binds dig utility with its trace flag. It can bypass any resolver by querying up from the root servers to the designated label without any caches being involved. You still only will know that other resolvers will receive the desired answer eventually. Only safe bet is to assume it will take the TTL until every will receive the updated record.
24h seems overly excessive but some resolvers may refuse to adhere to arbitrary low TTL and chose to answer with stale records from cache for as long as they deem necessary. 24h certainly would make many issues with that strategy very apparent.
i used to use [0]s3ql on-top of "slow" fuse storage. it comes with its own caching layer and some strategies around handling larger blobs of data efficiently even at high latency with ease but its a non shared filesystem. you mount/lock it only once at a time. otherwise this was a perfect solution to me at the time.
there is also [1]rclone with its own caching layer and own support for various backends directly. I don't remember anymore why i did prefer s3ql though, but i usually have some reasoning with things like this..
i think it cleared a thing up or two. However, would you mind sharing why insertable streams are apparently required for this to work? As WebRTC traffic is encrypted already E2E it seems to me that constructing the SDP with the key, currently used here with insertable streams, would be good enough.
I wish browser would do something similar with their WebRTC stack. Something that shows independently of the site (out of its execution context) which keys are used and allow for an easy comparison of them independently. But i don't know of such functionality being there yet.
>As a side note, this is why we built Booth.video -- to demo that this isn't a fundamental tradeoff and it's possible to have E2EE, metadata-secure video conferencing in the browser.
now i wonder how you did that. Is the key exchange of participants happening out of band?
E2EE implies both ends have an encrypted channel to transport data to each other directly, without an intermediary step. this is the very definition of the term, at least it is in my mind. Having the data only encrypted to and from their servers would merely be transport layer encryption. Although i have no idea whether they implement one, the other or both.
In context of video conferencing software (WebRTC specifically) this is actually somewhat interesting, because typically the signaling server is the one who hands out the public key of the other peer and needs to be trusted, so they could by all means deliver public keys to which they posses the keys for decryption and it therefore would allow them to play man in the middle in a typically relayed call. So even if E2EE is implemented, it might be done poorly without figuring out how to establish trust independently.
more precisely a CNAME must be the only record type for a given label as it would be otherwise ambiguous to revolvers. that doesn't hold true for DNSSEC secured zones where the records for signatures are to be allowed, but also arent creating any ambiguity on how to resolve queries. the apex must have NS and SOA records for a minimum to work so that rules out any CNAME in addition to that. an apex without any other record but SOA and NS would work fine though. so saying it needs to be an A record implies the wrong thing.
just so you know, your assumption i am not using the right tools feels almost insulting to me considering i made no claim about any tooling used. i am using systemd-networkd to setup networking anywhere, i never touch wg-quick because it is no fit for my use cases. i have multiple routing tables and do policy routing and i would really like to have the "via" in the routing tables to have a meaning to wireguards crypto routing thing. i.e. i want to be able to set "AllowedIPs" based upon the routing table very similar to reverse path filtering. i know i can setup multiple interfaces with multiple keys to exchange and multiple ports to set and to make sure every client that needs to is kept in sync.... but it would be much nicer if i could handle it like an ip-ip tunnel and make routing decisions with software build for this purpose.
i just wish i could control the routing via routing tables instead, making dynamic routing decisions possible without specialized software that is able to manipulate it.