Skip to content
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

Clients receive timeouts for queries that cannot be answered by resolvers #221

Open
chaehni opened this issue Mar 25, 2019 · 1 comment
Open

Comments

@chaehni
Copy link
Member

chaehni commented Mar 25, 2019

Queries which a resolver cannot answer cause the client to time out.
An expected answer would be an error.
Timeouts should only ever happen when a client cannot reach the resolver.

Example query:
rdig --localAS 17-ffaa:1:XX @17-ffaa:0:1107,[192.33.93.195] node.snet. scionip4 -p 55553 --context .
node is a subordinate zone of snet and not a host. Querying a scionip4 for a zone is not defined and the client times out.

@FR4NK-W
Copy link
Contributor

FR4NK-W commented Mar 25, 2019

@chaehni The issue is a bit different:
The zone authority of node.snet. is not authoritative for the name node.snet., only for the *.node.snet. zone.

So the first issue is that the authoritative rains nameserver for the node.snet. zone does not detect that it is not authoritative for the name node.snet.
And the second issue you are pointing out is that queries for records a nameserver is not authoritative for time out, but this seems to be ~by design: An authoritative server only answers queries about a zone it has authority over

@fehlmach Can you confirm that it is intentional for a nameserver to timeout for queries where it is not authoritative?
Only the caching resolver should not time out.

FR4NK-W added a commit that referenced this issue Mar 26, 2019
Fix confusion about authority
Fix out of bounds

Fixes part 1 of issue #221
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants