Pros and cons of using edge router to host a private DNS

I am working through a few different scenarios on how to configure a ziti network.

One aspect is the use of the edge router to host a private DNS.

While this can be done, it can also be done by launching a private host.

So… I thought to ask for some guidance around the different pros and cons.

For instance:

Is there a big cost to use an edge router to host a private DNS, or is it small?
Is is more secure to use a private host rather than an edge router?

One that comes to mind is that you can inject custom http headers if you use a private host.

Keen for your thoughts and feedback.

Without knowing the full architecture, it’s difficult to be able to give any terribly meaningful advice I’m afraid.

Presuming you’re using tunnelers, personally I’d leave all dns related stuff with them.

I’m not sure what type of cost you’re referring to. There are costs associated with running the server and there are costs to client latency but none of those are probably all that substantial.

Custom http headers are irrelevant to DNS so I’m not sure that fits in to this topic. :grinning:

1 Like

It sounds like you’re evaluating the practicality of self-hosting a router, configuring its tunneler binding to tproxy for the purpose of publishing the nameserver that comes with that on the attached network. In this hypothetical, I think you’re trying to use the self-hosted Ziti router as an IP router too i.e. an IP gateway, local network nameserver, and a Ziti router all in one. Is that accurate?

1 Like

Thanks for the feedback. Great insights.

The reason for the post is that I am reflecting on different approaches.

I am not that technical when it comes to networking… so its more of a blended request to understand how things fit together.

To provide some context, I started off creating a private DNS using a Golang reverse proxy… as opposed to an edge router… as I did not know how to set it up.

As I now know how easy this is…it’s challenging me on how I am approaching what I have been doing in the past.

For instance, while you can do lots of interesting things in Golang… like http headers, authorisation headers, logging, data manipulation… traffic throttling etc… much of this may not be required for a standard implementation

For general needs, maybe all you need is a API gateway or a private DNS. In such cases, using the edge router is probably best.

Also… when you use an edge router to host a private DNS… it is on the edge of the fabric. However, if you host a private DNS using a reverse proxy Golang server… it can be on a subnet on another computer…

In thinking about the cost, what I would like to know are the technical limitations… ie… how many services can you realistically allocate to an edge router without it impacting performance

When performance starts to be impacted, how do you manage the trade-off… is it just a matter of adding more CPU, memory and bandwidth… or do you just create another edge router… or do you split the services up between different edge routers?

I would find that very interesting to know

Is it safe to say the contrasting approaches that you’re reflecting upon are Ziti router tunneler vs a custom proxy and nameserver? I think you’re suggesting that either could provide the necessary Ziti infrastructure to a Ziti-naive network, sort of like a Ziti gateway. Let me know if you have any specific questions. There’s not quite enough info to speculate about costs or max services, but we could estimate if we collapse some of these variables.

1 Like

Re-reading you’re also asking how I might scale out (more nodes, horizontal) or up (bigger nodes, vertical) or both. There are some load balancing strategies built-in to Ziti. For example, endpoints that share permission to bind a particular service will also share that workload. This means you can scale out your capacity to provide a particular service by hosting it with more endpoints i.e. identities with a common role attribute that grants them permission to bind that same service.

1 Like

You can always scale up a node / component with minimal resources, but the vertical scaling dimension tends to have few steps and so it’s wise to plan for horizontal scale sooner than later.

Another example of load balancing built in to Ziti is that all endpoints will use the first edge router that responds to their call for an edge connection. This is a function of resource availability and network latency. The busiest routers will be slower to response, and so the edge client will automatically select the most available, least latent edge router.

1 Like