[Dnsmasq-discuss] Fake reverse lookups from cache

Niels niels at netbox.org
Mon Feb 2 15:57:33 GMT 2015


> 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.

> 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.

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  




More information about the Dnsmasq-discuss mailing list