[Dnsmasq-discuss] Fake reverse lookups from cache

[Simon Kelley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256



On 02/02/15 15:57, Niels wrote:
> 
>> On 31 Jan 2015, at 23:21, Simon Kelley <simon at thekelleys.org.uk>
>> wrote:
>> 
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>> 
>> On 31/01/15 13:57, Joachim Zobel wrote:
>>> 
>>> --fake-reverse Fake reverse lookups by using the cache.
>>> Reverse lookups are satisfied by using the cached forward
>>> entries if possible. Note that this does not give the same
>>> result as the reverse lookup. It will give a better results in
>>> most situations, since it will return a name that has actually
>>> been before.
>>> 
>>> So I have two questions:
>>> 
>>> 1. What are the cons?
>> 
>> Good question. Here's a couple I can think of.
>> 
>> 1) If the forward entry has expired from the cache, or is
>> otherwise lost (dnsmasq restart) then you can't do this and will
>> have to get the "real" answer. That's introduced some
>> indeterminacy as a start.
> 
> There is also a chance the actual forward lookup no longer
> resolves to the same ip at the time the reverse lookup is
> requested.

It's reasonable to assume that the cached forward lookup is still
valid as long as it's within the time-to-live. If you don't assume
that, you can't do _any_ caching.
> 
>> 2) Whilst useful for you to look at the output of netstat-nat,
>> you're also affecting everything else that uses reverse lookups.
>> I'm not sure if there would be consequences to that, but can we
>> be sure there won't.
> 
> Any service trying to ensure a reverse lookup yields a domainname 
> resolving to the connecting IP is one example. All hosts that have 
> a cached forward lookup would pass, regardless of actual reverse
> PTR existence in dns.
> 
>> 
>>> 2. What are my chances to have such a patch accepted in
>>> dnsmasq trunk?
>> 
>> Another good question. I'm kind-of ambivalent about this. It
>> seems like Yet Another Config Option, it's of some, but niche,
>> use. 99% of all dnsmasq users won't use it (but that's true of
>> quite a few dnsmasq features.) I'm not sure, but I'd be
>> interested in other's opinions too.
> 
> I do see the usefulness of such an option but only if implemented
> such that real reverse lookups can still function unchanged. One
> way would be to implement a separate dns service listening on some
> other port.
> 
> That is probably way too complicated to be acceptable as a general
> patch.
> 
> I have been pondering the idea to make a log parser process that
> builds a database from forward lookups that can then be queried on
> the resulting ip. For CNAME expansion that would be problematic
> since the individual log entries currently do not provide enough
> information, like in:
> 
> Feb  2 16:36:55 dnsmasq[852]: query[A] p05-btmmdns.icloud.com from
> 192.168.178.12 Feb  2 16:36:55 dnsmasq[852]: cached
> p05-btmmdns.icloud.com is <CNAME> Feb  2 16:36:55 dnsmasq[852]:
> cached p05-btmmdns.icloud.com.akadns.net is 17.172.100.68
> 
> The logs do not make clear that p05-btmmdns.icloud.com.akadns.net
> is the value of CNAME p05-btmmdns.icloud.com and I found the extra
> dns query needed to prove that would be too much of a hassle.
> 
> So one proposition would be to make the log entries for <CNAME>
> list the actual value, which is a very small change, and leave the
> 0.01% dnsmasq users that are interested in reporting which forward
> request resulted in an actual ip being encountered alone with the
> task of writing their own report tools.

You might like to look at another change here.

http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commitdiff;h=25cf5e373eb41c088d4ee5e625209c4cf6a5659e

which makes the logs more parseable. It doesn't address the CNAME
issue, however. That shouldn't be difficult or expensive to fix.

> 
> Another way to makes things easier would be to introduce another
> logfile in an easier parseable format with just domain names and
> A/AAAA values.
> 
> Just my $.02
> 
> Regards
> 
> Niels
> 
> 


Cheers,

Simon.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJUz/IhAAoJEBXN2mrhkTWikQoP/itjBE4vNKJYwS0JLiCKnz7d
gGiyaz+ELBkbXFgxyB1YxWT10qhDv3sSe+xySF8KkT+j0Msrl25Asaa+7VYyTEPw
siW0vDyVtZHjOBvtcV0JySwE+RW3Sv5PPU5frPYPQNkkJIXvk7vJ2Pr/NxVV4tVp
qmdcE4YAxgWlTWKiP0ysNbmLauQCqt/AwRYUZp/pqQN/3W1SjvFIEyjwYGvO++G/
m6/kwgbQDuC+W9BpTmMf01cDNNML/rY7r4Zj9xMv1YulHgcNsEPV+AiIP8OERIVO
cJNdl5IXnwr189sIQEOi9Ek9jE9MUqGSTffxqEJYt1/iXZ874ea8cOej90KSRWXh
Sf3WGg/J8GSSQMP/zXIbP7Es4/uyOPXBjx0TB1rIlf7nqdTkN/L8lhWY0lXuZFnA
h2V8Fdm/nBTVWPwFMDskRubxoP1X0jwiULEmV2GRpnyPzwQU3kb1ZJJNlCJcio1d
1J49OaV2WYWuoQzrGrlSzAkarnN5AznAtiNuChF9oy5JCD+ULvwNKi/5Xj0Zr2ps
8UIBFlh3hpQk3uLghZ7N5oQBLCoZ/lIhFMYFCf4F+67yixllCTGI7aWkbeo6ylgH
CmxD3m01813zOTZgkj989oJo38HRVCmK2Rx4h5D84rvSXljBGenYbPAJ6PW4q8Ui
LpZI8PjfOthd0bsSLobU
=vBCq
-----END PGP SIGNATURE-----