What tables will be there.Also as read percentage will be significantly larger than write, is indexing on columns advised? What other precautions are necessary?
For now, I can just think of 1 table containing two columns namely domain and ip address and B+ tree index implemented on both. Is this sufficient?
A simple list of name/address pairs with an index on each would be sufficient if absolutely all you needed to do was lookup one from the other. Unfortunately you will find that the DNS protocol has larger requirements than that so if you intending to interact with the public domain name system you have much more work ahead of you. See http://en.wikipedia.org/wiki/Domain_Name_System for a quick primer and a list of the relevant RFCs (which are essentially the specification you'd be expected to work to as a participant in the public DNS infrastructure (though remember that many features are optional: you may chose to implement an authoritative service only so not need to worry about recursive queries (except knowing the right error response to give when you receive one).
There are a couple of F/OSS DNS servers that use a relational database back-end instead of bind-style zone files, perhaps you could look at their structures as a hint (though if you are building a commercial solution be careful of licensing issues: for instance you might find looking at GPL covered code to be a bad idea if you intend to distribute the results of your project in a non-GPL compatible manner):
MyDNS: http://mydns.bboy.net/
Power DNS: http://en.wikipedia.org/wiki/PowerDNS
