DNS2db is no longer supported and has been replaced by the superior PacketQ. PacketQ is much faster and no longer relies on Sqlite. Go to https://github.com/dotse/packetq/ for more information. The information and source on this page is provided for historical reasons.
Storing all information in dns packet may not be necessary in all cases. Fields should be labeled and options on command line could be:
EXAMPLE# dns2sqlite --fields CTQ (This would store only Client,timestamp and Qname in database)
Sql queries should contain start and stop time, this can be used to select smaller time intervals in a database and also to verify that the correct database is beeing used.
Geographic and logical graphs showing where queries are coming from are useful in many ways. When deciding where to deploy new sites or if nodes are getting traffic from the correct region. It also is a nice thing to have in presentations ;)
Investigate if its feasible to create a mechanism that only samples a fraction of the packets once the packet frequency reaches a certain threshold in order to improve performance and keep the database size manageable.
This should include information about dropped packets to be able to create correct statistics.
Graph function to show distribution of:
Query type, packet size, EDNS0 usage etc.
protokoll (tcp/udp)
ipv4/ipv6
Procentage malformed packages
Investigate if it would be possible to create custom graphs from the GUI
Functionality to run configurable sql queries on newly created databases and output into rrd database or similar. Useful for custom graphs or other needs.
Add option to configure if src/dst IP should be anonymized. One suggestion is to not store the last octet. (replace with 0). Naturally this should include both queries and replies.
When having multiple listener interfaces and/or multiple TLD's to collect there need to be support in the config files and start scripts to handle this.