While watching some parked domains, I recently observed one which has a
TXT field containing some crypto value, something like a ssh key/RSA 512
or 1024 output (only the crypto part 'cvxvcvcxvcxv=' ).
For now, I have referenced the following usage of TXT
- DNS Server information/version
- SPF (format like "v=spf1 a mx -all") [1]
- DKIM (format like "k=rsa\; t=y\; p=MIGfMA0GCSqGSIb3 [...]
YA+OwSMWQIDAQAB", but always in _domainkey.<domain>) [2]
- not DNSSec as I supposed first (only DNSKEY, RR, RSIG, NSEC, not TXT)
Does someone know at what kind of usage this kind of value could
correspond ? (even if, nearly everything is possible)
If the TXT data is a large wodge which changes, and/or there are
fluctuating interesting labels within the zone, then it isn't parked
but is being used for IP-over-DNS tunneling.
Dkim , SPF ,and Domainkey are sender authentication methods for email system. Which use Public Key Cryptography.
The mail server apends signiture to every outgoing message using private key. the recepient mail server to verify needs the public key which placed in the sender DNS server.
DKIM and Domainkeys use public key cryptography to authenticate signature sources used for signing at least email From headers and signature headers.
However, SPF uses chained IP address lists to establish source authorization, but not authentication. Since outbound MTAs might handle multiple domains, it would be incorrect to assume authorization implies authentication and to expect email domains have been previously verified by the source. For example, Sender-ID might use the same SPF record, but this expects Purported Responsible Addresses (PRA) rather than Mail Froms have been verified. On the other hand, SPF was designed to ignore the PRA, and neither section 2.2 or 2.4 of RFC4408 imposes prior verification demands on Mail From or HELO, which would conflict with normal forwarding. :^(
Both DKIM and Domainkey share the same domain label of "<domain-holding-key>._domainkey.<admin-domain>", whereas the first SPF record in a chain would be accessed without any prefix label. While bad actors could use either scheme to obscure encoded DNS tunnel traffic, ascertaining abnormal use would be especially difficult whenever the first SPF records in a chain includes local-part encoding for subsequent SPF record prefixes. :^(