Discovery: Document DNS redirection - CNAME

[oej]

Document how and if CNAME can be used for redirection, like to a service provider. Will/can it lead to new URI regulation at that level.

[oej]

There are two cases

• TEI discovery using URI DNS records -> http url -> CNAME redirection
• Using the DNS name in the TEI URI directly and getting a CNAME

We need to figure out the rules for CNAME resolution and figure out how this relates to use cases and if we need to write something extra in the implementation guide on where CNAME resolution fits in.

[oej]

References:

• https://en.wikipedia.org/wiki/CNAME_record
• https://www.rfc-editor.org/rfc/rfc9460.pdf -> Not CNAME but other records

[oej]

Ok, checked with a person who is a member of the IETF DNS Directorate. The CNAME can be used in the TEI resolution, i.e.

• A TEA client asks for a URI record for "products.example.com"
• DNS finds a CNAME at "products.example.com" pointing to "teapot.example.org"
• The resolver now checks for the URI record for "teapot.example.org" and returns the resulting URI's.

[oej]

Document hosted solution fully including TLS validation.

[oej]

It can also be used to separate product groups/divisions in an enterprise. Like "brushes.examples.com" and "fax machines.examples.com"

[ppkarwasz]

While CNAME is one possible way to perform a redirection, we could also introduce a rule like DMARC uses:

• if _tei._tcp.bar.foo.org is not present, check _tei._tcp.foo.org.

[vpetersson]

TLS aside, this is how I envision the flow to look like:

sequenceDiagram
    autonumber
    actor User
    
    participant tea_client as TEA Client
    participant dns_server as DNS Server
    participant tea_server as TEA Server
    participant tea_product as TEA Product

    User ->> tea_client: User requests TEI 'urn:tei:uuid:products.example.com:d4d9f54a-abcf-11ee-ac79-1a52914d44b1'
    tea_client ->> dns_server: Client request resolution for the CNAME records corresponding to products.example.com 
    dns_server ->> tea_client: DNS server responds with the CNAME for the 3rd TEA server (tea.3rdparty.com)
    tea_client ->> dns_server: Client resolves the IP for the CNAME/A-record tea.3rdparty.com
    dns_server ->> tea_client: IP a.b.c.d is returned 
    Note over tea_client,tea_server: The initial HOST Header is preserved (i.e. products.example.com) when making the HTTP request
    tea_client ->> tea_server: A GET request is made towards the a.b.c.d with the GET parameter `uuid=d4d9f54a-abcf-11ee-ac79-1a52914d44b1`
    tea_server ->> tea_product: The request is routed to the corresponding tenant (based on HOST) assuming a multi-tenant environment
    tea_product ->> tea_client: The leaf collection(s) are returned

Loading

This diagram assumes a TEA Client (which we've discussed before), that knows how to interpret a tei.

Also, note that both Cloudflare and AWS do support DNS failover for CNAMEs.

As far as TLS goes, to me, this is a solved problem. Since we are dealing with HTTP(s), it's not a responsibility of the TEA service, but rather the HTTP server. If we look at Let's Encrypt (which is more or less the standard these days), they support multiple challenge types, including .well-known/acme-challenge.

[oej]

So you suggest that a hosting provider needs to host one web site per customer?

I'm not sure everyone is happy with that. Regardless, I'll start writing something up on multitenancy and we can discuss further. Thanks for your input.

BTW, we can't build solely for large cloud providers. We have to support them, but not assume that they are the platform.

[vpetersson]

So you suggest that a hosting provider needs to host one web site per customer?
I'm not sure everyone is happy with that. Regardless, I'll start writing something up on multitenancy and we can discuss further. Thanks for your input.

No, not at all. This model doesn't by any means require a single tenancy setup. You may want to run a single app server per tenant behind a load balancer/reverse proxy (where HTTS is terminated), but that doesn't really change the workflow. The only difference is if you reverse proxy the request to a dedicated app server per client or a shared one. If a shared/multi-tenancy app server is used, you'd probably use X-FORWARDED-FOR to serve the right customer.

If we borrow a playbook out of something that is very widespread, namely WordPress hosting, this is essentially what they do.

As far as the implementation goes, it would be fairly straight forward (again, this is how most WordPress providers and similar) are able to offer TLS:

sequenceDiagram
    autonumber
    actor customer as Customer
    actor user as User
    participant tsp as TEA Service Provider
    participant dns_server as DNS Server

    participant le as Let's Encrypt
    participant rp as Reverse Proxy/Load Balancer
    participant tea_product as TEA Product

    customer ->> tsp: Signs up for an account and provides their desired CNAME (e.g. products.example.com)
    tsp ->> customer: Provides the CNAME that product.example.com needs to point to (e.g. tsp.foobar.com)
    tsp ->> dns_server: Begins validation process to ensure products.example.com resolves to tsp.foobar.com
    tsp ->> rp: Provision a virtual host (HTTP) for products.example.com
    tsp ->> le: Begins certification process and requests a HTTP-01 challenge for products.example.com
    le ->> tsp: Certificate issued
    tsp ->> rp: Virtual host upgraded to HTTPS with issued certificate
    tsp ->> customer: Provisioning completed
    user ->> tea_product: Users can now request TEI data via the Reverse Proxy over HTTPS

Loading

As for how the load balancer/reverse proxy utilizes the TLS certificate, this will vary. As you mentioned before, there's Server Name Indication (SNI), which is what Kubernetes ingress-nginx controller users for instance. This is likely the best and most scalable way to do it.

However, for smaller installations, you could also use a single certificate with multiple domains. certbot, which is a popular Let's Encrypt/ACME client allows you to use --expand to generate a single certificate that spans a long list of domains. This however does create a bit of a single point of failure (in addition to leaking all other domains in the certificate), but it is possible.

BTW, we can't build solely for large cloud providers. We have to support them, but not assume that they are the platform.

It's not a requirement. It's just that they are the only ones supporting DNS Failover, which is a non-standard DNS feature.

[oej]

DNS failover is NOT a non-standard DNS feature. It may not be used in many HTTP instances, but assuming that DNS failover is not used is very very wrong.

[oej]

btw. I haven't seen a single of the large providers supporting DNS failover. They build with BGP and IP anycast instead, something that is very costly for smaller entities.

[vpetersson]

btw. I haven't seen a single of the large providers supporting DNS failover. They build with BGP and IP anycast instead, something that is very costly for smaller entities.

I'm not sure that I follow. Cloudflare and AWS Route 53 both support it and are some of the biggest DNS providers globally.

[oej]

We are talking about different things. Let's sort that out in a conversation.