mirror of
https://github.com/abh/geodns.git
synced 2026-04-27 03:45:53 +03:00
[GH-ISSUE #108] TXT records of length more than 255 chars #74
Labels
No labels
bug
bug
enhancement
pull-request
question
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/geodns#74
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @AnoopAlias on GitHub (Apr 24, 2018).
Original GitHub issue: https://github.com/abh/geodns/issues/108
geoDNS does not support txt records with more than 255 char . But I am facing issues in splitting up a very big DKIM record .
xyz: { "txt" : [" firstpartof string","secondpart"]}
This seems to work and geoDNS provide the 2 records in query , but the DKIM is shown as invalid
Is there a way around to add such DKIM record, all the notes I have read say ..if we just pass the 2 records, the client DKIM checker must concatenate and use it
https://kb.isc.org/article/AA-00356/0/Can-I-have-a-TXT-or-SPF-record-longer-than-255-characters.html
@abh commented on GitHub (Apr 24, 2018):
What does bind, nsd or PowerDNS do in this case?
@AnoopAlias commented on GitHub (Apr 24, 2018):
@abh
Following is binds response from dig tool
The entry in binds DB file is as follows
I tried to split this in geoDNS and it is providing 2 response when queried but doesn't seem to be valid. Online DKIM tester tools all return errors.
If the TXT record is given in entire, geoDNS does not provide response and the log says the 255-byte length exceeded
Thanks a bunch for looking into this
@AnoopAlias commented on GitHub (Apr 24, 2018):
I tried recommendations here:
https://serverfault.com/questions/255580/how-do-i-enter-a-strong-long-dkim-key-into-dns
http://hack.limbicmedia.ca/how-to-split-dns-dkim-records-properly/
@abh commented on GitHub (Apr 24, 2018):
Hm. My best guess is that GeoDNS randomizes the order. The easiest fix is probably to teach it to split long txt records and preserve the order in that case.
@AnoopAlias commented on GitHub (Apr 24, 2018):
@abh - geoDNS automatically handling the long TXT record would be fabulous.