-
Notifications
You must be signed in to change notification settings - Fork 72
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TSIG Authentication not used during queries #29
Comments
Hi @jnahelou! Agreed that this doesn't seem quite right. I assume it works for many users because they have the nameserver configured to only require authentication for writes, but it is possible and valid to also require authentication for reads, if e.g. you handle updates on a separate server that doesn't respond to end-user queries and then synchronize the updates into a public-facing server. The Terraform team at HashiCorp won't be able to work on this in the near future due to our focus being elsewhere, but we'd be happy to review a pull request if you or someone else has the time and motivation to implement it. |
What do you think about adding a property
and use it like :
Where queries can be :
I'm waiting for PR #28 to start new PR :) |
I would say the new attribute doesn't belong in the I'm struggling a bit with why you'd want to require TSIG on queries apart from because you can. I do something similar whereby I send updates to a non-public DNS server which is slaved by public DNS servers so I require TSIG for the updates but if someone wants to query the internal server then I don't really care as the data is publicly accessible anyway. |
I use infoblox DNS cluster composed by one gridmaster cluster and resolvers. GM is the only one to allow update. To ensure performance, we denied queries on GM (that's resolvers's job). |
I would not expect any of the data sources in this provider to use authentication, and indeed they cannot as currently implemented because they are using the Go resolver directly. Given that, it seems reasonable for the It's been a long time since I had a DNS server that supported updates so I'd love to hear your thoughts on what seems like reasonable behavior here. If possible I'd rather just do "the right thing" by default rather than adding another option, since each additional option adds both user-facing complexity and testing/maintenence complexity. |
I think if you send a TSIG-signed query to a server that doesn't require it, it just gets ignored so signing all reads might work, at the expense of sending larger DNS packets. Handling EDNS0 and/or TCP for queries would become necessary. I had a think about it, and an alternative could be to extend the provider configuration with an optional |
I like the idea of an optional
Then it's easy to update existing code like :
I tested it locally on my own cluster (with ACL on read & write). |
Thanks for prototyping that, @jnahelou! The separate My other worry about the separate My preference (and again, I'm happy to change this if we can convince ourselves that there are common situations that would not be supported by this) is to have the credentials given in the |
Rather than copy and paste the same code, refactor DNS query code out into separate function and while there, handle UDP message truncation by first retrying with EDNS0 and then TCP.
Rather than copy and paste the same code, refactor DNS query code out into separate function and while there, handle UDP message truncation by first retrying with EDNS0 and then TCP.
Rather than copy and paste the same code, refactor DNS query code out into separate function and while there, handle UDP message truncation by first retrying with EDNS0 and then TCP.
Rather than copy and paste the same code, refactor DNS query code out into separate function and while there, handle UDP message truncation by first retrying with EDNS0 and then TCP.
Rather than copy and paste the same code, refactor DNS query code out into separate function and while there, handle UDP message truncation by first retrying with EDNS0 and then TCP.
Just came across this and I can say for certain at least the knot DNS does not act this way. If it isn't expecting a TSIG record it responds with a REFUSED. I think a flag should be implemented. |
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. |
Hi there,
When using ACLs on resolvers for update and queries, Terraform doesn't provide tsig config during queries.
Terraform Version
Terraform v0.11.3
Affected Resource(s)
Terraform Configuration Files
Debug Output
Expected Behavior
DNS Queries should use tsig name/secret
Actual Behavior
Anonymous queries are sent
The text was updated successfully, but these errors were encountered: