A curious question. I am frustrated by the issue of reverse DNS resolution. It seems to me that the Omnia acts as a gateway and DNS for all my LAN users. Thatis all their DNS requests go through kresd, which resolves my .lan names well and refers onward to my ISP DNS for a resolution if not and then I presume answers the client on my LAN.
To wit, Knot has (or can keep) a record of domain names and the IP addresses they resolved to.
I would presume this to be the cache. I can see the cache is modestly accessible through its tty interface:
but it doesn’t seem to provide anything like what I’d like, a lookup on IP to return a possible list of names that were requested for resolution and which resolved to that IP. Which would essentially be a locally cached reverse DNS.
I wonder is what I’m after possible with the kresd cache at present?
Reverse resolution, i.e. IP address -> name? In DNS that is standardized in ways that don’t “need cache”. For example,
$ dig +short -x 217.31.205.50
www.nic.cz.
Of course, there’s no guarantee that forward and reverse resolution correspond to each other in any way – it’s just like two “independent” mappings.
If you meant this for local addresses, typically 192.168.x.y, there is a catch with current knot-resolver that reverse queries to local address ranges get blocked by default.
But of course there are the very limitations you noted. For example:
dig +short -x 203.219.107.146
just one IP from my Majordomo log, Majordomo logs (which BTW totally fail to do reverse DNS lookups regardles sof the setting asking it to do so - a known issue:
and I have no resolution for it, no way of diagnosing or fixing it to date, just frustating failure to work). But even if it did work, if it uses standard methods like above, it is woefully short of what it could reveal. Let’s say someone connected to a site there and it’s served by someone on an ISP and all reverse DNS gives me is the ISP pool … yeah! When kresd knows full well what domain name it was asked to resolve earlier that resolved to that IP - probably, not always, because some users may be connecting to raw IP addresses of course, though this would be marginally few as I know my family well enough and none are working at that level nor using P2P services like bittorrent or soulseek that might do a lot of direct IP connections - the vast majority is web services they access via named domains).
For which reason I am in fact curious if the local DNS cannot help us out here, keeping a local cache of request and IPs they resolved to. I could write a quick script that looks up IPs there, and returns a domain name, and falls back on dig if it’s not found.
And that is where my curiosity takes me and drives this question.
For local addresses I’m less concerned or interested. My main driver is more rigorous and informative reverse DNS, given the information needed in fact passes right through the same router and is technically very available.
I see what you mean. Well, there are even companies whose business is to collect DNS data, as much as possible over time, and use that to mine some information, etc.
As it is now in knot-resolver’s cache, the name-address mappings are only searchable in one way, unless you want to walk through all the cache – it’s just designed for a different purpose. At least some of such functionality shouldn’t be hard to add via plugins, but for tracking IP connections, I’d personally use other ways designed for that – especially as most of the traffic is http(s) and the hostname is easily readable in these protocol’s traffic, so you can mine more information related to connections to those hostnames. From what’s currently available on Omnia, I’d suggest you look into pakon.
Thanks, pakon looks to be targetting exactly what I have in mind, though it seems a little young (no web interface) it seems to be aiming to eclipse majordomo (as evidenced by the FAQ What is the difference between “Majordomo and PaKon?”.
I will take a look at pakon and play with it and maybe its source if I can find it ;-). Personally I’d love to see tool (and maybe just maybe, though not likely, build it myself if I have to), that does a reverseDNS as I described above (checks the history of DNS requests - name/IP pairs that knot or dnsmasq resolved first (to get the most relevant users perspective on things) and then dig as a fallback.
Alas have now tried pakon and am mildly disappointed, but may as I said see if I can find the source code and maybe I can fix it. The biggest disappointment is, that while it seems focussed on doing the IP to domain name mapping using knowledge about DNS requests that passed through the router (and hence as discussed above, is much more complete and robust than a standard reverse DNS lookup) it makes no effort it seems to identify the source machine whichit lists my MAC address only.
I mean I wrote a script to convert MACs to names already:
Part of me wishes Turris would stick to github or gitlab and/or keep the READMEs clean enough to immediately identify the role of each. But it looks like gitlab hosts the pakon source code and github the package management for it. Shining light onto my naive researches is always welcome.
As time permits I’ll try and work out how it works, it seems not too complex and python based which lends me confidence.
Pakon is pretty new and doesn’t have github mirror yet. But all our repositories are on gitab.labs.nic.cz so you don’t have to search for anything else. If you are looking for source codes then you should search our gitlab.
Thanks for clarifying the roles. I would recommend to Turris then kindly to add to all the README.md files that appear on github a summary of that, that this is a mirror of X at gitlab … Clarity then found where and when its needed by people who discover the repos.
but it would be nice to mention the location of its primary repository in there.