On Mon, 2004-05-03 at 15:17, Varun Varma wrote: <snip> > I hope you realise that zone transfers are read only, and pose no threat > to the security of the server what-so-ever.
AFAIK, the reason for closing axfr access is not only the DNS server's security. Its also about *not* revealing details about your other hosts for (cr)(h)ackers/spammers to sit and hit around. > All the information hosted on these servers is purely public. There is > no *confidential* DNS information here. Thus, there are no privacy concerns. > > In terms of it being a potential DoS target - that it isn't - not > anymore than say, a "dig -t any @ns1.easydns.com vaibhavsharma.com" and > that's because the server runs cpanel which creates only four additional > DNS entries per domain by default (two A records - ftp, localhost and > two CNAME records - mail, www) - and these are standard across all > domains hosted on the server. As you can see, there are not too many > additional RRs in the zone to concern us that the size of a zone > transfer would be substantially larger than that of a "dig -t any" query. Hmmm... point taken. But "dig axfr" is definitely more than "dig -t" any as it pulls out more information than someone like me and a lot others on this list as well as the internet would like to spew out. There are certain best practices that people learn from experience and try to propogate. Its on you to accept them or modify and use according to your situation. I see your situation is different. But it might so happen that tomorrow you might have to include some more RRs in the DNS which you might not want to expose. What will happen then? How much effort will you put in migrating your clients to not to run slave DNS servers? Its your call. I personally believe that after you are sure that all your boxes are patched and perfect, you can always introduce the thin "security by obscurity" layer which never harms you at that level. > Why do we do it? Because some clients want to run in-house slave DNSs > and we don't want to stop them from doing so. Isn't that the problem you > had with XO? Yup, and we chose to find a permanent future proof solution for it. We have a lot of RRs which we dont want anyone to know about to start with. > One might argue that allowing un-authorized zone transfers doesn't leave > you with a warm fuzzy secure feeling. But as far as I can see, there is > no logical reason to not to allow these zone transfers. Point taken. I see this as the telnet vs. ssh issue. Telnet in itself does not pose any threat. Its the medium which it uses is the problem. If you run telnet over an encrypted link to another network which is purely switched, the chances of someone sniffing you are lesser than running telnet over a barebone link. Its still risky. Its your call as to how you want to use it. -- VaibhaV http://vsharma.net ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click _______________________________________________ linux-india-help mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/linux-india-help
