Open skl256 opened 1 month ago
Thanks for the post. The Split Horizon app will only return the data in it's APP record json and thus its not a feature that the app supports. This kind of feature will require creating another DNS app.
You can give a try for the Advanced Forwarding app where you can create group which can be configured to use this-server
as the forwarder so that it resolves the actual domain name and the rest of other clients would hit the conditional forwarder zone that you already have where you can now just have a simple A record instead of the APP record.
@ShreyasZare
So, you want to say that this is expected behavior?
Without configured APP record, the request "QNAME: rr2---sn-axq7sn7l.googlevideo.com; QTYPE: A; QCLASS: IN;" returns a correct response with the IP address: "RCODE: NoError; ANSWER: [rr2.sn-axq7sn7l.googlevideo.com., 74.125.163.84]".
With configured APP record, the same request "QNAME: rr2---sn-axq7sn7l.googlevideo.com; QTYPE: A; QCLASS: IN;" returns a response without the IP address: "NoError; ANSWER: [rr2.sn-axq7sn7l.googlevideo.com.]".
P.S. above - these are responses for DNS clients that are not included in the list of "private" and "my-isp" networks, of course, in the second case, for them (for "private" and "my-isp") "RCODE: NoError; ANSWER: [192.168.2.114]" is returned.
It seems to me that the expected behavior is that for clients from other networks, if they are not specified in the APP record, the same DNS response should be returned as would be returned without the "Split Horizon" app?
Thanks for the details. Please ignore my previous comments, since they are incorrect. Sorry about that.
I check the code again and yes, its supposed to work as you are expecting. That is, the APP record for the Split Horizon app should cause the DNS server to return the actual public IP for the domain name when the client does not match with any of the networks defined in the APP record's JSON config.
There is a bug in processing the causing the FWD record to not get processed in this specific scenario causing the response to contain the CNAME answer and FWD record as-is in the authority section. I am fixing the code so that the FWD record gets processed and the proper public IP of the domain gets added to the answer. This fix will be available in the upcoming update.
@ShreyasZare Can you please suggest an approximate time frame for fixing this, it just depends on this now, should I just wait or look for a temporary workaround? Thanks in advance!
Thanks for asking. The upcoming update is in its final implementation stage. It should be available after a few more days. Will post it here when its released.
There is no workaround for this issue that I know of since its an issue with the DNS server process itself.
I configure "Conditional Forwarder Zone" googlevideo.com.
Records:
@ APP
and
* APP
I expect that for clients in the private network and in the my-ips list, the request rr2---sn-axq7sn7l.googlevideo.com will return the IP address 192.168.2.114, and for other clients, the actual IP address will be returned (currently 74.125.163.84).
In fact, the response is returned without an IP address. Log:
[2024-08-14 17:15:22 Local] [<other clients IP>:64300] [TCPPROXY] QNAME: rr2---sn-axq7sn7l.googlevideo.com; QTYPE: A; QCLASS: IN; RCODE: NoError; ANSWER: [rr2.sn-axq7sn7l.googlevideo.com.]