First post.... Lan/some Vlans cant get to website, some vlans can

bmeeks

Allow me to follow up my previous post with one other common DNS misconception.

Some admins believe that when multiple DNS servers are provided to a client, and that client asks Server #1 for domain something.com and Server #1 says "can't find it", that the client will then automatically pass the same request along to Server #2 and so on to each DNS server the client was provided.

That is totally incorrect! When Server #1 says "domain not found" (or actually, it will return NX DOMAIN), the client gives up and never asks any other DNS servers for that record. That's because the first server said "that domain does not exist", so the client figures there is no use to pursue the quest any further.

VillageIT

@johnpoz said in First post.... Lan/some Vlans cant get to website, some vlans can:

@VillageIT said in First post.... Lan/some Vlans cant get to website, some vlans can:

. In the sonicwall the DHCP server listed our domain server as first DNS, and I copied that over to the PFsense, as well as 8.8.8.8 and 8.8.4.4.

So your handing out dns other than your AD to your clients? That is going to be problematic for sure. You really have little control what dns a client would use when you list more than 1.

Clients should only ever point to dns that resolves the same stuff.. 8.8.8.8 for sure isn't going to have a clue about your AD records.

Out of the box pfsense resolves - did you change this to forwarding? In an AD shop I would recommend dns and dhcp be handles by your AD.. clients should point to and get dhcp from your AD.

You can then have your AD forward to pfsense, which can then either just resolve or you could set it up to forward to whatever external dns service you want to use.

You could also just point your clients to pfsense, and have a domain override setup for your AD domain.. But if your a MS shop, and using AD its just easier to let the AD handle dns and dhcp.

But clients should only ever talk to dns that can resolve the same thing.. Lets say you setup X and Y for dns.. And X filters, and Y does not.. If your client asks X your filtered, but if you ask Y your not.. So are you actually filtered? You have no idea which dns a client might decide to talk to for any given query.

Very true... I guess I set it up that way because "it's how it's always been". Yes, active directory. There are 22 devices that utilize the AD server (hosted on a synology diskstation in the main IT room). I had left the 8.8.8.8 in the secondary mostly because it had always been, and I felt that if the AD failed the hosts could at least resolve outside. Very good information you both share about hosts not always using the order specified. I'll definitely look to adjust how we handle this. I'm liking the domain override route as it allows me to avoid running everything through the synology. Maybe the synology would be capable, but I hate to have the whole network dependent on it.

Thank you so very much for bearing with me. I'm not a full time IT admin (outside our properties that is). I'm fairly capable, but I'm struggling to make changes wholesale that risk losing connectivity.

VillageIT

@bmeeks said in First post.... Lan/some Vlans cant get to website, some vlans can:

Allow me to follow up my previous post with one other common DNS misconception.

Some admins believe that when multiple DNS servers are provided to a client, and that client asks Server #1 for domain something.com and Server #1 says "can't find it", that the client will then automatically pass the same request along to Server #2 and so on to each DNS server the client was provided.

That is totally incorrect! When Server #1 says "domain not found" (or actually, it will return NX DOMAIN), the client gives up and never asks any other DNS servers for that record. That's because the first server said "that domain does not exist", so the client figures there is no use to pursue the quest any further.

Iwas not previously aware of that either. Seems like an extremely basic concept, but I hadn't thought of it. I'll be adjusting the dns layout definitely.
Thank you for the pointers. The answers here are exactly what I was hoping for when I posted.

bmeeks

@VillageIT said in First post.... Lan/some Vlans cant get to website, some vlans can:

I'm liking the domain override route as it allows me to avoid running everything through the synology.

Dont' forget to also add a reverse PTR domain override as well for your AD domain. You should place two domain overrides in your pfSense DNS Resolver configuration. One for the actual domain name and one reverse PTR so IP address lookups to hostnames will work in AD. You can see what both of these overrides should be named by looking at the current setup in your Windows AD DNS.

Secondly, I would ditch the Google servers altogether. Not needed. Set the DNS Resolver on pfSense to "resolve". That is the default. If you checked the "Forward" checkbox earlier, uncheck it. Also remove any DNS servers you may have entered on the SYSTEM > GENERAL setup tab. Leave those blank. pfSense comes out of the box with a ready to run DNS resolver - unbound. You don't have to change a single thing from the defaults for that to work. All you need to add are the two domain overrides I mentioned (one for your AD domain name and one for a reverse PTR scope).

