I am attempting to install DJBDNS on OpenSuSE my configuration is intended to install dnscache on a local host alias (127.0.0.53) and share the cache with multiple networks – this cache will only contain outside references for resolution (tinydns will run for each network providing internal network specific name resolution.)
What I have working – I can access a dnscache on another machine when it is coded in the /etc/resolv.conf file from the OpenSuSE box. However when I attempt to access this same cache from the djbdns cache program running on 127.0.0.53 I am not getting access (dnsip {address} is timing out and failing) could there be a flaw in either the options I specified in the /etc/sysconfig/network/ifcfg-lo file for the localhost aliases or do I have firewall issues because the cache to be referenced is the same as the external network’s gateway address. (I have opened the domain ports both tcp and udp on the external interface in the firewall.) I also indicated that the box should be protected from the internal network (firewall option) and no IP routing between networks is being done in the OpenSuSE box. By the way I can successfully ping 127.0.0.53 and the external network cache address (as well as (repeated claim) successfully use the external network cache address when it is in /etc/resolv.conf.
I’m not sure I understood all of that, your paragraph is very long.
However if you are trying to make 127.0.0.53 visible to other hosts on the LAN, that’s impossible. By definition 127.x.x.x addresses are only on the local host. Each machine will have their own 127.x.x.x space and pings to any address in that space will go to the local machine.
And you should never try to override the subnet for lo, it should always be 127.0.0.0/8.
I have achieved a similar process on an alternative flavor of Unix already. However the computer assigned to the task will not run that flavor of u\unix and it does run OpenSuSE.
The current issue is to allow a service listening to 127.0.0.53 named dnscache to communicate with an external gateway 192.168.0.1 using a nic configured to the external side of the firewall addressed 192.168.0.2 with that same external gateway address of 192.168.0.1.
The next step will be to have another dnscache service on each nic configured to listen the internal or dmz sides of the firewall such as 192.168.1.2 or 192.168.2.2 forwarding their request (like a proxy) to 127.0.0.53 for resolution. 127.0.0.53 maintaining a cache will either answer based on information it has or forward the request (as noted above) and cache the results for later use.
I have only added an alias and not overridden the subnet of local host. (SuSE has even already created a 127.0.0.2 alias (in addition to 127.0.0.1) for localhost for some internal reason already. I copied from their example to create my aliases.) Direct access from the outside networks is not intended with DJBDNS the connections can be made by creating a forwarding cache listening on each of the the network nic addresses and referencing the dnscache listening on the 127.0.0.53 local host address (like /etc/resolv.conf does for the local machine). Likewise this setup I am attempting is utilized to create a local cache for the single computer on which it resides (in those cases the established 127.0.0.1 localhost is commonly used) however I see little difference to creating a unique address for that purpose. (I could more further from the DJB base code by applying third party patches supporting listening on multiple addresses by a single cache however I would like to avoid that, if possible.) When setting up tinydns also a part of DJBDNS for internal network resolution a second address (sometines base on documentation on localhost) is absolutely required as both DNS resolvers cannot operate on the same address (an alias on an existing network card is possible when the content does not need to be shared). This is part of the security provisions made in DJBDNS by separating the functions of the monolithic bind alternative into multiple services that are each individually easier to secure including access limitations. (Including the possibility of an internal and external resolver for locally controlled domains providing one with the detail required for the internal use and another with limited references externally to the access points intended for appropriate use based on the relative location of the user that is either connected to the internally or externally to the local network.)
Ok, fine fine. So attempting to summarise that extremely long paragraph, and explanation of how djbdns and dnscache are separated by design, which is all in the docs anyway:
You are running djbdns bound to 127.0.0.53, and dnscache talks to it, and you want dnscache to be accessible from the outside, is that right? Sounds like you should pull out wireshark and see what packets are getting through and what’s in them. It could also be that they are getting through but can’t be routed back. More evidence gathering is needed.