Hi, On 5/6/19 8:55 PM, [email protected] wrote: > Hi Conrad, > > Thanks for the report. It should be fixed in master > https://gitlab.labs.nic.cz/knot/knot-dns/commit/3285184c866b049744ef853d87d3b041d4539f9c
Verified! Sorry for the delay and thanks for the fix! Conrad > > If you could verify the fix, that would be great. > > Best, > Daniel > > On 2019-04-30 11:23, Conrad Hoffmann wrote: >> Hi there, >> >> while trying to understand the algorithm employed in the >> `find_best_view` function in the geoip module, I started wondering >> whether this line is in there intentionally: >> >> https://gitlab.labs.nic.cz/knot/knot-dns/blob/4015475b0d3e11c0bd6fcac8aceb63cac0451491/src/knot/modules/geoip/geoip.c#L677 >> >> >> I am still trying to understand how this works with the actual geo data, >> but here is a test case using the subnet mode that yields slightly >> surprising results: >> >> Using a geoip config like this for zone example.com: >> >> bar.example.com: >> - net: 127.0.0.0/8 >> A: 9.9.9.9 >> - net: 192.0.0.0/8 >> A: 1.1.1.1 >> - net: 192.168.0.0/16 >> A: 4.4.4.4 >> - net: 192.168.1.0/24 >> A: 8.8.8.8 >> >> If I query bar.example.com from 192.168.1.X, I get 4.4.4.4, which is >> suprising because it is neither the most nor the least specific item. >> The binary search returns the most specific one (8.8.8.8), which is sort >> of what I would expect. However, above line immediately takes the `prev` >> item without checking for `view_strictly_in_view`. Without the above >> line, the whole function returns the most specific item, as I would >> expect. >> >> Please note that this is mostly an intuition atm, as I have not yet had >> the time to set up a similar test case for real geo data (which uses the >> same algorithm). But I figured that someone more familiar with the code >> might have enough context to tell whether this is correct or not or what >> a suitable fix might look like. >> >> Thanks a bunch, >> Conrad > -- https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users
