Apparent internal DNS issue

Currently reading
Apparent internal DNS issue

Here is the DNS path:
computers->NAS->router->9.9.9.9
The NAS only resolves for the AD domain and forwards other requests to the router. The router forwards requests to 9.9.9.9.
Note that this all works perfectly. The computers resolve ALL names. The router is not on the domain.

Pointing the router to the NAS would break name resolution in my system. I could change the NAS to forward directly to 9.9.9.9 and bypass the router. But the router on the WAN side would not be able to be pointed to the NAS because its on the other side of the NAT translation. I think.

I also honestly don't see that this could help.
 
Pointing the router to the NAS would break name resolution in my system
Agreed. Mere fact that dns for clients is being forwarded to the router and letting that out is mind boggling that itself can’t name resolve.
-- post merged: --

Have you tried rebooting the ont in addition to the router? Maybe the ont is holding onto the previous routers MAC address and therefore not transmitting properly??? Lol now just throwing stuff at the wall
 
All I can add to this is show my RT2600ac's DNS configuration, in SRM 1.2. Setup is:
  • ISP router in modem/bridge mode to RT2600ac WAN port.
  • SRM DNS Server running as slave zones to personal domain master zones on DSM DNS Server.
  • LAN DHCP by RT2600ac, but that should be immaterial.
  • LAN DHCP points DNS to RT2600ac LAN IP first and NAS LAN IP second.
  • Safe Access intercepts web requests from LAN clients.
  • SRM Control Panel set to use time.euro.apple.com NTP server (because that's what everything else on the LAN has used for years).
SRM Network Center
1659599696092.png


SRM DNS Server (same Resolution settings in DSM DNS Server)
1659599980104.png


Control Panel
1659600197737.png



For a short while I went to having a problem setting SRM to use the NAS LAN IP as NTP, but this was resolved by Synology. The reason I decided to use the NAS as NTP server was that if there was an Internet outage and I power-cycled the router then it may not set an accurate time for 2FA. I actually had a lot of 2FA issues on SRM where there was too much drift so much so that I stopped using it. Instead I have a different administrator account, strong password, and don't allow WAN access to the router... except for VPN Plus and even then only for LDAP users from the NAS and only user level accounts. Also, I don't run any other services (e.g. file sharing, media sharing) and don't allow users to log in, hence using LDAP accounts managed on the NAS.
 
Fredbert & Gerard, thank you for your efforts on this. It is now more or less resolved. I will tell you the resolution first and then how I figured it out, which you may not want to bother to read :)

The problem had nothing to do with DNS. The RT6600ax suggests 2 public time servers in its dropdown menu: pool.ntp.org and time.nist.gov. I tried both of them and they failed. But it turns out time.google.com works. So the issue is a sensitivity to unreliable public time servers. Gerard, you were right that it WAS something stupid.

How I figured it out? I had opened a ticket with Synology and they wanted me to enable SSH and remote access so they could debug. I had not realized that I could SSH into the router, so I did that myself of course. In a past life, I was an embedded engineer and I had worked with unix/linux network stacks and I even worked on software-based routers. It was a long time ago and I was rusty, but I figured out that the SRM could indeed resolve names (using nslookup). So right away I knew it wasn't dns. I also checked the /etc/ntpd.conf file and saw that whatever I had typed into the synch field for time server was indeed going into the ntp configuration. Unfortunately now I went down the rabbit hole of deciding that it was a firewall problem. It was not.

This morning I decided to check my NAS which I knew worked and see how the ntp setting was made and I saw that I had selected time.google.com as a server. Then I changed the SRM setting to time.google.com and it worked!!!!! There seems to be two problems with public ntp servers which I was unaware (or had forgotten): 1) longer than expected timeouts 2) response never comes back. I believe ntp is over UDP (Unreliable Data Protocol) so this stands to reason. SRM is extremely sensitive to this. DSM seems to be slightly less sensitive to this. I could go back and compare the ntpd.conf files for both, but I've done enough to debug Synology's issues here. From my point of view I can go back to my real job!
 
Fredbert & Gerard, thank you for your efforts on this. It is now more or less resolved. I will tell you the resolution first and then how I figured it out, which you may not want to bother to read :)

