wildcard DNS service records

[Ronny M]

Is it possible to create wildcard DNS records for services in consul.
 
 *.apps.service.example.com (for example) should point to a service.

the following query' should then resolv the same ip for different queries.

app1.apps.service.example.com (ip: 10.0.0.1)
app2.apps.service.example.com (ip: 10.0.0.1)
app3.apps.service.example.com (ip: 10.0.0.1)
 

[pba...@hashicorp.com]

Intersting idea.

I'm trying to understand your use-case - these DNS names don't match Consul DNS format so I assume you mean create these records in an external resolver? Id so then the answer seems to be very specific to your external DNS resolver and how it can be configured - can you provide more details?

If you don't then Consul doesn't let you just specify arbitrary DNS records no. It simply has a DNS interface onto it's existing data.

Hope that helps!

[Ronny M]

Use case is.

We now use Consul as DNS for node (DNS) records en service records for service discovery.

For access to services in a kubernetes cluster we have a haproxy which forwards requests to the ingress controllers in a kubernetes cluster.

With traditional DNS servers I would use wildcard DNS records to forward requests though a haproxy to the ingress controllers in a kubernetes cluster.

wildcard DNS  *.apps.service.example.com" is then pointing to the haproxy.

requests for :

app1.apps.service.example.com
app2.apps.service.example.com

will go to the haproxy and haproxy will forward them to ingress backends in the cluster which nows how to get to:
  app1.apps.service.example.com
  app2.apps.service.example.com

In the cluster.

I don't want to have an additional DNS servers only for the wildcard DNS records.

I was hoping that it would be possible to create (for example) a service. "app" with tag "*" for the haproxy server (service).

consul service record would then be the same as a traditional wildcard DNS record "*.apps.service.example.com" and would be pointing to the haproxy server.
 
So the following request would go to haproxy and then to the ingresses in cluster.

app1.apps.service.example.com
app2.apps.service.example.com
en lots more only the ingress in cluster knows about.

 

 

[Paul Banks]

Got it thanks for the details.

> I was hoping that it would be possible to create (for example) a service. "app" with tag "*" for the haproxy server (service).

Does that not work? IIRC we actually allow service names and tags that are not valid DNS names so I don't think anything would stop you registering that as a service currently. That said, we intend to be stricter about that in the future so I can't don't recommend it in general - if it does work for you now though it could be a case we explicitly consider allowing when stricter rules come.

It might not because I know we do check for valid DNS names within the DNS server - I've not tried and don't off top of my head recall if `*` would cause that error.

> For access to services in a kubernetes cluster we have a haproxy which forwards requests to the ingress controllers in a kubernetes cluster.

I'm interested to know what Consul brings to this use case? We think it's great but why can't you just use k8s own service discovery tooling for this? You already have their ingress controller AND (sidecar?) haproxy both of which presumably have service-discovery and health checks and load-balancing options without Consul.

Apologies for asking about things you likely already considered - I'm just trying to understand the full constraints of the problem.

Does the ingress controller use Consul to find the backends for the services (I guess no as k8s knows this anyway). If not then why can't you just register each service with the IP and port of the ingress controller directly and so all requests just go there?

In general though, the answer is that no Consul doesn't allow defining arbitrary DNS entries and likely won't in the near future because it seems it would just grow until it's a fully fledged DNS server which is bloat for the vast majority of users. 

Consul is a discovery/health-checking tool with a DNS interface but it's not designed to replace all other DNS infrastructure in your DC. We often recommend running something simple and lightweight like DNSMasq on each node configured with consul agent as the authoritative source for the `.consul` domain which gives you full DNS flexibility (and can improve performance if short TTLs are acceptable).

Or in k8s there are several other DNS alternatives that integrate with k8s service discovery already.

Does that help?

If you think there is a really compelling reason for this to be a special-case additional feature for Consul then I don't mean to shut down the conversation - let us know why :)

Would any others on the list find this valuable?

Thanks

Paul

--
This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.
 
GitHub Issues: https://github.com/hashicorp/consul/issues
Community chat: https://gitter.im/hashicorp-consul/Lobby
---
You received this message because you are subscribed to a topic in the Google Groups "Consul" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/consul-tool/Itw0lsXJ5Pw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to consul-tool+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/consul-tool/5d271e56-d821-4f3b-b75c-90bdef52ea27%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[rm...@quattro.ps]

> Does that not work? IIRC we actually allow service names and tags that are not valid DNS names so I don't think anything would stop you registering that as a service currently. That said, we intend to be stricter about that in the future so I can't don't recommend it in general - if it does work for you now though it could be a case we explicitly consider allowing when stricter rules come.

*.apps.service.example.com resolves but thats not what wildcard DNS is supposed to do.

any name existing or not, before .apps.service.example.com should resolve to the same ip.
In my case that should be the loadbalancer.

