Improve handling of records with missing/invalid key
Opened this issue · 0 comments
When we store the results from the DNS lookup, we store also records that don't have a key, for example when p=
is followed by an empty string, when there is no p=
, or when the result from the DNS server contains junk data. It's just a minority of all the records, but it can still be misleading and not the best developer experience when you expect a key, but you don't get a key, but an invalid DNS TXT record.
There are 4 categories of records:
- Regular values. A non-empty, valid p=, e.g.
k=rsa; p=MIGfMA0GCSq...
- Empty p= value, such as
k=rsa; p=
. An empty p value is allowed by the specification (https://datatracker.ietf.org/doc/html/rfc6376#section-3.6.1), and it means that the key has been revoked. - Invalid non-DKIM compatible data. (Example: s1._domainkey.mg.premiumbanker.com returns
s1.domainkey.u7679196.wl197.sendgrid.net
) - Invalid data that actually does include a key. (Example:
dig mandrill._domainkey.argentcu.org txt +short
returns"v=DKIM1;\194\160k=rsa;\194\160p=MIGfMA0GCSqGSIb3DQEBAQUAA4GN...;"
)
Some possible solutions:
Alternative 1:
Keep empty and invalid records in the database, but don't include them in the response from api/key
endpoint. (If necessary, we could add some options: include_revoked
, include_invalid
).
Alternative 2:
Remove empty and invalid records from the database, (and make sure to not add any new).
Alternative 3:
No code change. Just update the documentation of the API, and explain what can be returned.