Bug #3530
closed
TinyDNS creates incorrect NS records
0%
Description
pfsense: 2.1-RELEASE (i386)
dns-server: 1.0.6.18
When enabling the "Automatic PTR entry" for an A record, an explicit NS record is also created. This is problematic in my environment because the NS record that is created uses the hostname of the firewall. The correct NS record (in my env) should actually be the loopback address.
For example, I have an existing zone, 0.168.192.in-addr.arpa, with an NS of 127.0.0.1.
I create the A record "test.myprivate.domain=192.168.0.100" and enable "Automatic PTR entry".
The following tinydns records are created:
=test.myprivate.domain:192.168.0.100:100
.100.0.168.192.in-addr.arpa::hostnameofmyfirewall.mypublic.domain
In my environment, the second line is unnecessary, but if an explicit NS record is created it should read:
.100.0.168.192.in-addr.arpa::localhost
I think some logic should be added so that an NS record is only added if one does not already exist for the associated PTR zone. I don't think the assumption should be made that the nameserver is going to be the firewall's hostname.
Line #572 of tinydns.inc is where this NS record is added. Removing the line prevents the NS record from being created.
Updated by Kill Bill almost 9 years ago
Cannot see how on earth is proper FQDN "incorrect" and localhost "correct" for a NS record anywhere but for localhost and 0.0.127.IN-ADDR.ARPA. Resolved WTF?
Updated by Chris M almost 9 years ago
To better explain: in my PFsense environment, there are two nameservers:
- recursive nameserver bound to the private address of the firewall
- authoritative nameserver bound to the loopback address of the firewall
Clients on the network use the recursive nameserver for all queries. If a request is made for a domain that the authoritative nameserver handles, the recursive nameserver forwards that request to the authoritative nameserver.
In a nutshell, my PFsense env has two nameservers; since both nameservers cannot be bound to the same address I have elected to bind the authoritative nameserver to the loopback address. This is not a problem because the only queries ever made to the authoritative nameserver will come from the firewall.
In any case, I think the assumption that the nameserver for any zone is going to be the hostname of the firewall is problematic. What if this were a nameserver bound to a different IP address than that which corresponds to the FQDN of the firewall?
Updated by Kill Bill almost 9 years ago
My humble suggestion would be to NOT use "Automatic PTR entry" in your highly weird environment that probably noone else uses.
Updated by Michael Hasse about 8 years ago
Not particularly weird, it's really the only way to do split DNS on one box.
The difficulty is how TinyDNS could know which name is the correct one.
My recommendation would be to not auto-create the records, (ever, really), but if people really need it then the OP's suggestion of checking for an existing record first would be the way to go.
Updated by Chris Buechler almost 8 years ago
- Status changed from New to Needs Patch
this package has been deprecated