GOPHERSPACE.DE - P H O X Y
gophering on colincogle.name
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


"Using SVCB Records for Gopher"
by Colin Cogle

Written November 8, 2022.
Online at: gopher://colincogle.name/blog/gopher-svcb/

ABSTRACT
Old technology meets a new DNS resource record type, in hopes that some
ambitious Gopher client will adopt it.


INTRODUCTION
Look, there are far more important things in the country and world now.
However, when I got around to adding HTTPS DNS records for my web site
into my DNS zone, I decided to think about what it would look like for
other services, such as Gopher.


BACKGROUND
For those who don't know, this standard (still in draft) allows someone
to publish service binding information in DNS. For HTTPS, this includes
the port number  (great, as HTTP/3 is not tied to a specific UDP port).
By putting this in DNS,  clients do not need to initiate an HTTP/1.1 or
HTTP/2 connection in order to find out the HTTP/3 information.   A very
ambitious webmaster can also publish IP addresses here  (to avoid extra
A/AAAA lookups),  Encrypted ClientHello information,  and accepted ALPN
values.

For this article, though, I'm looking at the ServiceMode function of
the SVCB record.  Let's implement a proof-of-concept that I admit few
if any Gopher clients will ever support.


PROVIDING CLIENT HINTS
For a TCP-based connection like Gopher, this first portion is going to
be largely pointless.   (However, the Gemini protocol supports virtual
hosting, so this might serve a purpose there.)

The SVCB record contains underscores, much like DANE (TLSA) records do.
Likewise, it's also named with the port and the URL scheme.   Thus, for
Gopher, we're going to name this resource record "_70._gopher".

We can provide the following keys for our SVCB record:
  - "port" to specify a port number.  In theory, this would let a SVCB-
     aware client implicitly connect to a different port.
  - "ipv4hint" to provide the client with an IPv4 address, to save the
    round-trip time of fetching an A record.  (DNS64/NAT64 servers are
implicitly allowed to synthesize an IPv6-mapped address.)
  - "ipv6hint" to provide the client with an IPv6 address, to save the
    round-trip time of fetching a AAAA record.

Let's put it all together into a DNS record.   In BIND format, it would
look something like this.  (Note that "1" and "." have semantic meaning
in the draft standard, which I won't bore you with here.)

```
$ORIGIN colincogle.name.

; I'm breaking this onto two lines for readability.  You don't need to.

_70._gopher IN SVCB  1 . (port="70" ipv4hint="34.205.210.157"
                          ipv6hint="2600:1f18:40f3:9a00::ec2:1")
```

In theory, this will speed up Gopher connections.  Let's continue.


DNS-BASED LOAD BALANCING
I run a backup Gopher instance on another server, with the same content
on both.   Thus, I effectively have a mirror, and can offer clients the
option to connect to both.  In my zone file:

```
$ORIGIN colincogle.name.
_70._gopher IN SVCB  1 . (port="70" ipv4hint="34.205.210.157"
                          ipv6hint="2600:1f18:40f3:9a00::ec2:1")
_70._gopher IN SVCB  1 . (port="70" ipv4hint="51.159.186.85"
                          ipv6hint="2001:bc8:1202:1324::1")
```

SECURE GOPHER CONNECTIONS WILL BE FINE
The vast majority of Gopher traffic is unencrypted.  However, the Gopher
community has added support for explicit TLS.

If you look at my new SVCB records, you'll notice that some of the hints
point to two different servers, that have two different TLS certificates
with two different subjects and SubjectAltNames. You'd expect that would
break certificate validation. Fortunately, the designers of SVCB planned
planned for this scenario.   As their work was based on the HTTP Alt-Svc
header, the SVCB draft standard says, "clients MUST continue to validate
TLS certificate hostnames based on the origin."

As I discovered while working on my PowerShell Gopher client, PSGopher,
client apps use the regular gopher:// URL scheme for secure connections.
However, some require gophers://, sgopher://, or even gopher+tls:// for
TLS to be negotiated.   You might want to add matching SVCB records for
each possible scheme, to make sure your SVCB records don't get ignored.


CONCLUSION
I hope you enjoyed this little Gopher-exclusive post. There's no chance
that any Gopher client will be updated to support SVCB records, so this
was time wasted, but still a good thought exercise nonetheless.

If you *are* a Gopher client developer with too much time on your hands,
you can use my published SVCB records for testing.


WORKS CITED
Bishop, Mike.  "Service binding and parameter specifications via the DNS
    (DNS SVCB and HTTPS RRs), draft-ietf-dnsop-svcb-https11."  11
October 2022.  Accessed 8 November 2022.
https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/11/
SoByte.  "Introduction to DNS SVCB/HTTPS records."  7 January 2022. 
    Accessed 8 November 2022. https://sobyte.net/post/2022-01/dns-svcb-https/
 
-----BEGIN PGP SIGNATURE-----

iHUEARYIAB0WIQQ7NZ6ap/Bjr/sGU4FSrfh98PoTfwUCY2pp3wAKCRBSrfh98PoT
fzOSAP9SAjZIaP/XfnZsavgwJZNESiGWI5+TXy6594siRXVBOgD9FXkhwKTgzRTb
bqwry8OEFJ8fBb2SUo7VkfFkJByMIgA=
=cChz
-----END PGP SIGNATURE-----