Fix the forward zones in the recursor #3244
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
ToDo:
|
| @@ -954,14 +951,14 @@ int SyncRes::doResolveAt(set<DNSName> nameservers, DNSName auth, bool flawedNSSe | |||
| bool sendRDQuery=false; | |||
| boost::optional<Netmask> ednsmask; | |||
| LWResult lwr; | |||
| if(tns->empty()) { | |||
| if(tns->empty() && nameservers[*tns].first == ComboAddress() ) { | |||
There was a problem hiding this comment.
I'm not sure if this is idiomatic. We should maybe add a test for it if it is. It looks like we currently get away with it.
There was a problem hiding this comment.
I added a unit test for this.
In the pre-DNSName era, when dns-native names were passed as strings, we overloaded the NS-name for a forward or auth zone. e.g. an empty string meant 'this is an auth zone' and '+203.0.113.1' meant 'forward to 203.0.113.1 with the RD bit set'. With DNSNames, this is impossible (yay!). In this commit, the set of strings (and later DNSNames), is replaced by a map where a DNSName is the key and the value is a pair of a ComboAddress and a boolean. A non-empty DNSName: This is a normal NS, recurse as usual (the pair is ignored). An empty DNSName and empty ComboAddress: We are auth for this zone, check the auth store for an answer. An empty DNSName and non-empty ComboAddress: The query must be forwarded to the ComboAddress specified and the boolean in the pair tells us the value of the RD bit in the query we need to send.
pieterlexis
force-pushed
the
4.0-forward-zones
branch
from
629564c
to
68b1e9f
Compare
pieterlexis
force-pushed
the
4.0-forward-zones
branch
from
68b1e9f
to
c9ff7d5
Compare
ahupowerdns
added a commit
that referenced
this pull request
Jan 19, 2016
Fix the forward zones in the recursor
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In the pre-DNSName era, when dns-native names were passed as strings, we
overloaded the NS-name for a forward or auth zone. e.g. an empty string
meant 'this is an auth zone' and '+203.0.113.1' meant 'forward to 203.0.113.1
with the RD bit set'. With DNSNames, this is impossible (yay!).
In this commit, the set of strings (and later DNSNames), is replaced by
a map where a DNSName is the key and the value is a pair of a
ComboAddress and a boolean.
A non-empty DNSName: This is a normal NS, recurse as usual (the pair is
ignored).
An empty DNSName and empty ComboAddress: We are auth for this zone,
check the auth store for an answer.
An empty DNSName and non-empty ComboAddress: The query must be forwarded
to the ComboAddress specified and the boolean in the pair tells us the
value of the RD bit in the query we need to send.