The Amiga Future 144 was released on the May 4th.
4 posts • Page 1 of 1
In my LAN I have a NAS acting as local DNS server (proxying real dns servers). My cablemodem (= default gateway & local DHCP server) lists this NAS as primary DNS server.
Now my Amigas tend to have some difficulty with the NAS dns server. Also Roadshow, when set to dhcp, I think. Somehow dns lookups work only one boot in many. All other boots dns lookups don't work.
Now I could setup the Amiga with a fully static config, but frst I hoped I could still use dhcp to get IP, gateway & subnetmask and set static DNS servers. Unfortunately these static dns servers seem to be lower in priority than the dhcp retrieved dns servers? Is there a way to overrule the dhcp retrieved dns servers? Or do I really have to disable dhcp?
Is this strictly necessary? I am asking because normally, your ISP would suggest which DNS servers to use, and these are commonly caching responses and respond most quickly to queries from your home network. The downside to using the ISP-provided DNS servers is that some (many?) ISPs will not transparently resolve queries but insert their own responses.
Can you replace the DNS server which your NAS uses? It's possible that the problem is not so much with the NAS, but with the DNS server it delegates its queries to.
This could be caused by DNS lookups taking too long to complete. Lookups must succeed within five seconds after a query is sent. Hard to tell if this is cause, though
Yes, I am afraid this is the only solution available right now. The DNS servers provided through the DHCP negotiation do take priority over the statically configured DNS servers. I made the choice back then because misconfiguration of the static DNS servers tends to be a bigger problem than DHCP configuration of the servers to use. Giving the user a choice which servers to prefer would be possible, but that won't be a feature which is likely to become available soon enough
Implementing multicast DNS is a wee bit too tricky for me Porting an existing mDNS implementation would be possible, but the downside would be in making the Roadshow bsdsocket.library even larger than it currently is.
Hm... may be a solution would be in making the name resolution which bsdsocket.library performs extensible through an API. One could then write a service which hooks into the existing built-in name resolution process to do all the heavy lifting. I'll make a note of that.
Firstly, however, I need to implement the option to prioritize the use of the statically configured DNS server addresses over those added by the DHCP client.