Short hostnames not working on 2.3.3



  • i checked, below the contents of /etc/hosts in pfsense 2.3.2 (i removed about 10 lines from it).
    these are all fqdn's, is that not correct then?

    10.0.0.2 is one that has a static dhcp mapping that is not working under pfsense 2.3.3

    127.0.0.1 localhost localhost.internal.abc.nl
    ::1 localhost localhost.internal.abc.nl
    10.0.0.1 pfSense.internal.abc.nl pfSense
    10.0.0.57 sas93ts1m0.abc.nl sas93ts1m0
    10.0.0.20 sasva.abc.nl sasva
    10.0.0.2 goedegooier.internal.abc.nl goedegooier
    10.0.0.13 openvpn.internal.abc.nl openvpn
    10.0.0.20 sasva.internal.abc.nl sasva
    10.0.0.21 wiki.internal.abc.nl wiki
    10.0.0.22 sas94lax.internal.abc.nl sas94lax
    10.0.0.54 r310.internal.abc.nl r310
    10.0.0.56 win2k8.internal.abc.nl win2k8
    10.0.0.57 sas93ts1m0.internal.abc.nl sas93ts1m0
    10.0.0.59 kemphaan.internal.abc.nl kemphaan
    10.0.0.80 win2k12r2.internal.abc.nl win2k12r2

    dhcpleases automatically entered

    10.0.0.191 NASBD1BB6.internal.abc.nl NASBD1BB6 # dynamic entry from dhcpd.leases
    10.0.0.101 idrac-DVBD002.internal.abc.nl idrac-DVBD002 # dynamic entry from dhcpd.leases
    10.0.0.245 fritz.repeater.internal.abc.nl fritz.repeater # dynamic entry from dhcpd.leases
    10.0.0.139 WNDAP350.internal.abc.nl WNDAP350 # dynamic entry from dhcpd.leases

    dhcpleases automatically entered

    10.0.0.245 fritz.repeater.internal.abc.nl fritz.repeater # dynamic entry from dhcpd.leases
    10.0.0.101 idrac-DVBD002.internal.abc.nl idrac-DVBD002 # dynamic entry from dhcpd.leases
    10.0.0.139 WNDAP350.internal.abc.nl WNDAP350 # dynamic entry from dhcpd.leases
    10.0.0.218 bbg-foon.internal.abc.nl bbg-foon # dynamic entry from dhcpd.leases



  • Short names work for me on 2.3.3.



  • What is not working and how are you testing it? On pfSense or on a client system?


  • LAYER 8 Global Moderator

    if your trying to query just hostname.

    You need to query hostname.domain.tld

    If your client auto adds the search suffixes - then yeah you can just put in host name.  But if your client does not add suffixes then no its not going to respond anymore..



  • @kpa:

    What is not working and how are you testing it? On pfSense or on a client system?

    I have the same problem.  I just upgraded to 2.3.3-RELEASE-p1, and now single name lookups from my Ubuntu 16.04 machine return NXDOMAIN / unknown host.  My Ubuntu machine is using DHCP for network settings, and appears to be getting the correct default domain/search domain.  pfsense is configured to use the unbound DNS resolver.

    
    login@mycomputer:~/mounts$ host pfsense
    Host pfsense not found: 3(NXDOMAIN)
    
    login@mycomputer:~/mounts$ host pfsense.mydomain.net
    pfsense.mydomain.net has address 10.xx.xx.xx
    
    

    Looks like the behavior changed:
    https://doc.pfsense.org/index.php/2.3.3_New_Features_and_Changes#DNS_.2F_Resolver_.2F_Forwarder
    Changed behavior of DNS Resolver overrides to only add FQDN entries, not short hostnames
    https://redmine.pfsense.org/issues/6064

    Ubuntu apparently is not appending the domain name or search domain to single name DNS queries.

    So the question is, which behavior is correct?  The new pfsense behavior, or Ubuntu's behavior?



  • @WayneSherman:

    Ubuntu apparently is not appending the domain name or search domain to single name DNS queries.
    So the question is, which behavior is correct?  The new pfsense behavior, or Ubuntu's behavior?

    After doing some more research, I have concluded that my Ubuntu machine was not behaving correctly and the new pfsense behavior simply allowed the problem to surface.  Ubuntu should normally append a search domain (obtained via DHCP) to a single word DNS lookup.  It accomplishes this with a "search" entry in the /etc/resolv.conf file (e.g. search mydomain.net) .  In my case the /etc/resolv.conf was incorrectly configured.  It should be a symlink to /run/resolvconf/resolv.conf which already had the correct search config.  After running "sudo dpkg-reconfigure resolvconf", and selecting "yes" to correct the symlink, everything works again.



  • So the question is, which behavior is correct?  The new pfsense behavior, or Ubuntu's behavior?

    I'm running openSUSE 42.2 and short names work.  For as long as I've been working with IP (20 years), there has always been a search or local domain setting, which is checked first and requires only the short name.  Any other domain requires a FQDN.

    Can you try with any other operating system?



  • It's is solely the client's responsibility to slap on search domains to short names, pfSense's "new" behaviour is the correct one.

    As a matter of fact, DNS doesn't know short names as such. The only "short names" recorded in DNS are the top level domains .com, .org and so on. All other cases of short names working as DNS names are the client appending a search domain to the short name to complete the name to a FQDN before it is tried with the DNS resolver.



  • As a matter of fact, DNS doesn't know short names as such. The only "short names" recorded in DNS are the top level domains .com, .org and so on.

    Actually, it's quite easy to have both FQDN and short names in /etc/hosts.  Either will return the correct IP address.



  • @JKnott:

    As a matter of fact, DNS doesn't know short names as such. The only "short names" recorded in DNS are the top level domains .com, .org and so on.

    Actually, it's quite easy to have both FQDN and short names in /etc/hosts.  Either will return the correct IP address.

    True but /etc/hosts is not part of  DNS, it's part of the local resolver(3) and entries in it are local overrides that don't have to play the rules of DNS and can have short names without interfering with anything else.



  • great discussion but i am the original poster of this thread and i had a problem ..  :)

    the problem is that after upgrading from 2.3.2 to 2.3.3_1, dns for servers on my local network that received their ip address from pfsense's dhcp server did not work anymore.
    i reported this on the installation topic, the administrator there said - very quickly imho - this problem was due to shortnames and threw my question over here to the DHCP and DNS topic.

    so i posted the content of my pfsense router's /etc/hosts (see first message in this thread). all entries there have fqdn's, next to short names.
    is the mere existance of the shortnames causing the problem? if so how do they get there?
    i'm not expert in this field but i do believe i have all settings correct:

    in dns forwarder: Register DHCP leases in DNS forwarder
    in system: general setup i have the domain filled in
    all clients have a search domain

    any help is appreciated!



  • @bheinsius:

    in dns forwarder: Register DHCP leases in DNS forwarder
    in system: general setup i have the domain filled in
    all clients have a search domain

    On the Services | DNS Resolver settings page, do you have this checked?:

    Static DHCP  Register DHCP static mappings in the DNS Resolver
    If this option is set, then DHCP static mappings will be registered in the DNS Resolver, so that their name can be resolved. The domain in System > General Setup should also be set to the proper value.



  • I don't use DNS Resolver, I use DNS Forwarder.



  • Hi,

    I had the same issue, not even long domain names worked in the DNS forwarder.
    Turns out it is due to a setting in the General Setup "DNS Server override"

    "If this option is set, pfSense will use DNS servers assigned by a DHCP/PPP server on WAN for its own purposes (including the DNS Forwarder/DNS Resolver). However, they will not be assigned to DHCP clients."

    That was checked on my setup and as such none of my local - full domain forward overrides - worked anymore.
    This was never a problem before pfSense 2.3.3_1.

    Perhaps it makes sense, but at least unchecking that and manually setting the DNS server setting above that instead of getting it from DHCP immediately fixed the issue I was having.
    After that I could query for any of the internal DNS entries again.

    cheers!



  • That solved it, thanks!



  • Well I rebooted pfSense while still on 2.3.3_1 and it stopped working again.
    So figured to update to 2.3.4 and see if that helped.

    Nope my local DNS forwards -with FULL FQDN!- do not work.
    I checked the same setting and the custom forwards immediately started working.

    For kicks I rebooted the pfSense box again and it -yet again- stopped working.
    Then I unchecked the "DNS Server Override" and it starts working again.

    So somehow the forwarder only works if you change that config setting.
    Smells like a bug to me.


  • LAYER 8 Global Moderator

    Dude are you hitting save after you uncheck use override?  That box would not recheck itself, unless you not saving the config change.



  • Sure I use save all right.

    You are missing what I am saying.

    It only works after I make a change to that particular setting.

    After I reboot the setting is still there an indication that the save worked.
    But the forwarder does not work for the list of predefined custom FQDNs unless I make a change.
    Once the setting has changed it works.

    It does not matter if the box is checked or unchecked.

    Wil


Log in to reply