{"id":15903364,"url":"https://github.com/erikh/border","last_synced_at":"2025-03-17T21:31:37.014Z","repository":{"id":150460312,"uuid":"608829324","full_name":"erikh/border","owner":"erikh","description":"A modern approach to handling the edge of your website's communication.","archived":false,"fork":false,"pushed_at":"2023-05-08T18:53:25.000Z","size":452,"stargazers_count":4,"open_issues_count":10,"forks_count":0,"subscribers_count":2,"default_branch":"main","last_synced_at":"2025-02-28T04:58:35.537Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"Go","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mpl-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/erikh.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2023-03-02T20:29:10.000Z","updated_at":"2023-05-22T04:55:13.000Z","dependencies_parsed_at":"2023-07-28T09:46:17.939Z","dependency_job_id":null,"html_url":"https://github.com/erikh/border","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/erikh%2Fborder","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/erikh%2Fborder/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/erikh%2Fborder/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/erikh%2Fborder/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/erikh","download_url":"https://codeload.github.com/erikh/border/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":243886014,"owners_count":20363649,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-10-06T12:01:31.051Z","updated_at":"2025-03-17T21:31:36.761Z","avatar_url":"https://github.com/erikh.png","language":"Go","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Border: A modern approach to DNS \u0026 Load Balancers\n\nBorder is a combination of DNS service and Load Balancer, It uses this\ncombination, internal health checking, and primitive consensus algorithms to\nautomatically heal your network when there are issues. If you lose a border\nnode, one can be immediately added to the cluster without additional\nconfiguration. Zones and Balancing rules will automatically propagate to the\nnew node.\n\nAll network resources are treated like DNS entries, and DNS propagation (\"Zone\nTransfers\") do not use the primitive and insecure AXFR protocol. They use\n[JOSE](https://datatracker.ietf.org/wg/jose/documents/) to distribute full\nconfiguration of the server via modern protocols with modern encryption and\nmodern amenities. All nodes subscribe to a publisher node, which is in \"legacy\"\nterms the \"master\" or \"owner\" of the network. The publisher is responsible for\ndistributing configuration to the other nodes.\n\nBorder does not depend on a consensus database. It holds its own elections and\nit is strongly recommended for this reason you run an even number of nodes in a\nproduction configuration, so that when a service goes down, an election can be\nheld and it will be guaranteed that one will win eventually.\n\n## Rationale\n\nWhy do this?\n\nIn typical scenarios, you have one of a few configurations that all have their\nown problems:\n\n- In many cases, you have fixed IPs provided via a very rigidly deployed DNS\n  service. Virtual IPs, or technologies like BGP and Anycast are employed to\n  retain the value of these IP addresses. DNS is, in this case, a very brittle\n  lynchpin providing static records to the network which when modified, tend to\n  cause chaos as it is a major event.\n\n- Other cases leverage a round-robin distribution of A records with a very\n  short TTL on the DNS server. This increases load to the DNS service, which is\n  usually not an issue, but also increases the severity of a DNS outage. This\n  works well with e.g. haproxy, but if the haproxy is removed prematurely to a\n  DNS change, there will be forced network hiccups.\n\n- Other, simpler configurations either stack load balancers, proxy from haproxy\n  to a secondary proxying webserver, e.g., nginx, but no matter how this is\n  sliced, there is a single point of failure: the load balancer, but usually\n  DNS is also a notable point of failure in the event the host running the load\n  balancer is lost.\n\nAdditionally, third party health monitoring must be employed for all these\nscenarios. The beauty of Border is that it monitors itself through the\nconjunction of both protocols combined with consensus.\n\nBorder cannot eliminate all failures. TCP is still TCP and when the connection\nis gone, TCP must do something about that, which is usually to simply fail the\nconnection. Border, however, tries to eliminate the administrative overhead of\nsuch an event.\n\n## Features\n\nBorder is trying to pack a lot of features and not just be a simple tool. We\nare dedicated to bringing a richer experience to fronting websites for\nadministrators.\n\n- [x] Provides TCP and HTTP Load Balancing\n- [ ] TLS Termination\n- [ ] Load Balancing of less typical DNS situations, such as SRV records (think\n      tools like Samba or LDAP).\n- [x] Health checks are a part of DNS, and when a health check is failed, DNS\n      is automatically adjusted.\n- [x] Zone Transfers do not use the unwieldy and frequently insecure AXFR\n      protocol, instead opting for the protections provided by JOSE. Full\n      configuration is synced, not just zones.\n- [ ] Built-in Let's Encrypt and ACME support\n  - [ ] For TLS Termination\n  - [ ] For DNSSEC (still need to look deeper into this one)\n- [x] Self-Distributing architecture means fire-and-forget deployments, and a\n      fully STONITH (Shoot the offending node in the head) architecture.\n- [ ] ngrok-like agent to help border traverse NAT firewalls as well as more\n      entrenched network configurations behind e.g. Corporate Firewalls.\n- [ ] Split Horizon support baked into the service, on a per network and per zone basis.\n- [ ] Capacity management in the config, e.g., \"this webserver can handle 10k\n      connections at a time, and that one can handle 5k, so don't route more than\n      that there\".\n  - [ ] Consensus based connection tracking so that load balancers can manage\n        all servers in a criss-cut pattern, not just pool of servers that are lost\n        when the balancer goes down.\n- [ ] We are debating adding a caching proxy ala Squid / Varnish, as it may\n      also be a good fit in this service with a minimal footprint overall.\n\n## Some operational notes\n\n[Here](example.yaml) is an example configuration. Documentation will come soon,\nbut this displays most of the service's features at this time.\n\nElections are held when the publisher is no longer responsive. This is a\nconfigurable parameter (at least, eventually). At the point an election is\nheld, all members vote for the service with what they think has the highest\nuptime. This should result in a clear winner as if the publisher has been\nworking up to this point, this information should be communicated in the\nconfiguration.\n\nThe appropriate cadence for replacing a failing or terminated load balancer is\nsuch:\n\n- Termination event of original load balancer\n- Wait for health checks to fail, and any necessary elections to complete. This\n  takes approximately a second.\n- Create a new peer in the configuration, and send it `border client\nupdateconfig \u003cmyconfigfile\u003e` to the publisher. You can use `border client\nidentifypublisher` to determine the publisher.\n- Start the new peer with the updated configuration.\n\nPlease note that between the termination point and the raise of the new\ninstance, that unless you have lost _all_ border nodes, health checking will\nautomatically heal the affected load balancing and DNS records pointing at the\nfailed instance. This works _today_.\n\nLoad Balancers are configured like a DNS record. The A records for a website\nare maintained as records pointing to border. Contrast with ALIAS records on\nAmazon Web Services' Route 53 and Elastic Load Balancer. Each one will have\nconfigurable parameters similar to a SOA record's notion of TTL and cache.\n\nBorder agents (tunneling proxy) will use JOSE keys to identify themselves to\nthe network instead of an IP address, and their DNS records will represent\nthat. Contrast with a SPF record's use of the TXT record type.\n\nBorder agent is a well documented and well specified protocol that can be\nimplemented by web service frameworks as well as web servers themselves such as\nCaddy or Nginx.\n\nBorder's impact on whois distribution basically expects you to use higher TTL\nrecords and let the DNS protocol do its job properly, allowing for fallback to\nother nameservers. In the event a nameserver fails, A quorum of 4 nameservers\nshould keep another three alive, allowing you to adjust the whois records in the\nevent the host is completely lost. We feel this is a safer DR strategy than\ninvesting a lot of infrastructure into retaining the IP addresses at all costs,\nas it is much simpler to maintain.\n\n## Status\n\nBorder is in an early alpha stage. It is functional, but lacks many of the\nfeatures you would expect from a product of its type. Encouragement, testing,\nand patches (!) are strongly encouraged, but \"betting the farm\" on this product\nat this point would be an impressive display of your own lack of wisdom.\n\n## Author\n\nErik Hollensbe \u003cerik+github@hollensbe.org\u003e\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Ferikh%2Fborder","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Ferikh%2Fborder","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Ferikh%2Fborder/lists"}