Feature request: DNS TXT resource records

[sodre]

@sean-

As discussed, It would be useful for Consul to serve TXT records at multiple levels in the domain hierarchy. One use-case in mind is a Kerberized cluster configured purely through DNS. This requires that the DNS server respond to TXT _kerberos[.data center]<.domain> with the configured realm name.

One thought is to store this information is in the key-value store, perhaps in a format such as...
key: /service/dns/req=TXT/<FQDN> value: TXTDATA.

[slackpad]

There might be a nice path for this now that we have node metadata, and we plan on service metadata as well.

[sodre]

That would be awesome. Can you point me to an example of how to use the metadata? I can try to come up with the first version of this feature.

[slackpad]

Node metadata is configured in https://www.consul.io/docs/agent/options.html#node_meta, and is exposed in all the catalog and health APIs.

[slackpad]

Closed via #3343.

[sodre]

This is not fully addressed yet. For example, there is no way to assign TXT records to the base domain yet.

[neurostream]

In case anyone else also arrives here wondering about how the DNS API for a TXT record might translate to the HTTP API, here were a couple related thoughts I've discussed with other colleagues/Consul fans:

The basic feature model of Consul that circles around one's head is, especially from the HTTP API perspective, primarily:

- Nodes
- Services
- KV

From the DNS API perspective, it might seem to follow such that:

- Nodes    = DNS Resource Record Type: "A" 
- Services = DNS Resource Record Type: "SRV"
- KV       = DNS Resource Record Type: "TXT"

First consider the way "Nodes" are mapped under .node.consul, and the way "Services" are mapped under .service.consul. And then consider that a "Value" of a Consul K:V pair would fit naturally into a TXT record - but mapping the kv/path/for/the/Key to a ( for example ) .kv.consul domain name doesn't quite hold up.

key.the.for.path.kv.consul or path-for-the-key.kv.consul would seem to be a bit presumptuous - either for subdomain levels that are too deep or to presume it OK re-format the kv/path/for/the/Key with some other DNS domain -friendly delimiter in order to key in from a single domain name level below .kv.consul. base64 encoding the URL KV path/for/the/key into a single DNS domain name level might end up with an '=' sign or other non-DNS friendly DNS record names.

As mentioned, Node meta data comes through in a DNS TXT record lookup, i.e.:

dig pvclaims.kubeworker2.node.consul. txt

kubeworker2.node.consul.    0   IN  TXT "provisioner=kubernetes.io/iscsi-targetd"

It would be snazzy if ServiceMeta could be mapped into the DNS TXT record lookup the same way that NodeMeta, but for the :

dig iscsi.targetd.service.consul. txt

But service meta data seems to only be retrievable through the HTTP interface.

[rtbellows]

Any chance of getting servicemeta returned as TXT records through consul dns? This would be very useful for DNS-01 letsencrypt challenges, for example.

[sodre]

I am willing to implement if you post my me to where the metadata for services is stored. This should be no different from what I did with nodes.

…

On Apr 20, 2018, at 4:47 PM, rtbellows ***@***.***> wrote: Any chance of getting servicemeta returned as TXT records through consul dns? This would be very useful for DNS-01 letsencrypt challenges, for example. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[hanshasselberg]

I am closing this issue since the corresponding PR was also closed. We don't have time to add this feature, but I would be happy to review a PR and provide feedback. Thanks all!