Architecture

Supervision Hierarchy

• ed_sup is the root supervisor
• ed_udp_server accepts incoming queries via UDP
• ed_udp_handler_sup spawns child worker processes to answer queries
• <0.54.0> and <0.55.0> are examples of ed_udp_handler_server instances concurrently working on two DNS requests
• ed_zone_sup is responsible for supervising the zone subsystem
• ed_zone_registry_server contains information about all zones registered with the server
• ed_zone_data_sup supervises the actual zone servers
• <0.53.0> is an example of an ed_zone_data_server (this one serves the sample root zone from the end-to-end tests).
• ed_extension_sup supervises extensions such as the simple_stats_server.

Sample Query and Answer

1. A DNS query is received via UDP and accepted by ed_udp_server
2. ed_udp_server asks ed_udp_handler_sup to spawn a worker ed_udp_handler_server to process the request
3. ed_udp_handler_server decodes the request and calls ed_query_resolver (and any extension resolvers) to answer the query
4. ed_query_resolver asks ed_zone_registry_server for the nearest zone associated with the request
5. if a zone exists ed_query_resolver requests a copy of the zone data from the associated ed_zone_data_server
6. ed_query_resolver answers the query from the zone data, optionally making recursive calls to fetch additional details
7. ed_udp_handler_server encodes the answer data and sends it to the original requestor via UDP.

Notes

This is my first "real" OTP application, so I am not claiming that this architecture is particularly suitable or finalised for that matter. Comments are certainly most welcome.

If you are new to OTP, please take a look at my tutorial here: http://blog.bot.co.za/en/article/349/an-erlang-otp-tutorial-for-beginners. It's become quite popular and I had to constantly refer to it as I built up the app.