You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Some domains have multiple TXT records. Although this is not allowed in the specification (link), it would still be good to handle it.
TXT RRs MUST be unique for a particular selector name; that is, if there are multiple records in an RRset, the results are undefined.
The easiest option is probably to just add them all - any faulty ones will be handled by #85
Alternatively, parse them and pick those that are valid DKIM TVL and have valid ASN1 DER encoded public key in p=.
At the moment, we have just picked the first record. But there seem to be a few cases in the archive (could be as much as 1%), for which we have actually missed the "real" key because the record with the real key was preceded by some invalid value. They are easy to find though, so we can process them and add any extra selectors.
One example:
dig default._domainkey.ictwaarborg.nl txt +short returns 2 records:
Record 1 (note the underline in _p=):
Observation:
Some domains have divided the data in several DNS records (instead of several partial strings of the same record, which is the normal way)
In the example below, the data is divided in 3 records, which are returned in a random order. To handle cases like this, we would need to try to concatenate together in all possible combinations and see which combination gives a valid key. Maybe for the time being, this is not worth the extra complexity, also given that this does not follow the DKIM specification.
Some domains have multiple TXT records. Although this is not allowed in the specification (link), it would still be good to handle it.
The easiest option is probably to just add them all - any faulty ones will be handled by #85
Alternatively, parse them and pick those that are valid DKIM TVL and have valid ASN1 DER encoded public key in p=.
At the moment, we have just picked the first record. But there seem to be a few cases in the archive (could be as much as 1%), for which we have actually missed the "real" key because the record with the real key was preceded by some invalid value. They are easy to find though, so we can process them and add any extra selectors.
One example:
dig default._domainkey.ictwaarborg.nl txt +short
returns 2 records:Record 1 (note the underline in
_p=
):Record 2 (probably the correct one):
Another example:
The text was updated successfully, but these errors were encountered: