Investigate potentially missing NS record

[armon]

Consul may be omitting an NS record since it is the authority for the consul TLD. See this thread for context: https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/consul-tool/dokhUSVf0h4/fBaDY6ADCwAJ

[jarischaefer]

Are there any updates on this issue?

[westsouthnight]

@slackpad may be we do a full dns support to consul?

[lgfausak]

I've been wrestling with this issue. The consul dns server is not reporting a NS record for the consul domain, which makes it impossible to hook in to named properly. When I set up the glue records to delegate from my named server to consul, the delegation fails because although consul reports an SOA, it does not respond with NS and A records for the name server(s). So I can't delegate a subdomain to the consul dns. It may also be necessary to add an A record for the NS record, I don't know, I haven't been able to get that far. I am currently looking at replacing my bind infrastructure with unbound as a work around.

[slackpad]

Follow on discussion linking here from https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/consul-tool/QalkNLftvO8/DoBD032ZAAAJ.

[preetapan]

@lgfausak - I work on the consul team at Hashicorp, and we have a fix for this issue in https://github.com/hashicorp/consul/tree/issue_1301 that we would like to release with 0.9.1. I would appreciate your help in testing this to make sure it works with your DNS setup.

Our implementation adds NS records and A records for those NS records with consul server IP addresses. However nodes may change their IP addresses, and servers may move around within a consul cluster. So, we didn't want to have static names like "ns1.consul" in the authoritative section. Instead we make up a name that includes the IP address so that it meets nameserver requirements, particularly the requirement that hosts must not resolve to the same IP address. This should all work, but testing that in the environment that you describe in this thread would help verify.

[lgfausak]

Hi, thank you for reaching out to me about this issue. Since I reported this problem I had to use a work around, which was using a consul template to rewrite the dns configuration (for unbound) every time it changes and then restart unbound. I would much rather delegate dns to consul and not have to deal with the configs/restarts etc. I can set up a test environment. Is there a consul executable I can download with this patch, or do I need to build it?

[preetapan]

Thanks for the fast reply. I don't have a release candidate for this yet. Can you build the issue_1301 branch from source? If you are on a *nix platform, running make linux should give you an executable that you can run in your test environment.

[lgfausak]

I made a couple attempts to build it. I was not successful. What version of golang? I attempted with 1.6 and got these cannot find context errors.

[preetapan]

@lgfausak we do require Go 1.8 - https://github.com/hashicorp/consul/blob/master/README.md#developing-consul

[preetapan]

Also @lgfausak we are still working through the approach in a PR #3353, I will let you know when its ready to test again EDIT - you can try this branch now.

[magiconair]

@lgfausak I've tested the static-stub setup with consul 0.9.0 and with that you can query for services but not for the NS records since we don't respond to those in that version. See #3353 (comment) for the tests I ran. The patch in #3353 should fix the responses to SOA and NS queries. Please let us know whether this is working for your use case.

[magiconair]

#3353 and the fix in #3407 should fix this. Closing.