CNAMEs from another server to pfSense not working

oleg.blecher

Hi there,

Below you see a picture of our local network (both gateways are pfSense machines connected via IPSEC with identical configurations, and with proper domain overrides in DNS Resolver):

Imgur

I've just moved DHCP from our Samba DC to the pfSense gateway. Many old DNS posts under the internal.comapny.com-domain are still used. Many of them CNAMEs.

However, CNAMEs that are pointing to the local.company.com-domains do not resolve correctly, while the ones that resolve to the remote.company.com-domain names do resolve correctly.

More specifically, if I run dig localserver.internal.company.com (locally) I get the following:

;; ANSWER SECTION:
localserver.internal.company.com. 3600 IN      CNAME   server.local.company.com.

However, if I run dig remoteserver.internal.company.com (locally) I get a much nicer answer:

;; ANSWER SECTION:
remoteserver.internal.company.com. 3599  IN      CNAME   server.remote.company.com.
server.remote.company.com. 3599 IN A     10.10.100.100

nslookup doesnt give any answer at all.

When I run the same commands on the remote network, I always get proper answers and resolution all the way.

So I've decided to check the logs, this is what I saw for local dig localserver.internal.company.com:

info: sanitize: removing extraneous answer RRset: server.local.company.com. A IN 
info: sanitize: removing potential poison RRset: . NS IN

So is this a "feature"? Or did I misconfigure something? If you need any particular configurations, let me know please.

johnpoz

When you forward to another ns, ie a domain override.. rebind will be active. So the ns your asking for some fqdn returned rfc1918 you won't get that answer to the client.

You either need to turn off rebind completely, or best solution is to set the domain you have set in your override as private...
https://docs.netgate.com/pfsense/en/latest/dns/dns-rebinding-protections.html

oleg.blecher

Thank you @johnpoz! It was exactly that. However, if I don't check the Disable DNS Rebinding Checks box, and only add

server:
private-domain: "local.company.com"

It works for like a minute, and then it stops responding once again. And then I don't see anything at all in the logs. Could it be that I get "blacklisted" somehow?

Edit: even with Disable DNS Rebinding Checks on, it stops working after a minute or two.

I also wonder why aren't there any issues like that on the remote.company.com-side. The only differences there are that WAN is set on DHCP and that it's running pfSense 2.4.3-RELEASE (the local pfSense machine is running 2.4.4-RELEASE-p3).

Edit 2: I've finally found some stuff in the logs. I have 2 DNS servers configured under General , one that is the local IP address, and another that is the ISPs. I noticed that after a few minutes, Unbound starts forwarding the queries to my ISPs DNS-server. If I reload Unbound, it starts working right again.

What is actually the best way to configure DNS for the DHCP-clients? It seems to work very smoothly when WAN is on DHCP, but slightly more complicated when it's static.

johnpoz

Having 2 different NS is not good idea, because you never know where something might get forwarded. If your going to forward to multiple ns, then they need to return the same info..

So say you forward to 8.8.8.8 and 8.8.4.4 that is fine.. But you wouldn't forward to 8.8.8.8 and 9.9.9.9 since quad9 is going to be blocking, while googledns does not... So if you ask quad9 your blocked, but if you ask google you get back an IP, etc.

Same goes for public and local - public is never going to have a clue to what your local is, and he will send back NX for the domains your asking for.. So you wouldn't ever swing over and ask the other ns like you would if just didn't get any answer...

If you are putting in more than 1 NS, they better answer the same way all the time. Putting in
" I have 2 DNS servers configured under General , one that is the local IP address, and another that is the ISPs"

Is problem waiting to happen.

You have your clients ask your local, who then forward to public stuff it doesn't know - or it resolves directly for stuff it doesn't know, etc.

oleg.blecher

Thanks once again.

I think we will just have to live with it, because I can't really see a way we can have NS that return the same posts. Unless I turn the pfSense machine into a "proper" DNS-server, right? So that it can resolve external DNS-posts. And that means I would need to start using Bind, and not Unbound?

Configuring DNS-servers only on the DHCP Server-section makes some clients very confused and works differently on Windows and Linux clients.

johnpoz

Not sure how its hard? You point your clients to your internal ns(ers) and have them resolve/forward stuff they are not authoritative for.. Just don't point them directly to external and you won't have any problems.

Unbound can be authoritative for a zone in a fashion, you can create host overrides, register dhcp/reservations.. If you have a lot of them you can load them all via the custom options, or even load a file from there that contain all the records you want to resolve from there.

Point your clients to your local NS.. Only reason you need pfsense to have a domain override is so it can resolve stuff in your local domains for its own use, say resolve an IP in the firewall logs..

oleg.blecher

@johnpoz said in CNAMEs from another server to pfSense not working:

Point your clients to your local NS.. Only reason you need pfsense to have a domain override is so it can resolve stuff in your local domains for its own use, say resolve an IP in the firewall logs..

Do you mean in this case the AD domain controller with BIND, or the local pfSense machine?

Right now the DHCP clients are only using the local pfSense machine, which has a domain override to the AD DC, and everything is working really good, except those CNAMEs back to the pfSense domain...

johnpoz

I mean to the authoritative ns(ers) for your name space.

If you want to point your client to pfsense that sure have at it... But what you can not do is point the client to pfsense and then some public ns.. Since you never know where the client will query.

But if pointed to pfsense, and pfsense has an override to resolve domain.tld that points to where they can resolve that - that works too. You just need to make sure that when you forward to something that is going to return rfc1918 space that you correctly allow for rebind protection.