Consul DNS - dig not returning all SRV records

[BC]

I have nomad(v.0.3.2) deploying 5 tomcat containers than span across 2 client nomad nodes. The services get started and registered properly in consul(0.6.4) but for reasons I don't understand, a DNS SRV query only shows 3 of the 5 SRV records in the 'answer' section.  Although the round-robin load-balancing seems shuffle through the services as expected, it seems no matter how many services get started/registered, only 3 show up in the answer section of a 'dig' command. The 'additional' section shows 5 A records corresponding to to the 5 services.

Has anyone else seen this behavior? Perhaps this is expected??

$ dig @10.190.212.4 -p 8600 tomcat.service.consul SRV

; <<>> DiG 9.10.2-P4 <<>> @10.190.212.4 -p 8600 tomcat.service.consul SRV
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30190
;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 5
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;tomcat.service.consul.         IN      SRV

;; ANSWER SECTION:
tomcat.service.consul.  0       IN      SRV     1 1 23331 nomad4.node.rackspace-dfw.consul.
tomcat.service.consul.  0       IN      SRV     1 1 33373 nomad4.node.rackspace-dfw.consul.
tomcat.service.consul.  0       IN      SRV     1 1 59651 nomad4.node.rackspace-dfw.consul.

;; ADDITIONAL SECTION:
nomad4.node.rackspace-dfw.consul. 0 IN  A       10.190.212.9
nomad4.node.rackspace-dfw.consul. 0 IN  A       10.190.212.9
nomad4.node.rackspace-dfw.consul. 0 IN  A       10.190.212.9
nomad5.node.rackspace-dfw.consul. 0 IN  A       10.190.212.7
nomad5.node.rackspace-dfw.consul. 0 IN  A       10.190.212.7

;; Query time: 38 msec
;; SERVER: 10.190.212.4#8600(10.190.212.4)
;; WHEN: Fri Apr 29 14:25:33 Mountain Daylight Time 2016
;; MSG SIZE  rcvd: 498

[Michael Fischer]

Set "enable_truncate" to `true` in your Consul config.  See https://www.consul.io/docs/agent/options.html

--
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
IRC: #consul on Freenode
---
You received this message because you are subscribed to the Google Groups "Consul" group.
To unsubscribe from this group and stop receiving emails from it, send an email to consul-tool...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/consul-tool/cdc74678-1769-46f6-92ed-165e4850abbd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[James Phillips]

Hi,

Michael's suggestion for the truncate config will work around this. The mismatch between the answer/additional section is a bug introduced in 0.6.4 - https://github.com/hashicorp/consul/issues/1931. We will get that fixed in the next Consul release.

-- James

To view this discussion on the web visit https://groups.google.com/d/msgid/consul-tool/CABHxtY4gSO%2B9M37AJF805B8Zb3JcQOMaykGmGNws-X2960TUcw%40mail.gmail.com.

[Darron Froese]

James,

When you say "next Consul release" - is there a 0.6.5 on the way? Or do you mean the next major 0.7 release?

Just curious - I know there's been a recent Go security release that may not affect Consul - but we've been waiting on deploying 0.6.4 for a bit and I am wondering if I should continue to wait.

Thanks!

To view this discussion on the web visit https://groups.google.com/d/msgid/consul-tool/CAGoWc06b_Ben8HPZp5cmTQkPoZwRhtmW1rE%2BJ1FeBHGcZK-Yzw%40mail.gmail.com.

[James Phillips]

Hi Darron,

We are currently working towards a 0.7 release and not planning on a 0.6.5 unless something else comes up. I don't have a firm time frame right now, but will update the list once we have an RC cut (~4 weeks is the goal, but there are several things outstanding right now).

-- James

To view this discussion on the web visit https://groups.google.com/d/msgid/consul-tool/CAEsqDyd%2B7XTrTbJ-ecTePRvJm1ni0Q7Htv3pZXxyUVCZhNg5Bw%40mail.gmail.com.

[BC]

James/Michael,

Thank you for the sanity check.  Setting "enable_truncate" to `true` did resolve the DNS query issue, but I am happy to hear this a known bug that is on someone's radar.

Regards,
Brett

[Darron Froese]

We are actually working around this bug and weren't completely aware or affected by it.

If you load all your Consul DNS records into dnsmasq and serve them from there, then you get the complete list like you should.

Will be watching this one for resolution as well.

Thanks for the clarification James!

To view this discussion on the web visit https://groups.google.com/d/msgid/consul-tool/4ad0e00e-a3e4-4f87-a5e4-c086bce0a8ce%40googlegroups.com.

[Igor Cicimov]

Just for the record, I have the same issue on 0.5.2 and 0.6.3 so the statement that the bug has been introduced in 0.6.4 is somewhat incorrect.

[Igor Cicimov]

James,

When I add that option to consul the agent wouldn't even start:

# consul agent -config-dir /etc/consul.d/client/
==> Error decoding '/etc/consul.d/client/config.json': Config has invalid keys: enable_truncate

Any limitations to this option or specific version this key has been introduced into?

Thanks,
Igor

[Igor Cicimov]

My bad, sorry should have read the whole page not just the enable_truncate section of the config page.

{
...
    "dns_config": {
      "enable_truncate": true