Unable to illegal DNS record from pfsense (DNS-resolver corruption)
-
@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..
-
@asadz also i checked DC2 points to PFsense infra interface (don't know why) should it not point to DC1 server IP address?
-
@asadz and what is this 192.168.4.4?
And yes you need to check both of them.
If they are not set to forward to pfsense.. And you still resolve your whatever to 100, then you prove to yourself its your AD dns issue..
Forward them to say google dns - these are the name servers used for resolving stuff not in your name space - they should not point to your AD for dns.. These are used to resolve the internet stuff, not stuff you are authoritative for forwarding to AD.. When then does what with it when asking for say www.google.com - forwards it back to the other one?
-
@johnpoz great makes 100% sense let me try this variation now.
-
@asadz
test done on DC1, DC2 i removed all pfsense IP put 8.8.8.8 in DC2,
in fwd section of DC1 i have put IP address of DC2, and I also tried put 8.8.8.8 with no reference of DC2, still resolves to 100.* :( -
@asadz said in Unable to illegal DNS record from pfsense (DNS-resolver corruption):
still resolves to 100.* :(
Because you have an issue with your AD, that was what I have been saying since the start..
in fwd section of DC1 i have put IP address of DC2
Pointless.. If client asks dc1 for say www.google.com which you are not authoritative for, what good is it to forward that to dc2? It is not authoritative for google.com either - so it would just have to forward that query as well.
The forwarders in your AD dns should point to what can resolve stuff you are not authoritative for.. The dns set on the server itself should point to itself, and the other AD dns running in your network..
My guess to your issue is you have a wildcard in your AD dns, do you have a * as a record.. this would resolve anything.otherthing.whatever.something.local to that IP.. Anything that does not have a specific record say host.local or sb.whatever.local to what that wildcard entry.
So if a client happens to ask for sb.scorecard.com.local - then it would return the wildcard record.
But now that you are not forwarding to pfsense, and your client directly asks your AD dns for whatever - and it returns that 100.x address you know for sure its an issue in your AD dns.. Or where your AD forwards.. but .local should never return anything on the public internet - it is not a valid tld.. And the 2 examples you gave of sb.domain.tld sure do not resolve 100.x on the public internet - one is not a valid domain, and the other resolves to public IP addresses that do not start with 100.
-
Because you have an issue with your AD, that was what I have been saying since the start..
but it was the pfsense according to dns-reply.log that return the bad ip address, on 14th dec the AD 192.168.3.6 did request for sb.scorecardsearch.com and it was returned that address. So, it behave as expected for ip/domains not under its control it fwd as expected.
My guess to your issue is you have a wildcard in your AD dns, do you have a * as a record.. this would resolve anything.otherthing.whatever.something.local to that IP.. Anything that does not have a specific record say host.local or sb.whatever.local to what that wildcard entry.
any specific place to check (please note im not an AD guy), i checked in forward and reverse lookup section found none with
*in itBut now that you are not forwarding to pfsense, and your client directly asks your AD dns for whatever - and it returns that 100.x address you know for sure its an issue in your AD dns.. Or where your AD forwards.. but .local should never return anything on the public internet - it is not a valid tld.. And the 2 examples you gave of sb.domain.tld sure do not resolve 100.x on the public internet - one is not a valid domain, and the other resolves to public IP addresses that do not start with 100.
Yes, i get your point AD is not forgetting this mapping , it is holding on to something also the TTL value 0 was a indicator as well, the request is not leaving the network (and going to internet)
what about stale records? also i'm able to resolve hostnames correctly with local nslookup/ping from DC, but that shouldn't matter as its local. -
@asadz on DC this is output of nslookup
Default Server: VM-DC1.dummy.local Address: 192.168.3.6 > sb.scorecardsearch.com Server: VM-DC1.dummy.local Address: 192.168.3.6 Non-authoritative answer: Name: sb.scorecardsearch.com Address: 100.2.3.4 -
@asadz said in Unable to illegal DNS record from pfsense (DNS-resolver corruption):
but it was the pfsense according to dns-reply.log that return the bad ip address
well yeah if pfsense asks your AD, and it returned that 100 then it would be cached.. This is why separation now allows you to figure out where the problem is.
Clear your AD dns cache.. if it still returns that address then you need to figure out why.. Sniff to see if your AD forwards that fqdn and gets back that answer. Or if when you client asks it just gets returned..
And again I would highly suggest you turn on debug when you do your nslookup - so you can validate exactly what is getting asked.
That "Non-authoritative answer" points to that being in cache.
-
@johnpoz I will run wireshark then, but i don't know if its install winpcap drivers on DC idk.
> sb.scorecardsearch.com Server: VM-DC1.dummy.local Address: 192.168.3.6 ------------ Got answer: HEADER: opcode = QUERY, id = 10, rcode = NXDOMAIN header flags: response, auth. answer, want recursion, recursion avail. questions = 1, answers = 0, authority records = 1, additional = 0 QUESTIONS: sb.scorecardsearch.com.dummy.local, type = A, class = IN AUTHORITY RECORDS: -> dummy.local ttl = 3600 (1 hour) primary name server = vm-dc1.dummy.local responsible mail addr = hostmaster.dummy.local serial = 15316 refresh = 900 (15 mins) retry = 600 (10 mins) expire = 86400 (1 day) default TTL = 3600 (1 hour) ------------ ------------ Got answer: HEADER: opcode = QUERY, id = 11, rcode = NXDOMAIN header flags: response, auth. answer, want recursion, recursion avail. questions = 1, answers = 0, authority records = 1, additional = 0 QUESTIONS: sb.scorecardsearch.com.dummy.local, type = AAAA, class = IN AUTHORITY RECORDS: -> dummy.local ttl = 3600 (1 hour) primary name server = vm-dc1.dummy.local responsible mail addr = hostmaster.dummy.local serial = 15316 refresh = 900 (15 mins) retry = 600 (10 mins) expire = 86400 (1 day) default TTL = 3600 (1 hour) ------------ ------------ Got answer: HEADER: opcode = QUERY, id = 12, rcode = NOERROR header flags: response, want recursion, recursion avail. questions = 1, answers = 1, authority records = 0, additional = 0 QUESTIONS: sb.scorecardsearch.com, type = A, class = IN ANSWERS: -> sb.scorecardsearch.com internet address = 100.2.3.4 ttl = 0 (0 secs) ------------ Non-authoritative answer: ------------ Got answer: HEADER: opcode = QUERY, id = 13, rcode = NOERROR header flags: response, want recursion, recursion avail. questions = 1, answers = 0, authority records = 1, additional = 0 QUESTIONS: sb.scorecardsearch.com, type = AAAA, class = IN AUTHORITY RECORDS: -> scorecardsearch.com ttl = 363 (6 mins 3 secs) primary name server = ns1.bodis.com responsible mail addr = dnsadmin.bodis.com serial = 2017062202 refresh = 10800 (3 hours) retry = 3600 (1 hour) expire = 1209600 (14 days) default TTL = 3600 (1 hour) ------------ Name: sb.scorecardsearch.com Address: 100.2.3.4 -
@asadz said in Unable to illegal DNS record from pfsense (DNS-resolver corruption):
QUESTIONS: sb.scorecardsearch.com, type = A, class = IN ANSWERS: -> sb.scorecardsearch.com internet address = 100.2.3.4 ttl = 0 (0 secs)Well that shows your AD returned that answer..
Did you sniff on traffic on your AD dns when that was asked? Did you flush your cache? Sniff will validate to you that your AD answered that on its own, or got that answer after asking its forwarder..
Or look to your AD dns logs - don't recall the level of logging, but you would hope you could log if answered on its own or got that from one of its forwarders..
-
Well that shows your AD returned that answer..
from the TTL value i guess?I'm doing a trace using netsh, and using message analyzer to analyse it, will share outcome soon.
