Thicket data repository for the EEG
anil.recoil.org
1{
2 "id": "https://ryan.freumh.org/eon.html",
3 "title": "Eon",
4 "link": "https://ryan.freumh.org/eon.html",
5 "updated": "2025-04-21T00:00:00",
6 "published": "2025-04-21T00:00:00",
7 "summary": "<div>\n \n <span>Published 21 Apr 2025.</span>\n \n \n </div>\n \n <div> Tags: <a href=\"/research.html\" title=\"All pages tagged 'research'.\">research</a>, <a href=\"/projects.html\" title=\"All pages tagged 'projects'.\">projects</a>, <a href=\"/self-hosting.html\" title=\"All pages tagged 'self-hosting'.\">self-hosting</a>. </div>\n \n \n\n <p><span><a href=\"https://github.com/ryanGibb/eon\">Eon</a>\nis an Effects-based OCaml Nameserver using <a href=\"https://mirage.io/\">MirageOS</a>’s functionally pure Domain Name\nSystem (DNS) <a href=\"https://github.com/mirage/ocaml-dns\">library</a>\nwith <a href=\"https://github.com/ocaml-multicore/eio\">direct-style\nIO</a> (as opposed to <a href=\"https://en.wikipedia.org/wiki/Monad_(functional_programming)#IO_monad_(Haskell)\">monadic\nIO</a>) using <a href=\"https://ocaml.org/releases/5.0.0\">OCaml 5</a>’s\n<a href=\"https://ocaml.org/manual/5.0/effects.html\">effect handlers</a>\n<span><a href=\"#ref-sivaramakrishnanRetrofittingEffectHandlers2021\">[1]</a></span> created as the basis to implement\nsome of ideas from the <a href=\"sns.html\">Spatial Name\nSystem</a>.</span></p>\n<h2>DNS Tunnelling</h2>\n<p><span>DNS is well-known to be used for <a href=\"https://en.wikipedia.org/wiki/Data_exfiltration\">data\nexfiltration</a> and <a href=\"https://en.wikipedia.org/wiki/Tunneling_protocol\">tunneling</a>,\nsince DNS is one of the few protocols that’s almost always allowed\nthrough a firewall (at least through a recursive resolver) since it’s so\nfundamental to the operation of the Internet. I’ve implemented a\ntransport layer over DNS <a href=\"https://github.com/RyanGibb/eon/tree/main/lib/transport\">in\nEon</a>, a simple <a href=\"https://github.com/RyanGibb/eon/tree/main/bin/transport/netcat\">netcat</a>\nexample shows how this can be used to transport data using DNS queries.\nMany thanks to <a href=\"https://github.com/panglesd\">Paul-Elliot</a> for\nhelping clean up the transport interface and making it more\nidiomatically functional. At the moment there’s no multiplexing – a\nserver can only handle one communication at a time, but that could\naddresses by adding a demultiplexing field (a ‘port’).</span></p>\n<p><span>The well-defined interfaces that\nOCaml gives us allows this to be combined in interesting ways, such as a\n<a href=\"https://github.com/RyanGibb/eon/tree/main/bin/transport/sod\">shell\nover DNS</a> (SoD), or an <a href=\"https://github.com/RyanGibb/eon/tree/main/bin/transport/tunnel\">IP\ntunnel</a>. Note that you wouldn’t want to use this in production\nwithout some form of encryption (maybe <a href=\"https://github.com/mirleft/ocaml-tls\">ocaml-tls</a>?) and\nauthentication (e.g. public/private keys, or capabilities). A standalone\nexample of a capability interface to a shell can be found at <a href=\"https://github.com/RyanGibb/capability-shell\">capability-shell</a>.</span></p>\n<p><span>There’s some interesting performance\ncharacteristics of this tunneling in a variable asymmetry of latency\nbetween the sender and receiver, since we’re retrofitting bidirectional\npacket switching onto a request response protocol. That is, for the DNS\nserver to send data to a client it has to have a query to respond to. We\ncan’t wait to respond to a query until we have data, since recursive\nresolvers aggressively timeout and return a <code>SERVFAIL</code> in the case of a delayed reply. So we\nhave the client periodically poll the server with queries containing no\ndata, so the latency of the server to client link is bounded by the\nperiod of this polling.</span></p>\n<p><span>This is interesting as it allows us\nto bootstrap communication with a nameserver using nothing but\nDNS.</span></p>\n<h2>Capability Interface</h2>\n<p><span>DNS is an old protocol, and\nhas some baked-in limitations due to <a href=\"https://en.wikipedia.org/wiki/Protocol_ossification\">protocol\nossification</a> (such as a maximum domain name length of 255 bytes).\nThe ‘back-end’ of the protocol, interactions between services under your\ncontrol, is easier to evolve. The AXFR zone transfers defined with the\nDomain Name System <span><a href=\"#ref-DomainNamesImplementation1987\">[2]</a></span> are often replaced with some form of\ndatabase replication in nameserver implementations. Dynamic updates\n<span><a href=\"#ref-vixieDynamicUpdatesDomain1997\">[3]</a></span> using secret key transaction\nsignatures <span><a href=\"#ref-eastlake3rdSecretKeyTransaction2000\">[4]</a></span> are often eschewed in favour of\ncustom APIs<a href=\"#fn1\">1</a>. While using these protocols allows\nan variety of nameserver implementations to interoperate, in practice\nthey are often replaced with custom solutions.</span></p>\n<p><span>We’ve experimented with a <a href=\"https://github.com/RyanGibb/eon/blob/main/lib/cap/schema.capnp\">programmable\ninterface</a> to the nameserver with <a href=\"https://capnproto.org/\">Cap’n Proto</a> <a href=\"https://en.wikipedia.org/wiki/Capability-based_security\">capability</a>-<a href=\"http://www.erights.org/elib/capability/ode/index.html\">based</a>\nRPCs. This creates capabilities for dynamically updating a domain, or\nreceiving a zonefile and dynamic updates as a secondary nameserver.\nPlease feel free to try deploying it for your own domain, and get <a href=\"about.html\">in touch</a> if you’d like to set up a reciprocal\nsecondarying relationship.</span></p>\n<h2>Names Have Power</h2>\n<p><span>Having a programmable interface\ninto the domain name system is powerful, because domain names are\npowerful. Domain names are the root of identity for the Internet\nprotocol suite. Federated communication networks derive user’s identify\nfrom domain names including <a href=\"https://matrix.org/\">Matrix</a>, <a href=\"https://joinmastodon.org/\">Mastodon</a>, Bluesky’s AT Protocol\n<span><a href=\"#ref-kleppmannBlueskyProtocolUsable2024\">[5]</a></span>, and good old <a href=\"https://www.rfc-editor.org/rfc/rfc822\">E-Mail</a>.</span></p>\n<p><span>The DNS is also used to prove\nowership of domains. The security of the modern internet is built on the\nTransport Layer Security (TLS) protocol <span><a href=\"#ref-allenTLSProtocolVersion1999\">[6]</a></span>, which uses X509 certificates signed\nby certificate authorities. The Internet Security Research Group\n(ISRG)’s Let’s Encrypt certificate authority (CA) provides the <a href=\"https://w3techs.com/technologies/overview/ssl_certificate\">majority</a>\nof the Internet’s certificates, over 500 million <a href=\"https://letsencrypt.org/stats/\">in 2025</a>. Traditionally\nprovisioning a certificate was costly and manual process, but the\nAutomatic Certificate Management Environment (ACME) protocol <span><a href=\"#ref-barnesAutomaticCertificateManagement2019\">[7]</a></span> used by Let’s Encrypt allows for an\nautomated provisioning of certificates by proving ownership of a domain\nby displaying a token with one of a number of challenges; HTTP,\nTLS-ALPN, and DNS.</span></p>\n<p><span>Only the DNS challenge is possible\nif the address the domain name points to is not publicly accessible,\nwhich is often the case for remote and resource constrained devices\nbehind NATs or firewalls. However, it requires a <a href=\"https://certbot-dns-rfc2136.readthedocs.io/en/stable/\">complex\ndance</a> of managing DNS UPDATE keys and specifying the subdomain and\nzone which it can modify. With our <a href=\"#capability-interface\">capability interface</a> to the nameserver\nwe can expose fine-grained access control to provision a certificate for\na subdomain.</span></p>\n<h2>Wake-on-DNS</h2>\n<p><span>Motivated by a desire to curb the power\nuse of self-hosted services which are often idle for large periods of\ntime, such as <a href=\"nas.html\">storage servers</a>, we implemented <a href=\"https://github.com/RyanGibb/eon/tree/main/bin/hibernia\">hibernia</a>\nnameserver than can wake a machine up on a name resolution with Eon and\na OCaml <a href=\"https://en.wikipedia.org/wiki/Wake-on-LAN\">Wake-on-LAN</a> <a href=\"https://github.com/RyanGibb/ocaml-wake-on-lan\">implementation</a>.\nWe published this idea as ‘<a href=\"papers.html#carbon-aware-name-resolution\">Carbon-aware Name\nResolution</a>’ in <a href=\"https://sicsa.ac.uk/loco/loco2024/\">LOCO2024</a>.</span></p>\n<h2>What next?</h2>\n<p><span>I’m looking at extending this interface\nto support additional functionality for networked services such as\nstorage, identity, and more. <a href=\"eilean.html\">Eilean</a> is an\nattempt to parameterise a federated service deployment by a domain name\nleveraging the NixOS deployment system to do so, but it lacks a runtime\ncomponent.</span></p>\n<div>\n<div>\n<span><div>[1] </div><div>K. Sivaramakrishnan, S. Dolan, L. White, T.\nKelly, S. Jaffer, and A. Madhavapeddy, <span>“Retrofitting effect\nhandlers onto <span>OCaml</span>,”</span> in <em>Proceedings of the 42nd\n<span>ACM SIGPLAN International Conference</span> on <span>Programming\nLanguage Design</span> and <span>Implementation</span></em>, Jun. 2021,\npp. 206–221, doi: <a href=\"https://doi.org/10.1145/3453483.3454039\">10.1145/3453483.3454039</a>\n[Online]. Available: <a href=\"https://dl.acm.org/doi/10.1145/3453483.3454039\">https://dl.acm.org/doi/10.1145/3453483.3454039</a>.\n[Accessed: Mar. 04, 2022]</div></span>\n</div>\n<div>\n<span><div>[2] </div><div><span>“Domain names - implementation and\nspecification,”</span> Internet Engineering Task Force, Request for\nComments RFC 1035, Nov. 1987 [Online]. Available: <a href=\"https://datatracker.ietf.org/doc/rfc1035\">https://datatracker.ietf.org/doc/rfc1035</a>.\n[Accessed: May 15, 2022]</div></span>\n</div>\n<div>\n<span><div>[3] </div><div>P. A. Vixie, S. Thomson, Y. Rekhter, and J.\nBound, <span>“Dynamic <span>Updates</span> in the <span>Domain Name\nSystem</span> (<span>DNS UPDATE</span>),”</span> Internet Engineering\nTask Force, Request for Comments RFC 2136, Apr. 1997 [Online].\nAvailable: <a href=\"https://datatracker.ietf.org/doc/rfc2136\">https://datatracker.ietf.org/doc/rfc2136</a>.\n[Accessed: Jun. 30, 2023]</div></span>\n</div>\n<div>\n<span><div>[4] </div><div>D. E. Eastlake 3rd, Ó. Guðmundsson, P. A.\nVixie, and B. Wellington, <span>“Secret <span>Key Transaction\nAuthentication</span> for <span>DNS</span> (<span>TSIG</span>),”</span>\nInternet Engineering Task Force, Request for Comments RFC 2845, May 2000\n[Online]. Available: <a href=\"https://datatracker.ietf.org/doc/rfc2845\">https://datatracker.ietf.org/doc/rfc2845</a>.\n[Accessed: Oct. 22, 2023]</div></span>\n</div>\n<div>\n<span><div>[5] </div><div>M. Kleppmann <em>et al.</em>, <span>“Bluesky\nand the <span>AT Protocol</span>: <span>Usable Decentralized Social\nMedia</span>,”</span> in <em>Proceedings of the <span>ACM Conext-2024\nWorkshop</span> on the <span>Decentralization</span> of the\n<span>Internet</span></em>, Dec. 2024, pp. 1–7, doi: <a href=\"https://doi.org/10.1145/3694809.3700740\">10.1145/3694809.3700740</a>\n[Online]. Available: <a href=\"http://arxiv.org/abs/2402.03239\">http://arxiv.org/abs/2402.03239</a>.\n[Accessed: Mar. 25, 2025]</div></span>\n</div>\n<div>\n<span><div>[6] </div><div>C. Allen and T. Dierks, <span>“The <span>TLS\nProtocol Version</span> 1.0,”</span> Internet Engineering Task Force,\nRequest for Comments RFC 2246, Jan. 1999 [Online]. Available: <a href=\"https://datatracker.ietf.org/doc/rfc2246\">https://datatracker.ietf.org/doc/rfc2246</a>.\n[Accessed: Mar. 25, 2025]</div></span>\n</div>\n<div>\n<span><div>[7] </div><div>R. Barnes, J. Hoffman-Andrews, D. McCarney, and\nJ. Kasten, <span>“Automatic <span>Certificate Management\nEnvironment</span> (<span>ACME</span>),”</span> Internet Engineering\nTask Force, Request for Comments RFC 8555, Mar. 2019 [Online].\nAvailable: <a href=\"https://datatracker.ietf.org/doc/rfc8555\">https://datatracker.ietf.org/doc/rfc8555</a>.\n[Accessed: Jun. 26, 2023]</div></span>\n</div>\n</div>\n\n\n\n\n<ol>\n<li><p><span>Note that prior\nto TSIG introduced with DNSSEC, DNS UPDATEs and zone transfers were\ntypically enforced with IP-based access control.</span><a href=\"#fnref1\">↩︎</a></p></li>\n</ol>",
8 "content": "<div>\n \n <span>Published 21 Apr 2025.</span>\n \n \n </div>\n \n <div> Tags: <a href=\"/research.html\" title=\"All pages tagged 'research'.\">research</a>, <a href=\"/projects.html\" title=\"All pages tagged 'projects'.\">projects</a>, <a href=\"/self-hosting.html\" title=\"All pages tagged 'self-hosting'.\">self-hosting</a>. </div>\n \n \n\n <p><span><a href=\"https://github.com/ryanGibb/eon\">Eon</a>\nis an Effects-based OCaml Nameserver using <a href=\"https://mirage.io/\">MirageOS</a>’s functionally pure Domain Name\nSystem (DNS) <a href=\"https://github.com/mirage/ocaml-dns\">library</a>\nwith <a href=\"https://github.com/ocaml-multicore/eio\">direct-style\nIO</a> (as opposed to <a href=\"https://en.wikipedia.org/wiki/Monad_(functional_programming)#IO_monad_(Haskell)\">monadic\nIO</a>) using <a href=\"https://ocaml.org/releases/5.0.0\">OCaml 5</a>’s\n<a href=\"https://ocaml.org/manual/5.0/effects.html\">effect handlers</a>\n<span><a href=\"#ref-sivaramakrishnanRetrofittingEffectHandlers2021\">[1]</a></span> created as the basis to implement\nsome of ideas from the <a href=\"sns.html\">Spatial Name\nSystem</a>.</span></p>\n<h2>DNS Tunnelling</h2>\n<p><span>DNS is well-known to be used for <a href=\"https://en.wikipedia.org/wiki/Data_exfiltration\">data\nexfiltration</a> and <a href=\"https://en.wikipedia.org/wiki/Tunneling_protocol\">tunneling</a>,\nsince DNS is one of the few protocols that’s almost always allowed\nthrough a firewall (at least through a recursive resolver) since it’s so\nfundamental to the operation of the Internet. I’ve implemented a\ntransport layer over DNS <a href=\"https://github.com/RyanGibb/eon/tree/main/lib/transport\">in\nEon</a>, a simple <a href=\"https://github.com/RyanGibb/eon/tree/main/bin/transport/netcat\">netcat</a>\nexample shows how this can be used to transport data using DNS queries.\nMany thanks to <a href=\"https://github.com/panglesd\">Paul-Elliot</a> for\nhelping clean up the transport interface and making it more\nidiomatically functional. At the moment there’s no multiplexing – a\nserver can only handle one communication at a time, but that could\naddresses by adding a demultiplexing field (a ‘port’).</span></p>\n<p><span>The well-defined interfaces that\nOCaml gives us allows this to be combined in interesting ways, such as a\n<a href=\"https://github.com/RyanGibb/eon/tree/main/bin/transport/sod\">shell\nover DNS</a> (SoD), or an <a href=\"https://github.com/RyanGibb/eon/tree/main/bin/transport/tunnel\">IP\ntunnel</a>. Note that you wouldn’t want to use this in production\nwithout some form of encryption (maybe <a href=\"https://github.com/mirleft/ocaml-tls\">ocaml-tls</a>?) and\nauthentication (e.g. public/private keys, or capabilities). A standalone\nexample of a capability interface to a shell can be found at <a href=\"https://github.com/RyanGibb/capability-shell\">capability-shell</a>.</span></p>\n<p><span>There’s some interesting performance\ncharacteristics of this tunneling in a variable asymmetry of latency\nbetween the sender and receiver, since we’re retrofitting bidirectional\npacket switching onto a request response protocol. That is, for the DNS\nserver to send data to a client it has to have a query to respond to. We\ncan’t wait to respond to a query until we have data, since recursive\nresolvers aggressively timeout and return a <code>SERVFAIL</code> in the case of a delayed reply. So we\nhave the client periodically poll the server with queries containing no\ndata, so the latency of the server to client link is bounded by the\nperiod of this polling.</span></p>\n<p><span>This is interesting as it allows us\nto bootstrap communication with a nameserver using nothing but\nDNS.</span></p>\n<h2>Capability Interface</h2>\n<p><span>DNS is an old protocol, and\nhas some baked-in limitations due to <a href=\"https://en.wikipedia.org/wiki/Protocol_ossification\">protocol\nossification</a> (such as a maximum domain name length of 255 bytes).\nThe ‘back-end’ of the protocol, interactions between services under your\ncontrol, is easier to evolve. The AXFR zone transfers defined with the\nDomain Name System <span><a href=\"#ref-DomainNamesImplementation1987\">[2]</a></span> are often replaced with some form of\ndatabase replication in nameserver implementations. Dynamic updates\n<span><a href=\"#ref-vixieDynamicUpdatesDomain1997\">[3]</a></span> using secret key transaction\nsignatures <span><a href=\"#ref-eastlake3rdSecretKeyTransaction2000\">[4]</a></span> are often eschewed in favour of\ncustom APIs<a href=\"#fn1\">1</a>. While using these protocols allows\nan variety of nameserver implementations to interoperate, in practice\nthey are often replaced with custom solutions.</span></p>\n<p><span>We’ve experimented with a <a href=\"https://github.com/RyanGibb/eon/blob/main/lib/cap/schema.capnp\">programmable\ninterface</a> to the nameserver with <a href=\"https://capnproto.org/\">Cap’n Proto</a> <a href=\"https://en.wikipedia.org/wiki/Capability-based_security\">capability</a>-<a href=\"http://www.erights.org/elib/capability/ode/index.html\">based</a>\nRPCs. This creates capabilities for dynamically updating a domain, or\nreceiving a zonefile and dynamic updates as a secondary nameserver.\nPlease feel free to try deploying it for your own domain, and get <a href=\"about.html\">in touch</a> if you’d like to set up a reciprocal\nsecondarying relationship.</span></p>\n<h2>Names Have Power</h2>\n<p><span>Having a programmable interface\ninto the domain name system is powerful, because domain names are\npowerful. Domain names are the root of identity for the Internet\nprotocol suite. Federated communication networks derive user’s identify\nfrom domain names including <a href=\"https://matrix.org/\">Matrix</a>, <a href=\"https://joinmastodon.org/\">Mastodon</a>, Bluesky’s AT Protocol\n<span><a href=\"#ref-kleppmannBlueskyProtocolUsable2024\">[5]</a></span>, and good old <a href=\"https://www.rfc-editor.org/rfc/rfc822\">E-Mail</a>.</span></p>\n<p><span>The DNS is also used to prove\nowership of domains. The security of the modern internet is built on the\nTransport Layer Security (TLS) protocol <span><a href=\"#ref-allenTLSProtocolVersion1999\">[6]</a></span>, which uses X509 certificates signed\nby certificate authorities. The Internet Security Research Group\n(ISRG)’s Let’s Encrypt certificate authority (CA) provides the <a href=\"https://w3techs.com/technologies/overview/ssl_certificate\">majority</a>\nof the Internet’s certificates, over 500 million <a href=\"https://letsencrypt.org/stats/\">in 2025</a>. Traditionally\nprovisioning a certificate was costly and manual process, but the\nAutomatic Certificate Management Environment (ACME) protocol <span><a href=\"#ref-barnesAutomaticCertificateManagement2019\">[7]</a></span> used by Let’s Encrypt allows for an\nautomated provisioning of certificates by proving ownership of a domain\nby displaying a token with one of a number of challenges; HTTP,\nTLS-ALPN, and DNS.</span></p>\n<p><span>Only the DNS challenge is possible\nif the address the domain name points to is not publicly accessible,\nwhich is often the case for remote and resource constrained devices\nbehind NATs or firewalls. However, it requires a <a href=\"https://certbot-dns-rfc2136.readthedocs.io/en/stable/\">complex\ndance</a> of managing DNS UPDATE keys and specifying the subdomain and\nzone which it can modify. With our <a href=\"#capability-interface\">capability interface</a> to the nameserver\nwe can expose fine-grained access control to provision a certificate for\na subdomain.</span></p>\n<h2>Wake-on-DNS</h2>\n<p><span>Motivated by a desire to curb the power\nuse of self-hosted services which are often idle for large periods of\ntime, such as <a href=\"nas.html\">storage servers</a>, we implemented <a href=\"https://github.com/RyanGibb/eon/tree/main/bin/hibernia\">hibernia</a>\nnameserver than can wake a machine up on a name resolution with Eon and\na OCaml <a href=\"https://en.wikipedia.org/wiki/Wake-on-LAN\">Wake-on-LAN</a> <a href=\"https://github.com/RyanGibb/ocaml-wake-on-lan\">implementation</a>.\nWe published this idea as ‘<a href=\"papers.html#carbon-aware-name-resolution\">Carbon-aware Name\nResolution</a>’ in <a href=\"https://sicsa.ac.uk/loco/loco2024/\">LOCO2024</a>.</span></p>\n<h2>What next?</h2>\n<p><span>I’m looking at extending this interface\nto support additional functionality for networked services such as\nstorage, identity, and more. <a href=\"eilean.html\">Eilean</a> is an\nattempt to parameterise a federated service deployment by a domain name\nleveraging the NixOS deployment system to do so, but it lacks a runtime\ncomponent.</span></p>\n<div>\n<div>\n<span><div>[1] </div><div>K. Sivaramakrishnan, S. Dolan, L. White, T.\nKelly, S. Jaffer, and A. Madhavapeddy, <span>“Retrofitting effect\nhandlers onto <span>OCaml</span>,”</span> in <em>Proceedings of the 42nd\n<span>ACM SIGPLAN International Conference</span> on <span>Programming\nLanguage Design</span> and <span>Implementation</span></em>, Jun. 2021,\npp. 206–221, doi: <a href=\"https://doi.org/10.1145/3453483.3454039\">10.1145/3453483.3454039</a>\n[Online]. Available: <a href=\"https://dl.acm.org/doi/10.1145/3453483.3454039\">https://dl.acm.org/doi/10.1145/3453483.3454039</a>.\n[Accessed: Mar. 04, 2022]</div></span>\n</div>\n<div>\n<span><div>[2] </div><div><span>“Domain names - implementation and\nspecification,”</span> Internet Engineering Task Force, Request for\nComments RFC 1035, Nov. 1987 [Online]. Available: <a href=\"https://datatracker.ietf.org/doc/rfc1035\">https://datatracker.ietf.org/doc/rfc1035</a>.\n[Accessed: May 15, 2022]</div></span>\n</div>\n<div>\n<span><div>[3] </div><div>P. A. Vixie, S. Thomson, Y. Rekhter, and J.\nBound, <span>“Dynamic <span>Updates</span> in the <span>Domain Name\nSystem</span> (<span>DNS UPDATE</span>),”</span> Internet Engineering\nTask Force, Request for Comments RFC 2136, Apr. 1997 [Online].\nAvailable: <a href=\"https://datatracker.ietf.org/doc/rfc2136\">https://datatracker.ietf.org/doc/rfc2136</a>.\n[Accessed: Jun. 30, 2023]</div></span>\n</div>\n<div>\n<span><div>[4] </div><div>D. E. Eastlake 3rd, Ó. Guðmundsson, P. A.\nVixie, and B. Wellington, <span>“Secret <span>Key Transaction\nAuthentication</span> for <span>DNS</span> (<span>TSIG</span>),”</span>\nInternet Engineering Task Force, Request for Comments RFC 2845, May 2000\n[Online]. Available: <a href=\"https://datatracker.ietf.org/doc/rfc2845\">https://datatracker.ietf.org/doc/rfc2845</a>.\n[Accessed: Oct. 22, 2023]</div></span>\n</div>\n<div>\n<span><div>[5] </div><div>M. Kleppmann <em>et al.</em>, <span>“Bluesky\nand the <span>AT Protocol</span>: <span>Usable Decentralized Social\nMedia</span>,”</span> in <em>Proceedings of the <span>ACM Conext-2024\nWorkshop</span> on the <span>Decentralization</span> of the\n<span>Internet</span></em>, Dec. 2024, pp. 1–7, doi: <a href=\"https://doi.org/10.1145/3694809.3700740\">10.1145/3694809.3700740</a>\n[Online]. Available: <a href=\"http://arxiv.org/abs/2402.03239\">http://arxiv.org/abs/2402.03239</a>.\n[Accessed: Mar. 25, 2025]</div></span>\n</div>\n<div>\n<span><div>[6] </div><div>C. Allen and T. Dierks, <span>“The <span>TLS\nProtocol Version</span> 1.0,”</span> Internet Engineering Task Force,\nRequest for Comments RFC 2246, Jan. 1999 [Online]. Available: <a href=\"https://datatracker.ietf.org/doc/rfc2246\">https://datatracker.ietf.org/doc/rfc2246</a>.\n[Accessed: Mar. 25, 2025]</div></span>\n</div>\n<div>\n<span><div>[7] </div><div>R. Barnes, J. Hoffman-Andrews, D. McCarney, and\nJ. Kasten, <span>“Automatic <span>Certificate Management\nEnvironment</span> (<span>ACME</span>),”</span> Internet Engineering\nTask Force, Request for Comments RFC 8555, Mar. 2019 [Online].\nAvailable: <a href=\"https://datatracker.ietf.org/doc/rfc8555\">https://datatracker.ietf.org/doc/rfc8555</a>.\n[Accessed: Jun. 26, 2023]</div></span>\n</div>\n</div>\n\n\n\n\n<ol>\n<li><p><span>Note that prior\nto TSIG introduced with DNSSEC, DNS UPDATEs and zone transfers were\ntypically enforced with IP-based access control.</span><a href=\"#fnref1\">↩︎</a></p></li>\n</ol>",
9 "content_type": "html",
10 "categories": [],
11 "source": "https://ryan.freumh.org/atom.xml"
12}