[Dnsmasq-discuss] [BUG] Bogus IP address in the syslog messages
Sergei Zhirikov
sfzhi at yahoo.com
Thu Feb 25 20:05:31 GMT 2010
On 2010-02-20 17:21, Simon Kelley wrote:
> Sergei Zhirikov wrote:
>>
>>
>> As I said, there is only one IP address. I have also used tcpdump to
>> watch both DHCP and DNS communication. The address 216.230.6.8 does
>> not show up anywhere. (As a sidenote: I found it a bit surprising
>> that despite "not giving name wafer ..." dnsmasq returns that same
>> host name in the DHCPACK message to the client)
>
> The name didn't go into the DNS, but it's still what the client is
> called or called itself in the DHCP transaction, and the name is matched
> against dhcp-host lines, so it's useful information to have.
>>
>>> Now try restarting dnsmasq and repeating the dig query. If you get
>>> the same result you must have some obscure configuration hidden
>>> away somewhere (--addn-hosts?) If the problem has cleared then we
>>> have a mystery to solve.
>>
>> Here comes the funny part. I should have mentioned that in my first
>> message. If I restart dnsmasq the bogus address remains the same most
>> of the time, *but not always*. If I run another dnsmasq binary (I
>> still have one of version 2.51, that I used before the last upgrade)
>> then the bogus address is different from the one I get with 2.52.
>> This makes me think it somehow depends on the memory layout of the
>> running process. Those mysterious addresses are not completely
>> random. All that I have seen so far have form xxx.xxx.6.8.
>>
>> Of course, I can't be sure it's memory corruption, but it certainly
>> looks very much like one.
>
> I just tried a superficially similar config here, and no problems.
>>
>> By the way, dnsmasq is running on an LFS system, which I have built
>> myself. Every single line in every single configuration file is
>> written by me, that's why I'm quite sure it isn't some obscure
>> configuration issue. Although, I did try "grep -rF '216.230.6.8'
>> /etc", just in case, and it came up with nothing, as I expected.
>>
>> I'm puzzled...
>>
> You need to get down with the debugger, I think.
>
I have managed to figure out what is going on. There is, indeed, something unusual about my configuration. One line in dnsmasq.conf that I erroneously disregarded as irrelevant turned out to be very much relevant:
cname=wafer.local.softlights.net,wafer.softlights.net
Together with another line:
domain=local.softlights.net
and a line in /etc/hosts:
172.23.112.1 wafer.softlights.net wafer
they result in host name wafer.local.softlights.net being resolved to the same IP address (172.23.112.1) in two different ways: one - directly, the other one - via alias to wafer.softlights.net. So there are, indeed, two records for that host name in the dnsmasq cache, which are looked up in the round-robin fashion. One record is of type A and another one is of type CNAME. It is that CNAME record that shows up as the bogus IP address, because the code for logging the message assumes that the record is always of type A, so it prints out the IP address member of the union, which has been initialized with the host name the CNAME record is pointing to. In other words, it is a bug in the logging code, but a minor one with no memory corruption involved.
--
Regards,
Sergei.
More information about the Dnsmasq-discuss
mailing list