Dnsmasq problem?

  • So I've scoured the internet looking for anyone else with this problem, and only one entry came up in a dnsmasq mailing list.  I tried following what it said to do, but it didn't seem to help.  Here's what's going on with my setup.  Every 3-20 seconds, I get the following two entries repeating themselves (IPs & company identifying marks removed):

    Apr  5 13:58:54 <pfsense ip=""> dhcpleases: Ignoring DHCP lease for emtdevlapnix01.office. <company name="">because it has an illegal domain part
    Apr  5 13:58:54 <pfsense ip=""> dnsmasq[31153]: read /etc/hosts - 79 addresses</pfsense></company></pfsense>

    Company name has no .com, .net, etc. after it, so it is not a FQDN on purpose.  The one link I could find suggested that this error comes because I set the full host/domain name on this *nix box, and dnsmasq only allows dhcp hosts to set their full dns if it matches its configuration.  It was suggested that the error would go away if I added domain=office.<company name=""></company> to the dnsmasq config file to make it authoritative for that domain.  Since this is pfsense, I added it into the services -> dns forwarder config section in Advanced.  After applying the changes, it still gives that error.  Does anyone have any suggestions?

  • Rebel Alliance Developer Netgate

    It could also be that some character in "company name" that is not valid in a hostname. Without seeing the actual text it's difficult to speculate.

    Usually in those cases I use <name>.local or .localdomain rather than ending it with the actual company name.</name>

  • LAYER 8 Global Moderator

    ^ I agree I would not suggest using a company name as the tld.

    I like <name>.lan myself - but sure .local or .localdomain are commonly used tld used when its not a public resolvable domain name.

    I find that line of text of your error in dhcp.c of dnsmasq

    if (strcmp(dot+1, suffix) != 0)
    				       "Ignoring DHCP lease for %s because it has an illegal domain part", hostname);

    it would be very helpful to know what your setting exactly.  Are you saying non nix boxes are in this same .companyname tld ?  And they work ok?  Or is the nix box in a different domain than your other boxes are using?</name>

  • OK, the full domain name I'm using is office.emediatrade.  It is the only domain in our office.  Yes, Windows boxes are working fine in this domain.  I do have other *nix boxes in this environment, but this is the only one using dhcp.  This is the only machine giving this error in the logs.

    I also want to point out that the machine itself doesn't have any visible problems connecting to the network or anything else.  This error just pops up in the log.  I would ignore it, but I'm trying to set up remote logging, and these errors are fast taking up a large chunk of the logs, hence why I'd like to resolve its problem.

  • LAYER 8 Global Moderator

    do you have the . on the end??  Or was that just the period on the end of your sentence?

    I can try and duplicate your issue, can you post your nix box config where you set his domain on the box?

  • Period at the end of my sentence.

  • LAYER 8 Global Moderator

    see my edit - can you post up your nix box config

  • This is a centos box, btw.

    /etc/hosts:       localhost.localdomain   localhost
    ::1     emtdevlapnix01.office.emediatrade       emtdevlapnix01  localhost6.localdomain6 localhost6



  • After thinking about this, something just occurred to me–do you think it could be trying to treat the whole host/domain as the hostname?  That would make the hostname too long, wouldn't it?  Would it be worth trying to remove the domain from the hostname values?

  • LAYER 8 Global Moderator

    so curious why you set your ipv6 loopback to your fqdn, but leave ipv4 at just localhost?

    I can fire up my centos vm and try and duplicate your error now.

    From my reading in centos the hostname in that file should be your fqdn.  So I don't see that is too long.

  • I didn't set it up that way.  Either CentOS did, or the guy using this machine did.  We don't use ipv6 in our network right now anyway.

Log in to reply