# Dnsmasq returning weird addresses for DHCP clients [SOLVED]

## Raniz

After running a while, dnsmasq assigns weird addresses to the hostnames of my local computers.

```
$ ping cloud

PING cloud (75.225.19.236) 56(84) bytes of data.
```

A quick look in the logs and dnsmasq.leases reveals the following

```
May 19 22:37:23 shockwave dnsmasq[4329]: not giving name starscream to the DHCP lease of 192.168.1.89 because the name exists in /var/lib/misc/dnsmasq.leases with address 75.225.56.7

May 19 22:37:23 shockwave dnsmasq[4329]: not giving name megatron to the DHCP lease of 192.168.1.200 because the name exists in /var/lib/misc/dnsmasq.leases with address 75.225.55.76

May 19 22:37:23 shockwave dnsmasq[4329]: not giving name cloud to the DHCP lease of 192.168.1.75 because the name exists in /var/lib/misc/dnsmasq.leases with address 75.225.19.236
```

```
1274341927 00:19:c5:a0:b0:4c 192.168.1.115 * 01:00:19:c5:a0:b0:4c

1274341689 00:0c:f1:1d:70:2f 192.168.1.89 starscream *

1274337237 00:19:d2:d2:60:ab 192.168.1.200 megatron *

1274344643 00:1d:e0:3d:e8:3f 192.168.1.75 cloud *
```

Restarting dnsmasq doesn't resolve the issue, removing dnsmasq.leases and having all clients refresh the lease works, but only temporarily. Any idea what causes this?

----------

## erik258

Interesting.  75.225.19.236 is a public IP address and belongs to verizon.  Does that mean anything to you?

Is it possible that you're not isolating your internal network from an external connection to verizon?  I really don't know how this would happen even if that were the case, but I'm thinking that your clients are receiving  more than one lease offer, and that verizon's servers are configured as authoritative and your dnsmasq isn't, and so the clients take the verizon address.  Then they send out an ACK on that address and dnsmasq picks it up and says, ok, you're that address now.  DHCP is a broadcast protocol if I'm not mistaken (since it happens before ip addresses are obtained, it can't be IP level) so i think this explination makes sense.

Are you DHCPing hosts holding either address?  

You don't have a public interface bridged with a private interface do you?  Typically you'd want to use NAT instead for a set-up like this.  Or are you maybe running DHCP on the external side of your network as well as the internal side?  The results would be similar, I'd imagine, although I would think verizon would filter that.

some viruses also give out DHCP leases in order to mitm other hosts on the network, but in this case I'd imagine it would give you an internal address and specify some malicious dns servers and maybe itself as the default router.  i don't see why it would hand out a public IP, especially one as heavily firewalled as verizon's.  

You might want to consider a traffic analyzer for debugging this - maybe tcpdump or snort or something.  

I'm looking forward to hearing what's going on here.

----------

## Raniz

I think I figured it out.

I had

```
addn-hosts=/var/lib/misc/dnsmasq.leases
```

in my dnsmasq.conf, I tried commenting it out and it seems to have fixed it.

----------

## erik258

I'd still like to know why it's happening though.  Perhaps it's as simple as you having a verizon domain in your 'search' in resolv.conf, and are appending it to internal names and then looking them up as in the verizon domain, thus getting public verizon IPs for them.

from what I can tell, addn-hosts simply parses another file as dnsmasq does /etc/hosts.  This seems like a good thing, because without it I don't think your host declared names will be able to be looked up in dnsmasq unless you also add them in /etc/hosts manually.

----------

## Raniz

It does, DNS lookups of my DHCP clients work fine now without them being in any file other than dnsmasq.leases and addn-host=... commented out (and dnsmasq restarted).

I'm guessing that addn-hosts=... causes dnsmasq to parse dnsmasq.leases according to the same format as /etc/hosts which means that the first number of each row is read as the IP-address and the rest of the entries as hostnames corresponding to that address. This makes a lot of sense since the numbers in dnsmasq.leases agree on the first five positions and all the bogus IP-addresses begin with 75.225.

Additionally, if you convert 1274344643 into an IP-address it becomes 75.244.244.195 - which isn't one of the bogus addresses, but it does start with 75.

Aside from the above, I'm not in any way connected to Verizon since I'm located in Sweden, my router is configured as a NAT, dnsmasq is only listening on the internal interface and I don't have any search directive set in my resolv.conf.

----------

## erik258

 *Quote:*   

> 
> 
> Additionally, if you convert 1274344643 into an IP-address it becomes 75.244.244.195 - which isn't one of the bogus addresses, but it does start with 75.
> 
> 

 

Brilliant analysis.  Of course.  I didn't see it.  

Just out of curiosity, does that mean you are updating /etc/hosts on your dnsmasq server, or getting dynamic dns updates some other way, or not at all?

----------

