Bug #6064: non-fully qualified hostnames included in hosts file and Unbound local-data - pfSense - pfSense bugtracker

Actions

Copy link

Bug #6064

closed

non-fully qualified hostnames included in hosts file and Unbound local-data

Added by Grischa Zengel over 8 years ago. Updated almost 8 years ago.

Status:

Resolved

Priority:

Normal

Assignee:

Category:

DNS Resolver

Target version:

2.3.3

Start date:

04/02/2016

Due date:

% Done:

Estimated time:

Plus Target Version:

Release Notes:

Affected Version:

All

Affected Architecture:

Description

mydomain: my.private

add test.my.private 127.0.0.1
add test.yours.private 127.0.0.2

> unbound-control -c /var/unbound/unbound.conf list_local_data | grep test
test.yours.private.    3600    IN    A    127.0.0.2
test.    3600    IN    A    127.0.0.2
test.    3600    IN    A    127.0.0.1
2.0.0.127.in-addr.arpa.    3600    IN    PTR    test.yours.local.
test.my.private.    3600    IN    A    127.0.0.1

> ping test
PING test.yours.private (127.0.0.2): 56 data bytes

That's wrong.

It should ping test.my.private=127.0.0.1 because:

> cat /etc/resolv.conf 
nameserver 127.0.0.1
search my.private

You should not add hostnames to unbound. Only FQDN.

Actions

Copy link

Updated by Jim Thompson over 8 years ago

Assignee set to Jeremy Porter

Actions

Copy link

Updated by Chris Buechler over 8 years ago

Subject changed from unbound: resolve host name to wrong domain to non-fully qualified hostnames included in hosts file and Unbound local-data
Status changed from New to Confirmed
Target version changed from 2.3 to 2.3.1
Affected Version changed from 2.3 to All

Subject is the issue. You end up with a hosts file like:

1.2.3.4    test.my.private test
2.2.2.2    test.your.private test

and you end up with a round-robin from Unbound.

;; ANSWER SECTION:
test.            3600    IN    A    8.8.8.8
test.            3600    IN    A    1.2.3.4
test.            3600    IN    A    2.2.2.2

with host_entries.conf file:

local-zone: "my.private" transparent
local-data-ptr: "127.0.0.1 localhost" 
local-data: "localhost A 127.0.0.1" 
local-data: "localhost.my.private A 127.0.0.1" 
local-data-ptr: "::1 localhost" 
local-data: "localhost AAAA ::1" 
local-data: "localhost.my.private AAAA ::1" 
local-data-ptr: "192.168.64.1 pfs23-test1.my.private" 
local-data: "pfs23-test1.my.private A 192.168.64.1" 
local-data: "pfs23-test1 A 192.168.64.1" 
local-data-ptr: "fc00::1 pfs23-test1.my.private" 
local-data: "pfs23-test1.my.private AAAA fc00::1" 
local-data: "pfs23-test1 AAAA fc00::1" 
local-data-ptr: "8.8.8.8 test.buechler.lan" 
local-data: "test.buechler.lan A 8.8.8.8" 
local-data: "test A 8.8.8.8" 
local-data-ptr: "1.2.3.4 test.my.private" 
local-data: "test.my.private A 1.2.3.4" 
local-data: "test A 1.2.3.4" 
local-data-ptr: "2.2.2.2 test.your.private" 
local-data: "test.your.private A 2.2.2.2" 
local-data: "test A 2.2.2.2"

It should be as easy as omitting non-FQDNs from host_entries.conf and /etc/hosts, but I have a feeling we'll break something by doing so, and it will need some time for testing. Post-2.3.

Actions

Copy link

Updated by Grischa Zengel over 8 years ago

As pfsense user/admin I wouldn't expect to have unbound entries in /etc/hosts
- It's better to have a extra table for /etc/hosts entries.
  Especially If you use Split-horizon DNS (Pfsense use external IPs and DNS client have to use internal IPs).
  \-or-
- check mark entries to use them in /etc/hosts
The format of the input form is historical and should have an other format in future
- Don't split hostname and domain. Use FQDN and split it if necessary.
  - Necessary are only <entered FQDN> = (.*)\.<local domain>
- I like to use a lot of "real" aliases and like to see what's the real host if I ping this.
  \>ping intranet.mydomain.local
  PING server3.mydomain.local (172.19.19.102) 56(84) bytes of data.
- Deleting multiple entries at once. (Check marks)
- Importing entries from csv
- A text input area which will be pasted to an user zone file

For the second point should I open a separate feature issue?

Actions

Copy link

Updated by Chris Buechler over 8 years ago

Target version changed from 2.3.1 to 2.3.2

Actions

Copy link

Updated by Chris Buechler over 8 years ago

Status changed from Confirmed to Feedback
Target version changed from 2.3.2 to 2.4.0

fix pushed to master/2.4 only, as that'll need more widespread testing than 2.3.2 will get before release.

Actions

Copy link

Updated by → luckman212 about 8 years ago

This didn't make it into 2.3.2_p1 right? Just checking. FWIW I have been running a couple of patched systems with this fix for a few months on 2.3.2 and have had zero issues with it.

Actions

Copy link