thegeezer <thegeezer <at> thegeezer.net> writes: > > generally using something like ISC BIND you can set filters and easily > create an external view and internal view, so that you can do split dns > based on network connection. if doing something like this test it and > then test it again to make sure there is no leak due to a typo. > > it would be easier if we knew what you were standing up the servers for. > if it is for example your own domain name, you want something simple > like a couple of A addresses and an MX record then you don't need to > deviate much.
Well some things will be very simple (minimal). Then, There is a "portal" I'm researching where we run all sorts of applications very securely, for one person at a time. It's eventually (hopefully) going to be a full LMS Learning Management system, something comprehensive, maybe even www-apps/moodle and or SWAD. Eventually a full ecommerce system, just for one company, not as a service to others. But for now, just running various forms of secure, minimized DNS. Some machine controls (SCADA) will use the DNS as part of the SSL services. > > if you are looking for dynamic dns updates you want to make sure you > have auth by secured ip (encrypted traffic) and you want to guard your > keys to allow DDNS. > > DNSSec is to prevent MITM attacks such as DNS cache poisoning, and you > can see some starter material at ISC BIND website [1] DNS sec will be down the road. I have time to build, test, research and adjust the strategy as this goes along. It's not fixing a desparate situation; more along the lines of building up various secure dns platforms along an increasing features set. > In terms of "hack my dns server" there are many things that can hamper > it - something at the bleeding edge like gentoo is ace for this kind of > thing (*cough* centos is prehistoric *cough*) and if you were to load up > metasploit with ISC specific filters you can try to see what is > vulnerable. you can filter by CVE on your favourite website [2] Yep: http://cyberarms.wordpress.com/2014/04/20/detecting-openssl-heartbleed-with-nmap-exploiting-with-metasploit/ I got that, hense the advise is being sought out, first. > If the server is public facing then you want to be wary of such goodies > as recursive lookups as these can contribute to DoS attacks. you might > also like to try flooding the server with DNS or spoofed ip and see what > it responds to. these are not necessarily dns server specific but UDP > server specific and you can start to get an idea of scalability. One of the things I like to do, is profile the traffic, particularly in "well behaved, machine control networks" with IP services first. The open them up and gather some statistics, to start to develop some heuristics for patterns and volumes of excpected and un expected traffic flows..... That will be for latter. > in terms of primary to secondary then you have to question the > underlying layers -- is this being xferred across the internet ? > internally over vpn ? are your secondary servers going to be full > secondaries or just caching forwarders ? how will you control zone > transfers ? consider filtering the type of queries, and the size > of queries > > also consider the consequences of a hack. use selinux or similar, make > sure dns running in its own username and/or namespace. primary target > though has to be to change dns zones, so to make www.example.com map to > www.clickads.com, so make sure that you have a remote server doing > lookups regularly and report anomalies. > > hope this gives you a few directions to explore! Yep, THANKS! James > > [1] http://www.isc.org/downloads/bind/dnssec/ > [2] > https://kb.isc.org/article/AA-00913/0/BIND-9-Security-Vulnerability-Matrix.html > >
