Unable to illegal DNS record from pfsense (DNS-resolver corruption)
-
@asadz said in Unable to illegal DNS record from pfsense (DNS-resolver corruption):
But, we are using DC as DNS server it has SOA records
but your clients are pointing to unbound on pfsense, and then it forwards .local to your AD via a domain override?
You should point all clients directly to the AD for dns, and have it forward to pfsense for anything not in your namespace. You can then still leverage any filtering of dns this way that is outside your namespace.
sb.scorecodesearch.com :100.2.3.4
If you query your AD directly for sb.scorecodesearch.com what does it return? what does it return if you ask for sb.scorecodesearch.com.local
Did you mention you found this 100.2.3.4 address on some setting in pfsense? Is this the IP you return for when something is blocked?
I do not show sb.scorecodesearch.com as a valid domain.. But before you used sb.scorecardsearch.com
Do you have wildcards setup in your AD dns... This can be very problematic when a client appends your tld to its searches, also that 100.2.3.4 is a valid IP on the internet
;; QUESTION SECTION: ;4.3.2.100.in-addr.arpa. IN PTR ;; ANSWER SECTION: 4.3.2.100.in-addr.arpa. 86400 IN PTR pool-100-2-3-4.nycmny.fios.verizon.net.Could be possible your isp is doing some sort of dns shenanigans and for whatever reason when it intercepts your dns it returns this IP?? Is verizon your ISP by chance?
Keep in mind this can get really convoluted when devolution of a fqdn starts happening on a client where they can take out multiple levels in a fqdn say host.sub1.sub2.tld when using single label..
You will want to look into how devolution works, I know it can be modified from its default of 2 and only 1 or completely disabled.
When a client starts messing with the fqdn that is actually queried you can run into all sorts of weirdness.. Especially if wildcard returns can come into play on your dns, etc.
DNS Devolution
There might be newer info on this - but again I have been away from having to deal with MS dns weirdness for quite some time.. But yeah it can be problematic depending on the circumstances of what exactly is being asked for, what your using for you domain and what clients are doing with search suffix and or devolution of some fqdn.
-
@johnpoz said in Unable to illegal DNS record from pfsense (DNS-resolver corruption):
but your clients are pointing to unbound on pfsense, and then it forwards .local to your AD via a domain override?
I check my DHCP server on pfsense and its set DNS servers in order of
DC1
DC2
and Firewall interfacePlus, I think you determination of resolution order comes from the output of outbound command you showed earlier. Is that right?
unbound-control -c /var/unbound/unbound.conf lookup sb.scorecardsearch.combut in this case the authoritative ns for this domain cannot be .local, it outbound to find the authoritative NS?
pls see output of nslookup on DC, it shows 100.2.3.4
I do not show sb.scorecodesearch.com as a valid domain.. But before you used sb.scorecardsearch.com
yes it was an error /typo thank you for pointing it out.
On snort I see the incoming traffic from wan-infra being blocked and whats strange its coming for 100.2.3.4
Do you have wildcards setup in your AD dns... This can be very problematic when a client appends your tld to its searches, also that 100.2.3.4 is a valid IP on the internet
I cannot find using mmc /dns-server on DC.
Now, the ISP is not verizon
-
@asadz said in Unable to illegal DNS record from pfsense (DNS-resolver corruption):
I check my DHCP server on pfsense and its set DNS servers in order of
DC1
DC2
and Firewall interfaceYeah I would remove pfsense from that equation. You really have no idea what NS will be asked by a client at some time in the future. It at some point will not be in that order.
1433 is default MS SQL port.. So sure if your client wanting to talk to your sql server tried to go to some public IP out on the internet ie this 100.x address then sure snort might warn you of that.
If your MS dns, that 3.6 address returns 100.2.3.4 then that is where clients would go when they try and use that fqdn.
-
@johnpoz said in Unable to illegal DNS record from pfsense (DNS-resolver corruption):
@asadz said in Unable to illegal DNS record from pfsense (DNS-resolver corruption):
I check my DHCP server on pfsense and its set DNS servers in order of
DC1
DC2
and Firewall interfaceYeah I would remove pfsense from that equation. You really have no idea what NS will be asked by a client at some time in the future. It at some point will not be in that order.
1433 is default MS SQL port.. So sure if your client wanting to talk to your sql server tried to go to some public IP out on the internet ie this 100.x address then sure snort might warn you of that.
If your MS dns, that 3.6 address returns 100.2.3.4 then that is where clients would go when they try and use that fqdn.
Ok but the PTR records for DC should provide the response there is no 100.* Network on infra so a response coming back can resolve to any of local machines as currently abc.doman.local or xyz Al point to 100.*
where I can reload or refresh this mapping ? Do I need to rebuild DNS resolver?
-
@asadz said in Unable to illegal DNS record from pfsense (DNS-resolver corruption):
Ok but the PTR records for DC should provide the response there is no 100.*
What does that have to do with a forward query.. And yes there is a PTR for that 100 address, be it on your AD dns or not.
Not sure why you think a client would validate that the PTR matches the fqdn for some IP given back in A query. Yes some software can do this - smtp is known for doing such a check but that is not something typical to happen.
I have not had to play with MS dns for quite some time. But yes if however it finds that 100 answer it would cache, maybe you have a configured device registering that in your AD dns?
You would have to look to your AD dns on where it might have that entered or cached. But clearing the cache would not stop it from caching it again if when asked for something it resolves that something back to the 100.x address.
So if a client asks your AD dns for something that is not in your namespace what does it do - does it resolve it, does it forward it to pfsense? Does it forward it to some external dns?
Where exactly did you find this 100 address - you mention something about an interface? What I can tell you is that does not resolve on the public internet for sb.domain.com be it either of the examples you have given. And anything.whatever.etc.local would not resolve anywhere on the public internet
If you are using say pfblocker on pfsense - and your AD forwards to pfsense, then its possible that IP is getting returned as your blocked IP?
-
Not sure why you think a client would validate that the PTR matches the fqdn for some IP given back in A query.
This is since for .mydomain.local both SOA tells the administrative / authoritative zones for abc.mydomain.local is domain controller, and I expect it to return the correct address.
I have not had to play with MS dns for quite some time. But yes if however it finds that 100 answer it would cache, maybe you have a configured device registering that in your AD DNS?
I check all records there is none for 100.* address.
-
So if a client asks your AD dns for something that is not in your namespace what does it do - does it resolve it, does it forward it to pfsense? Does it forward it to some external DNS?
according to DHCP settings it should goto pfsense for addresses where NS is no authoritative, proof is in the DNS-REPLY.LOG from pfblockerng below
https://www.reddit.com/r/pfBlockerNG/comments/zneaec/comment/j0hpsw1/?context=3
see the dns-reply.log, (I cannot put here as it get flagged as spam idk)this is all outbound forward request made by DC the IP address is DC, and you can in response it brought back 100.*. This is the first entry of its own kind of entire /var/log. Under snort this IP address was present as PASSLIST but that passlist was not associated on snort interfaces.
Currently pfblockerng is disabled. Previously I couldn't ping this IP too, but now I can when I remove its alert entry in snort.
And anything.whatever.etc.local would not resolve anywhere on the public internet
I agree its not, but for all .local address nslookup it bring to 100.x which is no the correct PTR record for this zone.
-
based upon tracert results the query is going outside the network to find 100.2.3.4
-
@asadz well yeah if clients asks for something and gets back a IP that is not local - it would try to get their via its gateway.
The question is here is why/how is it getting this 100.2.3.4 address for what is being asked..
Where does AD get its answers when what is asked is not in your namespace? Does it forward, to where - does it resolve? Tell you right now .local would not resolve on the public internet.
You would get back a SOA for the roots because .local is not a valid TLD. There should be no way anything .local should be resolvable to anything outside your network.
Your 2 example sb.scorecard or sb.scorecodesearch.com do not resolve to 100.x on the public internet either. So somewhere you have it setup to return that 100.x address for something, be it a host entry in unbound or your AD, or some sort of wild card, etc. when there is a .local tld
100.x which is no the correct PTR record for this zone.
Not understanding your thought process on how that has anything to do with anything..
To get to the bottom of this - just take pfsense and your AD talking to each other out of the equation. Again what is your AD dns setup to do when you ask it for something it is not authoritative for - its either going to forward, or its going to resolve. If forwarding to pfsense change that so it forwards to say gooledns or cloudflare or something.. On pfsense remove any domain overrides for .local etc..
Now query each of them for your fqdn that is returning the bad 100.x address.
-
This post is deleted! -
@asadz flush the entries where? Not sure why you care about connections and traceroutes - if stuff your client want to talk to are resolving to this IP address, then its a give they will attempt to make these connections.
Those all go away when you have correct resolution of what your actually trying to get to - so now there is a proxy as well - proxies unless transparent will resolve things for where the client asks them to go, resolution is done by the proxy not the client when proxy is explicitly set on the client.
-
@johnpoz yes using HAPROXY but its for reverse proxy , I don't think it will effect how for addresses that local e.g .local.
-
I don't have much to add to what Johnpoz wrote, but I did a Google search and found the following that might help:
See [0022]:
https://patents.google.com/patent/US20070195800 -
@bbcan177 said in Unable to illegal DNS record from pfsense (DNS-resolver corruption):
I don't have much to add to what Johnpoz wrote, but I did a Google search and found the following that might help:
See [0022]:
https://patents.google.com/patent/US20070195800Thanks bbcan177, but this is not a design issue in my view all was working fine on Dec-14, you can see in dns-reply.logs above where the 100.2.3.4 first appear.
I tested with my vpn client DNS addresses set to 8.8.8.8/4.4.4.4 and on DNS resolver there is no static mapping or override for
pingme.mydomain.local
but still i'm getting response from 100., I think this is due to stale state table entry for 100. can i get ride of them without restarting firewall?. Thankyou
-
@asadz said in Unable to illegal DNS record from pfsense (DNS-resolver corruption):
I think this is due to stale state table entry for 100
No it has nothing to do with a state... You still have not answered the basic question of where does your AD point to??
-
@johnpoz you mean the DNS server it uses?
-
@johnpoz it points to itself as primary and as alternative to pfsense
-
@asadz said in Unable to illegal DNS record from pfsense (DNS-resolver corruption):
No that is NOT what I mean, and DC should never point to anything but itself.. Or its the other DC running dns running in your network.
Where does it go when a client asks it for something not in its namespace.. You setup MS dns to either forward or resolve - just like you do unbound in pfsense. The dns set on the interface has nothing to do with that.
-
@johnpoz pls see the output the second ip is pfsense interface (web-ui). First is second DC.
-
@johnpoz should i check DC2 settings as well, which is second domain controller..
