36 karma · joined July 29, 2014
Cloudflare delivers signatures for records that last more than the TTL of the record. This has the problem of replay attacks. If one employee that had access at some points configures a machines DNS to return an old DNS response it will be valid until the expiration of the signature, hence having access for more time than the actual TTL.
I just checked and Cloudflare generates signatures expiring +2 days in the future. This means that I have a TTL of 5 minutes on my record but the client is receiving old queries, authentication would pass without a problem for as long as the RRSIG is valid.
Ideally Cloudflare should sign every record with the same frequency as the records TTL, that would solve the issue.
After finding this out I think you should _not_ use Cloudflare's DNSSEC because revoking access to a user wouldn't be 100% effective until the RRSIG expiration date given the replay attack scenario.
I really really trust them, they have an impressive history of contributions to the web and commitment to security. If your servers are behind another access control layer, like a corporate VPN, this shouldn't be a big concern, since they would have to disclose breaches anyway.
Finally, I think this interesting because basically DNSSEC gives you an easy way to distribute data globally in a secure way with a TTL. This is the best benefit compared to using certificates for access control where revocation is usually very painful.
Consider this an initial look on how to use those benefits of DNS. I agree another layer of security would be great. Think something like asymmetric signature of the actual TXT record so that DNSSEC helps control expiration and then the other key validates origin. You are using DNSSEC only for the benefits of TTL validation.
I'm yet to verify this, but it seems that Rust is closer to Haskell in that it intends to enhance the likeliness of program correctness as it's being written and not only through testing. In go you still get runtime errors and I don't think it's all that rare, Rust should reduce those greatly.
I do share that adoption through libraries and widespread acceptance is very important and when you compare Rust to Haskell you make a nice point, the language could be great but not generate adoption.
However besides adoption I don't see anyone who seem to dislike the process of writing Rust itself. Apparently people think it's viable if more libraries are out there. The natural presentation of the arguments made me feel that people are open to it should the right libraries be there.
It's semantics are somewhat more complex that something like Go, but using it shouldn't prove much more complex that Go one you are used to the language basics. This could be of course my errors anaylising the problem, maybe it's way slower/complex and without any great benefit when precise memory management can be spared in favor of development speed. But even then I wonder if the existance of immutability, exhaustive pattern matching and an expressive type system don't increase heavily the realiability of Rust code hence providing stability reducing bugs.
> If you want a replacement for Ruby, and don't want to use Go (for whatever reason), then I'd really advise asking "Why?", first.
I'm slightly tired of not having a type system, I keep shooting myself in the foot and introducing little bugs that a type system would often get. In ruby heavy testing is very important and I find myself wanting things like immutability and pattern matching to ensure I handled exhaustiveness in my logical assertions during the program flow.
Also, my company pays way to much for not so much concurrent users because Ruby consumes a lot of memory. We have to think to much about deployments and horizontal scaling and I'd prefer something simpler to scale.
This are all problem that we have solved. They are natural to the dynamic character of Ruby, but the beautiful syntax and simplicity of DSLs come at a price in development and deployment.
Go feels a very poor language. Channels are nice and expressive, but the lack of a larger type system, error handling, it's mostly imperative semantics and excessive simplicity make it unattractive. I don't want a compiled Javascript, I want the quality of abstraction that simple tools can bring even though they may not be the easiest.
Javascript is very unrealiable and full of quirks. Go is too simple to offer level of abstraction we want to invest heavily in program correctness without too much testing. Ocaml has an interesting balance but I want statically linked binaries at all times and have no interesting in dealing with what seems a messy standard library and compiler flags to get the exact result I want. Haskell's too complex to learn for any practical use. Purescript seems interesting but suffers from the same complexity as Haskell. Many other languages are not safe even though they're fast and compiled and many JVM languages are way to close to Java which I would love to see disappear during my lifetime.
It's very picky, but hopefully the downsides of every language appear clear as to why I'd consider Rust instead of Go as a replacement to ruby.
I do think there will be space for both and I would prefer to consider them as raw tools, hence the language themselves, and take the risk of having a community in the future sharing libraries for common things. It's a risk but not a crazy one I'd say and probably helpful for the analysis.
Building on your reply, I'd say prove of adoption is one downside for choosing Rust. This however ignores the merit of Rust as a language which hints me into what I have begun to see more often: that it's the newness and relative absence of production use cases that don't seem to validate it viability, not some inherent complexity or downside to the language itself.
Going back to my proposed question, maybe people can prefer golang for this syntactic benefit but I don't think that addresses the larger set of differences that usually separate them.
I think this is specially important with elastic IPs that have been whitelisted somewhere, e.g. a VPN of a 3rd party service provider. So a way to say, take EIP x.x.x.x, don't ever release it and then indicate what instance to associate it to is great.
Another example of this feature is starting from an existing VPC and build from there, or even actually inherit information from the current state and convert it to an "auto generated plan" to build from. Thanks again Hashicorp for all the great software.