SPEAKING

Anatomy of a Resilient Nameserver: Concurrency, Resolution, and Protection

On paper, DNS is a simple request-response protocol. In reality, building an authoritative nameserver that delivers under heavy load, processes malformed packets safely, and resists DDoS attacks is a complex engineering challenge. This talk peels back the layers of erldns, DNSimple's open-source high-performance DNS server, to explore the fundamental architecture required to handle millions of queries per second. We will focus on concurrency models: how to structure a system that isolates failures per-request so that a crash in one query never brings down the server; and traffic management: Strategies for handling UDP floods and managing TCP connection pools without exhausting resources. While the reference implementation uses Erlang, the architectural lessons on isolation, supervision, and fault tolerance are applicable to any language. This session is designed for developers and operators who want to understand the "nuts and bolts" of how robust DNS software is built.

Scaling, securing, and protecting DNS, in Erlang

DNS is that protocol we all seem to know the basics of it but we all know we don't know it in depth. It is at the core of the internet and we all need it to work, but, how does it work? And maybe more interestingly, how does it not work? And how is it implemented? This presentation explores the application of Erlang/OTP in a DNS nameserver, highlighting its strengths and weaknesses, and the trade-offs. We'll also compare against leading C++ solutions, judging by performance, fault-tolerance, development ease, and community support. We'll cover engaging challenges, like: - How to implement a Plug-inspired extensible protocol: a purely functional idiom that allows for easy extensibility and testing - Networking stack in the BEAM: a critical component of any server and how to it tailor to your needs - DNSSEC and proof-of-non-existence: at scale, what do you sign, an empty string?! - Surviving DDoS attacks: did you know DNS DDoS represents a quarter of the world's DDoS attacks? - What's next: how I think the future will look for DNS and the BEAM

Automata Unveiled: A Theoretical Exploration of State Machines

Come with me on a journey through the realms of state machines, with the practical brilliance of Erlang's gen_statem behaviour as our light beam. Building on state machines as a model to reimplement technical debt, we will traverse the intersection of state machine practical implementation and the theoretical foundations of automata. Using real-world application examples, we will go over from the industry beast to the theoretical abyss, revealing the mathematical elegance inherent in state machines and its more powerful automata siblings. Bridging this gap, we will empower developers to architect solutions that go beyond conventional patterns, with concrete examples and plenty of code to read, providing the attendees with a comprehensive vision to harness the full potential of state machines.

A Murder of Crows: actors, instrumentation, and load-testing as part of the TDD cycle

A system performing under load is the holy grail of developers and stakeholders alike, but how do we know our software does actually perform under heavy stress? Come with me on a quick journey through the realms of load testing. Nelson will present you eye-opening ideas about the different kinds of load testing there are and their purposes, how load can be modelled in programming, an extensible tool that can be instrumented to your needs, and most importantly, why –and how!– load test should be part of your TDD cycle.

gen_statem Unveiled: A Theoretical Exploration of State Machines

Come with me on a journey through the realms of state machines, with the practical brilliance of Erlang's gen_statem behaviour as our light beam. Building on state machines as a model to reimplement technical debt, we will traverse the intersection of gen_statem practical implementation and the theoretical foundations of state machines. Using real-world application examples, we will go over from the industry beast to the theoretical abyss, revealing the mathematical elegance inherent in state machines and its more powerful automata siblings. Bridging this gap, we will empower Erlang developers to architect solutions that go beyond conventional patterns, with concrete examples and plenty of code to read, providing the attendees with a comprehensive vision to harness the full potential of gen_statem.

Reimplementing Technical Debt with State Machines

An extensible protocol implementation means that its core code has to be extensible, right? But it also means the core is the first piece of code ever written for this project, and which everything else will depend on, which means, well, highly likely future technical debt. Fast-forward over a decade, and this code might have become not just intractable, but also impossible to understand. What's next? Incremental improvements, top-bottom or bottom-up, a full rewrite and replug, experiment with a mysterious and not fully tested spaghetti? In our chat's backend service, we kept coming back to this topic, until one day that looked like it'd be just a boring day, we came up with a prototype for a remorseless full rewrite that immediately looked promising. Based on the OTP's gen_statem behaviour, we wrote a new core set of extensible rules where everything can gracefully plug in. Let's solve the quagmire putting together old code, RFCs, state machines and a telemetry-like event mechanism.

The Actor Model as a Load Testing Framework

Scalability under load. The holy grail of much of a developer's life is that our software survives its beginning. The system went live. Made it to production. Got its first user. But surely, the true test of good software is how it lives up to expectation over its lifetime? After all, you wouldn't say a bridge or building was successful just because the first 100 cars made it across safely. In other forms of engineering, things are load tested under demand either by weight, shocks or overload. As a software developer we should be ensuring SLAs or exploring error conditions under extreme load. But what is "load" in the context of software? And how do we test its many different definitions? In this talk, I will present a relationship made in heaven, the relationship between the actor model and the answer to these questions. I will also introduce you to a library that applies all this knowledge in a ready-to-use dependency.

Building blocks and How to Use Them: A MongooseIM Case Study

This is a talk about open source and the community, with MongooseIM as its backbone. MongooseIM is Erlang Solutions' robust, scalable and customisable messaging server, and using it as a "case study", I want to tell the story of the evolution of a big and old open source project. I'll start presenting common Erlang design patterns for a server – the supervision trees, the many processes, the NIFs when they are needed, and most importantly, the ways to preserve a big project manageable and continuously evolving. I also want to present the libraries that branched off from MongooseIM. In the evolution of a big project, often times you find pieces of code that are not an integral part of the business logic but actually can be generalised and reused for projects potentially very different from your own. I want to present what we found and how, what we extracted, and what we prepared for other people to reuse.

The Actor Model as a Load Testing Framework

Scalability under load. The holy grail of much of a developer's life is that our software survives its beginning. The system went live. Made it to production. Got its first user. But surely, the true test of good software is how it lives up to expectation over its lifetime? After all, you wouldn't say a bridge or building was successful just because the first 100 cars made it across safely. In other forms of engineering, things are load tested under demand either by weight, shocks or overload. As a software developer we should be ensuring SLAs or exploring error conditions under extreme load. But what is "load" in the context of software? And how do we test its many different definitions? In this talk, I will present a relationship made in heaven, the relationship between the actor model and the answer to these questions. I will also introduce you to a library that applies all this knowledge in a ready-to-use dependency.

SCRAM: Challenging your authentication in the BEAM

Passwords, that nemesis of all users. Get a weak password, and it can be cracked. Store it plaintext, and it can be stolen. Store it hashed, and it can be brute-forced. Use the same in two different places, and stealing one means losing the other. Submit it deterministically, and the authentication can be replayed by an attacker. Enter SCRAM, a: Salted: no two usages of the same password can be matched challenge: exponentially slow down brute-force attacks. Response: clients need to submit a different response on each authentication, hence solving replay attacks. Authentication Mechanism: well, you guess what this means. But mind you, the challenge needs to be a challenge for the client, not for the server! In this talk I'll introduce you to this authentication protocol, and to some implementation tricks that all evil attackers know but servers tend to forget. And to some very important insight on how to do this efficiently on the BEAM