In prior commits (possibly PR #11?) we changed the DNSAuth resolves customers. We had it use the zone instead of the Server IP (aka host) . We need to change the way this works to again. The problem is that, baring qname minimization, you could potentially see a query for www.foo.bar three times: once to one of the root servers (bar), once to customer 1 (foo.bar), and once to customer 2 (www.foo.bar). The query name is identical across all three queries (www.foo.bar), yet they’re going to three different customers and three different IP addresses. Only the IP addresses distinguish them.
However! There still may be an instance where two customers with two zones are behind the same IP. In this case you'd need to use both IP and zone to resolve the log entry to a customer. Presumably we'll do this through an additional column in the customers DB.
One more trick we need to do: when using the IP, it should accept it in CIDR notation as well as exact IP. Further, see if it's reasonable to have both IPv4 and IPv6 IPs in there. Feel free to recommend a schema update if needed. Because CIDR notation (as well as individual IPs) can cause overlaps of matches, we should log "WARNING" or something when there's more than one match found.
mrjones-plip
commented
5 years ago
In prior commits (possibly PR #11?) we changed the DNSAuth resolves customers. We had it use the
zoneinstead of the Server IP (akahost) . We need to change the way this works to again. The problem is that, baring qname minimization, you could potentially see a query for www.foo.bar three times: once to one of the root servers (bar), once to customer 1 (foo.bar), and once to customer 2 (www.foo.bar). The query name is identical across all three queries (www.foo.bar), yet they’re going to three different customers and three different IP addresses. Only the IP addresses distinguish them.However! There still may be an instance where two customers with two zones are behind the same IP. In this case you'd need to use both IP and zone to resolve the log entry to a customer. Presumably we'll do this through an additional column in the customers DB.
One more trick we need to do: when using the IP, it should accept it in CIDR notation as well as exact IP. Further, see if it's reasonable to have both IPv4 and IPv6 IPs in there. Feel free to recommend a schema update if needed. Because CIDR notation (as well as individual IPs) can cause overlaps of matches, we should log "WARNING" or something when there's more than one match found.