Make sure DHCP on pfSense (if that's where your DHCP is configured) is set up to give clients the pfSense box as their only DNS server. Do not give your clients multiple DNS servers. If you do domain overrides, then give the clients only the pfSense box IP for their DNS server. If you are using DHCP within Windows AD, then configure that server to hand out the pfSense box IP as the "DNS" server clients should use.

johnpoz

@VillageIT said in First post.... Lan/some Vlans cant get to website, some vlans can:

"it's how it's always been".

That is another one of those misconceptions if you ask me.. Network guy takes over other network - and just goes with the flow, since it seems to be working..

See that all the time as well - when would start working with a new customer.. And you ask the network guy(s) hey why do you have it setup this way.. Because that was the way it was when we got here is a very common answer..

One customer network drove me crazy with this sort nonsense.. Why do you have a /16 for your printer vlan? You have like maybe 100 printers tops in the whole company.. Why do you not set gateways on the printers?? Thats the way it was when we got here.. They were using proxy arp to be able for the other networks to talk to the printers.. Vs just setting the gateway up on them via dhcp or static.. Was like WTF ;)

bmeeks

@VillageIT said in First post.... Lan/some Vlans cant get to website, some vlans can:

@bmeeks said in First post.... Lan/some Vlans cant get to website, some vlans can:

Allow me to follow up my previous post with one other common DNS misconception.

Some admins believe that when multiple DNS servers are provided to a client, and that client asks Server #1 for domain something.com and Server #1 says "can't find it", that the client will then automatically pass the same request along to Server #2 and so on to each DNS server the client was provided.

That is totally incorrect! When Server #1 says "domain not found" (or actually, it will return NX DOMAIN), the client gives up and never asks any other DNS servers for that record. That's because the first server said "that domain does not exist", so the client figures there is no use to pursue the quest any further.

Iwas not previously aware of that either. Seems like an extremely basic concept, but I hadn't thought of it. I'll be adjusting the dns layout definitely.
Thank you for the pointers. The answers here are exactly what I was hoping for when I posted.

Yeah, the only way multiple DNS servers on a client would really come into play is if one of those servers failed to respond to a query at all.

To simplify things a bit for this example, you can pretend that the first thing a client does during a DNS request is to "ping" the target DNS server, and if that server fails to answer at all, then it will mark that one as "dead" and try the next one in the list. Once it finds the first DNS server that answers, it will mark that one as "the one we use" and that's it. The client will not choose another one unless this one also eventually fails to respond.

Now the client does not literally do an ICMP ping, it insteads executes a query over DNS port 53 (or 853 if using TLS) to the server. If it fails to get any reply back, it waits for the configured DNS timeout period and then tries the next DNS server in the list. Once any DNS server answers the initial query, the client will then use only that server for future DNS requests (until it fails to respond).

But key in the above is that "failure to respond" means the equivalent of "did not answer a ping". The server may instead answer the "ping" but say "I can't find the host or domain you asked for". The client says okay, forget it, and will not ask any other server. Having multiple DNS servers listed is for actual DNS server failures -- it is not to have a list of servers you ask in succession until one of them gives you an answer for some host or domain.

VillageIT

ok guys.... I've traded all the DNS in my system to use the pfsense box, and moved all the phones, etc to the networks I wanted them on, and pretty much got the networks the way I think they should be (or reasonably close so we can run this way indefinitely). Yesterday I didn't seem to have any issue getting to the tools (we have a maintenance ticket system, transportation calendar (booked is the software if you are familiar), a phpbb "communication log" and a couple similar things.....

This morning at 10:30 they went unreachable again. One more data point I hadn't realized before... They are on domain.net/log, domain.net/maint, and domain.net/calendar.... The index.html at the base domain is simply a time/date page one of our shared monitors use to display thaat info.... I can get to the domain.net.
WTH?!?!?!?!?
What can cause the base domain to be reachable but not the folders under it? Intermittently????? Not sure this is a pfsense thing..... Not sure it's my issue at all.... Hostgator says they have no idea.....
AAAGGGHHHH

johnpoz

@VillageIT how would it be a pfsense thing.. pfsense has zero to do with you getting to domain.tld vs domain.tld/index.html or index.php or otherpage.html on that domain.

Unless your running proxy or ips - pfsense just sends the packets on, and to whatever IP the fqdn resolves too..

VillageIT

@johnpoz I mean a setup thing on my end...
Came back up all by itself at 1:30. It's gotta be something here, just can't get my head around it. It's just to strange that it's one of 4 websites we use all day every day. I used to have them hosted on site (I have a cpanel metal box here) but moved them to hostgator because I thought about getting rid of the cpanel when their prices went nuts. Might have to move them back.

Are we allowed to solicit moderators to take a look? You'd probably find my error in minutes.

bmeeks

Your problem as described in your previous post is not a pfSense issue. It is something on your web server setup. Your domain.net I assume resolves to a single IP. The URLs have the domain name in them, but then also include a web path that only the web server (or a web proxy) can read and understand. DNS and pfSense stop at the end of net in your example. The trailing slash and everything after that is the responsibility of the web host the URL is directed towards.