Storage plugins previously internally stored Answer types. This was a bit of a waste of space, and moreover was just a bit awkward because the storage plugin needed the zone name and data type to store the data correctly. It also didn't really infer the data type from the request, so any type of data could be stored with any other kind of data as long as it was a valid record (i.e. an MxAnswer could be stored under an "A" record as long as it was well-formed.
This PR seeks to solve that.
Instead of needing to repetitively type the whole Answer object, a la
Supplying the data type that matches the record, with type checking and intellisense.
This PR also adds Lodash as a dependency (for now). It's used in the (newly introduced and swiftly deprecated) trie module. If we choose to remove this module in the future, we may end up choosing to remove Lodash as it's not currently used anywhere else.
On that note, this PR also replaces the default store with a MapStore. The MapStore supersedes the TrieStore as the default in-memory data structure, and provides documentation in the generic Trie data structure to explain why. For clarity, here is a summary:
Tries are an efficient and compact way to store data such as domain names, that may share ancestor labels. However, because of the way DNS records must resolve wildcards to be in spec, they don't actually provide much benefit for this application. Concretely, if a wildcard exists at com -> *, and a user searches for test.example.com, the trie cannot simply return early and skip moving through the entire trie because it encounters a wildcard. There may be an exact match for test.example.com, or a lower (more specific) wildcard match which should be returned instead. Because of this, exact matches are not more performant than a simple map (O(m) for m domain label parts vs O(1)) and they aren't actually faster except in some specific situations (while actually being slower in others).
Maps are also generally simpler to implement, maintain, and test, so we've gone with the MapStore for now.
Storage plugins previously internally stored
Answertypes. This was a bit of a waste of space, and moreover was just a bit awkward because the storage plugin needed the zone name and data type to store the data correctly. It also didn't really infer the data type from the request, so any type of data could be stored with any other kind of data as long as it was a valid record (i.e. an MxAnswer could be stored under an "A" record as long as it was well-formed.This PR seeks to solve that.
Instead of needing to repetitively type the whole Answer object, a la
You can now simply do
Supplying the data type that matches the record, with type checking and intellisense.
This PR also adds Lodash as a dependency (for now). It's used in the (newly introduced and swiftly deprecated) trie module. If we choose to remove this module in the future, we may end up choosing to remove Lodash as it's not currently used anywhere else.
On that note, this PR also replaces the default store with a MapStore. The MapStore supersedes the TrieStore as the default in-memory data structure, and provides documentation in the generic Trie data structure to explain why. For clarity, here is a summary:
Tries are an efficient and compact way to store data such as domain names, that may share ancestor labels. However, because of the way DNS records must resolve wildcards to be in spec, they don't actually provide much benefit for this application. Concretely, if a wildcard exists at
com -> *, and a user searches fortest.example.com, the trie cannot simply return early and skip moving through the entire trie because it encounters a wildcard. There may be an exact match fortest.example.com, or a lower (more specific) wildcard match which should be returned instead. Because of this, exact matches are not more performant than a simple map (O(m) for m domain label parts vs O(1)) and they aren't actually faster except in some specific situations (while actually being slower in others).Maps are also generally simpler to implement, maintain, and test, so we've gone with the MapStore for now.