The problem had nothing to do with DNS. The RT6600ax suggests 2 public time servers in its dropdown menu: pool.ntp.org and time.nist.gov. I tried both of them and they failed. But it turns out time.google.com works. So the issue is a sensitivity to unreliable public time servers. Gerard, you were right that it WAS something stupid.

How I figured it out? I had opened a ticket with Synology and they wanted me to enable SSH and remote access so they could debug. I had not realized that I could SSH into the router, so I did that myself of course. In a past life, I was an embedded engineer and I had worked with unix/linux network stacks and I even worked on software-based routers. It was a long time ago and I was rusty, but I figured out that the SRM could indeed resolve names (using nslookup). So right away I knew it wasn't dns. I also checked the /etc/ntpd.conf file and saw that whatever I had typed into the synch field for time server was indeed going into the ntp configuration. Unfortunately now I went down the rabbit hole of deciding that it was a firewall problem. It was not.

This morning I decided to check my NAS which I knew worked and see how the ntp setting was made and I saw that I had selected time.google.com as a server. Then I changed the SRM setting to time.google.com and it worked!!!!! There seems to be two problems with public ntp servers which I was unaware (or had forgotten): 1) longer than expected timeouts 2) response never comes back. I believe ntp is over UDP (Unreliable Data Protocol) so this stands to reason. SRM is extremely sensitive to this. DSM seems to be slightly less sensitive to this. I could go back and compare the ntpd.conf files for both, but I've done enough to debug Synology's issues here. From my point of view I can go back to my real job!

So when you did the ping test on a dns name, were you using those ntp servers as a test? Did you attempt any other domain names to see if the router was resolving too? I was under the impression that on the router ping test no dns name would work at all.
 
Good question. So I went back and checked now. I had tried traceroute and not ping. And I tried google.com. I had only gotten one entry in the traceroute so I figured that it had failed. Had I tried ping, which I just tried, I would have seen that it worked properly. Turns out I am too old and the internet has changed. The one entry for traceroute WAS google.com because its only one hop on the Verizon network. I guess intermediate hops are no longer shown with traceroute, so I misinterpreted the one hop to mean it didn't work. Stupid of me. Had I tried it from the SSH instead of the graphical tool I was unfamiliar with, I would have figured that out immediately.
 
Good question. So I went back and checked now. I had tried traceroute and not ping. And I tried google.com. I had only gotten one entry in the traceroute so I figured that it had failed. Had I tried ping, which I just tried, I would have seen that it worked properly. Turns out I am too old and the internet has changed. The one entry for traceroute WAS google.com because its only one hop on the Verizon network. I guess intermediate hops are no longer shown with traceroute, so I misinterpreted the one hop to mean it didn't work. Stupid of me. Had I tried it from the SSH instead of the graphical tool I was unfamiliar with, I would have figured that out immediately.

Ahh makes sense now. Glad it’s working now.
 

Create an account or login to comment

You must be a member in order to leave a comment

Create account

Create an account on our community. It's easy!

Log in

Already have an account? Log in here.

Similar threads

While I cannot speak to the management console of your router, one is typically assigned a /64 block (at a...
Replies
4
Views
2,667
I have a question. So this is network speed issue on your NAS or on your PC? Not sure I picked up what...
Replies
1
Views
858
Hi! Finally, Synology fix the issue. How? Disable PPPe acceleration. How? With a script that they do not...
Replies
15
Views
2,190
  • Question
User defined Destination NAT (DNAT) /Source NAT (SNAT) is what is needed. My last router had this and...
Replies
1
Views
910
  • Question
checkip.synology.com is forever present on the NAS as well where it runs every 3 minutes. I disabled QC...
Replies
2
Views
1,227
I've configured the OpenVPN server in SRM (in vpn plus server), and I've checked the 'allow clients to...
Replies
0
Views
860
Thank you for the answers. It is runninig now without that one line. Will look later if I really need this.
Replies
28
Views
9,505

Welcome to SynoForum.com!

SynoForum.com is an unofficial Synology forum for NAS owners and enthusiasts.

Registration is free, easy and fast!

Back
Top