#felu

WIP, ignore for now.

#Crates

#bin

#felu-mgmt

UI for management.

Leptos, not sure about SSR or CSR yet, CSR might be easier. Local accounts to begin with, SSO via OIDC maybe.

Connects to configured felu-ns servers. Health checked connections and retry connections if dropped.

• Leptos for UI
• axum as web framework
• tower-sessions as session store for axum
• sqlx for PostgreSQL

#felu-ns

Nameserver.

Many, hosted as ns1, ns2, nsN, ns9.

Requires a static public IPv4, which is used as the DNS (At least Do53 (Port 53 over UDP and TCP). Possibly DoT, DoH and DoQ in the future) interface.

Don't start DNS servers until configuration from felu-mgmt is received.

Optionally the same interface used for DNS can be used as the interface that felu-mgmt connects to for management. Though ideally management is done via a VPN connection (e.g. Tailscale) and not via a public interface.

Completely stateless, receives configuration from felu-mgmt and stores it in memory. Stores nothing to disk.

Built-in HTTP server for things like Prometheus metrics at /metrics.

• hickory-dns as the DNS library, should support everything needed
• hyper for HTTP server

#lib

#felu-common

Protobuf definitions and other shared structures.

• prost for protobufs

#Initial notes:

#Communication

Certs!

Protobufs over gRPC or just TCP? Which is easier when we need a stream?

One-way stream? Mgmt sends data to ns, and ns can respond Results to received messages, but not send messages to mgmt.

#Version control

Configuration version number. Whole config hash?

#Health checks

Check if all available and on correct version of config. Send config update if not.

5 second intervals.

#Atomic updates

Swap config after update in one operation.

#Scenarios

#New felu-ns

Receive whole config.

#Config updated

Existing felu-ns receive update.

#felu-ns network flaky just as config was supposed to come

Health check will re-send if this happens.