nslookup app1.apps.service.example.com (resolved ip: 10.0.0.1)     
nslookup app2.apps.service.example.com (resolved ip: 10.0.0.1)
nslookup any.apps.service.example.com   (resolved ip: 10.0.0.1)

I'm interested to know what Consul brings to this use case? We think it's great but why can't you just use k8s own service discovery tooling for this? You already have their ingress controller AND (sidecar?) haproxy both of which presumably have service-discovery and health checks and load-balancing options without Consul.

We use it for all our services/hosts that are not running in the cluster. For example HAproxy that is outside of the cluster but is used to access services/apps in the cluster.

Does the ingress controller use Consul to find the backends for the services (I guess no as k8s knows this anyway). If not then why can't you just register each service with the IP and port of the ingress controller directly and so all requests just go there?

No, consul is only used for services/hosts not running in the cluster.

If you think there is a really compelling reason for this to be a special-case additional feature for Consul then I don't mean to shut down the conversation - let us know why :)

Consul suits most of our needs. I'm only missing wildcard dns.
 If the "*" as tag for a service could be a special use case to indicate wildcard dns then everything would be perfect :)

[rm...@quattro.ps]

With wildcard dns:

If I deploy a new app in the cluster with name app1 and use app1.apps.service.example.com as url in a browser.

Then app1.apps.service.example.com will be resolved as the loadbalancer.
 
The loadbalancer will forward the request to the ingress controller in my cluster.

And the ingress controller will forward the request to app1 ( app1.apps.service.example.com) in cluster.

So with wildcard dns I don't need to know what is running in my cluster. (as apps can be created/destroyed dynamically). Everything for .apps.service.example.com is forwarded by the loadbalancer to the ingress and the ingress know how to find it.

One (wildcard) dns entry for many, many different apps in my cluster.    

[Paul Banks]

Thanks for the details.

> *.apps.service.example.com resolves but thats not what wildcard DNS is supposed to do.

Ah yeah, I was thinking Consul would serve the IP on that and then downstream DNS resolver would take care of wildcard matches but that probably doesn't quite work and you said you have no downstream anyway. Apologies.

I can see how it would be helpful for you. All new features are a tradeoff between general utility vs bloat and I'm not sure that this is a case many other users would need.

I know it's more moving parts but my experience has been that running DNSMasq or similar locally is pretty low maintenance and is something many setups do anyway which I suppose is why things like this haven't affected many others.

If you really don't want to manage more things whatever provider you run on likely has a DNS service that could work with very little setup. It's reasons like that that make us a bit reluctant to try building "advanced" DNS server features into Consul - almost everyone already has a DNS infra that's better suited.

Hope this helps.

--

This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.
 
GitHub Issues: https://github.com/hashicorp/consul/issues
Community chat: https://gitter.im/hashicorp-consul/Lobby
---
You received this message because you are subscribed to a topic in the Google Groups "Consul" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/consul-tool/Itw0lsXJ5Pw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to consul-tool+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/consul-tool/498120d5-a16b-442a-a8e1-867fb86f98f3%40googlegroups.com.

[Ronny M]

For now I have put dnsmasq in front of my consul servers. They now handle wildcard dns.

It's not what I really want but works for now.

Normally I would have new instances automatically create service records when the are provisioned.

I now create those for wilcard dns on the consul server instead on the instances that use the wildcard dns for their service. It's know less dynamic/automated.
 
 

[Paul Banks]

Hi Ronny,

Another option I completely overlooked earlier that might work better is that Consul agent can be configured with an upstream DNS recursor for non .consul queries.

See https://www.consul.io/docs/agent/options.html#recursors

So in your case you could run a single (logical) DNS service in your infrastructure that hosts wildcard queries (or possibly use a cloud service).

That way you can get away with no additional DNS process on each host and just query Consul from apps directly but still serve custom DNS records, provided you don't need them to have the same .consul domain.

Hope that helps.

Paul

--
This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.
 
GitHub Issues: https://github.com/hashicorp/consul/issues
Community chat: https://gitter.im/hashicorp-consul/Lobby
---
You received this message because you are subscribed to a topic in the Google Groups "Consul" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/consul-tool/Itw0lsXJ5Pw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to consul-tool+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/consul-tool/9dd32af5-68b5-40cd-b787-f076f082b187%40googlegroups.com.

[Ronny M]

Paul,

We already configured our consul clusters with recursors (for example google: 8.8.8.8/8.8.4.4) for domains not served by consul.

But because we automate everything and want to keep everything dynamic and 'near' real-time we try not to use external recursors (except google) to stay in control of what is configured/served.

Our whole infrastructure is dynamic and services/roles can be created/removed on demand.

For this to work best, a service/role that is created or destroyed creates/removes everything needed to function, on it's own host or other hosts if needed.

This is also why we use consul, the consul agents get there configs during host creation and in some special cases consul config or other host/role configs can be changed with consul templates on demand.