A list of issues present in lexicon

I’ll create a list of issues that I’ve come across.

• Issue with update_record mentioned in #200
• No TTL implementation in some providers
• No method to specify accepted value of TTL by different providers
• No policy to handle illegal TTL value in providers
• Unpredictable provider behavior in create_record, list_record, update_record and delete_record
• No easier way to specify advanced options in case of MX, SRV, etc records
• No test to ensure autopagination is enabled when retrieving domain/record lists. (test with large number of domains & records, approx 100?)
• Tests needed for delegated domains and delegated accounts (provide specific suites?)
• we do not specify which Record Types are supported
• Should lexicon wrap/provide comprehensive list of custom error types for error handling downstream?
• SPEC should specify that records should be autopaginated when possible.

TTL Issue

Providers should be able to tell the user about the range/list of TTL values accepted by it. A policy should be defined on how to handle invalid TTL values supplied by the user.

Unpredictable behavior

Different provider implementations behave differently in certain situations at the moment. The behavior for the methods create_record, list_record, update_record and delete_record should be specified for most/all possible situations. This includes record sets and the like.

Easier reading of advanced options

This included TTL and extra options that MX,SRV, etc records require. Instead of self.options.get, we could try passing these in an argument if possible.

---

I’ll update this as I come across other issues.

---

Edited by @analogj to add additional issues.

[trinopoty]

As far as I can see, most providers will just delete all the existing records when you call delete_record() with no arguments. It looks extremely dangerous.

Looks like my linode providers are guilty of this too.

[jvanasco]

A lot of the exceptions raised are stock Python exceptions. It would make sense to take the approach SqlAlchemy does - a set of custom lexicon exceptions are created, and then underlying provider exceptions are mapped to them or raised as needed.

Using the TTL issue above, we might see:

class LexiconError(Exception):
      pass

class InvalidTTL(LexiconError):
      pass

If the provider raises a TTL error (or the logic demands one is raised), then InvalidTTL is invoked (stashing the original exception if needed).

People would then be able to switch DNS providers and not have to adapt their code.