7

What is the purpose of the TXT record in (for example) the root Microsoft.com zone? I don't see any reasonable tie into SPF, SenderID, DomainKeys, or even TLS-OBC or DANE for TLS.

microsoft.com IN TXT FbUF6DbkE+Aw1/wi9xgDi8KVrIIZus5v8L6tbIQZkGrQ/rVQKJi8CjQbBtWtE64ey4NJJwj5J65PIggVYNabdQ==

Community
  • 1
makerofthings7
  • 8,821
  • 28
  • 115
  • 196
  • Seeig as it is there dns record, they could use that for anything they please, huh? – uSlackr Jun 18 '12 at 01:27
  • @uSlackr True, but I doubt they would run experiments on a production domain like that. There has to be a public RFC out there somewhere, because doing things like this may break other experimental RFCs. – makerofthings7 Jun 18 '12 at 01:52
  • @makerofthings7 Why would a `TXT` record break anything? It's a base-64 encode of a 64 byte chunk of.. something. A SHA512 hash of something is my best guess. – Shane Madden Jun 18 '12 at 02:05
  • @ShaneMadden - There are many experimental RFCs that look at DNS and make use out of txt records that affect email, HTTPS verification, and more. The RFC "MUST" in most of them is to ignore records without the proper prefix or if the data isn't parsable. This may not really cause a negative impact, but new functionality should go through the IAB or IETF. If this is new functionality, I can't find it... – makerofthings7 Jun 18 '12 at 02:17
  • 1
    They also have a standard SPF record along side of the base64-encoded string, so not breaking anything. Decoding the encoded record doesn't really give me anything meaningful, just some binary data that they could be using for any number of purposes. – Justin Scott Jun 18 '12 at 02:17
  • 2
    In regards to the "Too localized" reason, it seems this is related to a new, broadly available feature that is available to any Exchange customer. We will be seeing much more of these in the future, so I voted to reopen. – makerofthings7 Jun 18 '12 at 20:41

2 Answers2

8

It looks like an Exchange federation "proof record". More information here: http://www.expta.com/2011/07/how-to-configure-exchange-2010-sp1.html

Domain Proof records are TXT records created in your domain's external DNS zone. The purpose of these TXT records is to prove the identity of your domain for the trust with the Microsoft Federated Gateway (MFG) server.

Run the following cmdlets from the Exchange Management Shell (EMS) to generate the domain proof values:

Get-FederatedDomainProof -DomainName exchangedelegation.companyabc.com

Get-FederatedDomainProof -DomainName companyabc.com

Repeat the second cmdlet for additional SMTP domains you want to federate, if any.

Each cmdlet will generate a unique Proof value, based on a hash using the Exchange Delegation Federation self-signed certificate. If the MFG can read the domain proof value in an external DNS record and it matches the calculated value, it proves domain ownership and validates the trust.

MS documentation: http://technet.microsoft.com/en-us/library/dd335047.aspx

Anyway, we can use TXT records for anything, or at least that's what I understand reading "The semantics of the text depends on the domain where it is found." (RFC 1035)

Shrout1
  • 343
  • 2
  • 6
  • 18
MV.
  • 766
  • 7
  • 11
  • I tried running the command `Get-FederationInformation` for Microsoft.com and it failed then genereated a Watson. Exchange 2010 SP1 RU6, and SP2 RU2 – makerofthings7 Jun 18 '12 at 14:11
2

In fact, there are several TXT records. If you run dig microsoft.com TXT:

;; ANSWER SECTION:
microsoft.com.      3600    IN  TXT "FbUF6DbkE+Aw1/wi9xgDi8KVrIIZus5v8L6tbIQZkGrQ/rVQKJi8CjQbBtWtE64ey4NJJwj5J65PIggVYNabdQ=="
microsoft.com.      3600    IN  TXT "v=spf1 include:_spf-a.microsoft.com include:_spf-b.microsoft.com include:_spf-c.microsoft.com include:_spf-ssg-a.microsoft.com ip4:131.107.115.215 ip4:131.107.115.214 ip4:205.248.106.64 ip4:205.248.106.30 ip4:205.248.106.32 ~all"

So there is standart SPF record available while an additional header that may have custom purpose e.g. anything the developers/domain managers wanted.

jollyroger
  • 1,650
  • 11
  • 19