Add custom DNS zone docs for VNet

[ravicious]

#42550 adds docs for end users, this PR adds docs for admins.

This is mostly the "Custom DNS zones" section of the RFD made into a guide.

[ravicious]

I'm not sure if it's fine to use <Var /> within the introductory paragraph like this. I haven't really seen that anywhere else, maybe other than in Helm AWS docs. But even there it's not at the very top and has its own admonition box.

[ptgott]

I would make this more general in the intro paragraph. I think it would make sense to remove the text beginning "We are going to..." in this paragraph and move it further in the guide, closer to where we tell the user how to run the demo.

[ptgott]

I would make this more general in the intro paragraph. I think it would make sense to remove the text beginning "We are going to..." in this paragraph and move it further in the guide, closer to where we tell the user how to run the demo.

[ptgott]

I would rephrase this—if there are multiple Proxy Service instances, would this capture queries to the Web UI URL for the cluster, or would there ever be multiple Proxy Service domains?

[ravicious]

I rephrased it and used a concrete example to make it easier to understand.

[ravicious]

@nklaassen I feel like this is kinda subpar in terms of "AX" (admin experience). What if VNet picked an arbitrary non-default range if present? Then instead of setting the range on each leaf cluster, an admin could set it only on the root cluster.

[nklaassen]

I don't believe this paragraph is entirely accurate. Each app should be assigned an address from the ipv4_cidr_range of the cluster it's actually in

You might be referring to some code where we assign an IPv4 address to the TUN device from one range arbitrarily. That's true and maybe it's subpar, but it doesn't affect the IPs actually assigned to apps, that's just the address assigned to the interface that will be the source address

So e.g. if you have

• root.example.com with a custom range 192.168.128.0/17
• leaf.example.com with the default range 100.64.0.0/10

you might get

• TUN interface gets assigned 100.64.0.1
• app.root.example.com will get 192.168.128.5
• app.leaf.example.com will get 100.64.0.5

If you dial app.root.example.com the source_addr will be 100.64.0.1 and the dest_addr will be 192.168.128.5.

You're right that's probably subpar if you set the custom range on the root cluster to avoid conflicts, and then the leaf cluster, where maybe you're not even using vnet, overrides the range used to pick an IP for the TUN and stuff breaks. I'd be onboard if you want to update it to try to prefer the root cluster or any non-default range

[ravicious]

I added an issue for changing the logic of how the address of the TUN device is picked. Based on what you said and how the code works at the moment, it shouldn't be a big issue, but I wanted it documented somewhere. #43343

The way the code is written at the moment means that VNet will always pick the range used by the first root cluster returned from api/profile.ListProfileNames. As the majority of users are logged in only to a single root cluster, this shouldn't be an issue most of the time.

---

And thanks for correcting me on that. Since in every other case the IPv4 range is taken from a config of a particular cluster, it should simplify the docs as well.

[nklaassen]

I don't believe this paragraph is entirely accurate. Each app should be assigned an address from the ipv4_cidr_range of the cluster it's actually in

You might be referring to some code where we assign an IPv4 address to the TUN device from one range arbitrarily. That's true and maybe it's subpar, but it doesn't affect the IPs actually assigned to apps, that's just the address assigned to the interface that will be the source address

So e.g. if you have

• root.example.com with a custom range 192.168.128.0/17
• leaf.example.com with the default range 100.64.0.0/10

you might get

• TUN interface gets assigned 100.64.0.1
• app.root.example.com will get 192.168.128.5
• app.leaf.example.com will get 100.64.0.5

If you dial app.root.example.com the source_addr will be 100.64.0.1 and the dest_addr will be 192.168.128.5.

You're right that's probably subpar if you set the custom range on the root cluster to avoid conflicts, and then the leaf cluster, where maybe you're not even using vnet, overrides the range used to pick an IP for the TUN and stuff breaks. I'd be onboard if you want to update it to try to prefer the root cluster or any non-default range

[nklaassen]

The app public_addr might not be in the application service config file, it could be a dynamic app

[ravicious]

I'll just remove the mention of it. I think it's clear that it needs to be set on a leaf cluster app and I couldn't find a succinct way to say that it needs to be set on an Application Service configuration or a dynamic resource.

[github-actions]

🤖 Vercel preview here: https://docs-iry2eq5g8-goteleport.vercel.app/docs/ver/preview

[github-actions]

🤖 Vercel preview here: https://docs-jh58pzq77-goteleport.vercel.app/docs/ver/preview

[public-teleport-github-review-bot]

@ravicious See the table below for backport results.

Branch	Result
branch/v16	Create PR