dig -t txt output variation

[M. Meadows]

We've noticed that the following command gets a variable result:

dig -t txt exacttarget.com @ns2.exacttarget.com +short

We get 2 results from this. Seems to be somewhat random. They are:

"v=spf1 a mx ip4:207.250.79.101 ip4:207.67.98.192/27 ip4:72.18.216.98 include:cust-spf.exacttarget.com include:salesforce.com include:message1-spf-inc.exacttarget.com include:hotels-spf-inc.exacttarget.com ip4:206.246.157.1 -all"
"spf2.0/pra ip4:207.250.79.101 ip4:207.67.98.192/27 ip4:72.18.216.98 include:cust-senderid.exacttarget.com include:salesforce.com include:message1-senderid-inc.exacttarget.com include:hotels-senderid-inc.exacttarget.com ip4:206.246.157.1 -all"


And 

"spf2.0/pra ip4:207.250.79.101 ip4:207.67.98.192/27 ip4:72.18.216.98 include:cust-senderid.exacttarget.com include:salesforce.com include:message1-senderid-inc.exacttarget.com include:hotels-senderid-inc.exacttarget.com ip4:206.246.157.1 -all"
"v=spf1 a mx ip4:207.250.79.101 ip4:207.67.98.192/27 ip4:72.18.216.98 include:cust-spf.exacttarget.com include:salesforce.com include:message1-spf-inc.exacttarget.com include:hotels-spf-inc.exacttarget.com ip4:206.246.157.1 -all"


So ... the text output flips. Sometimes the spf1 entry is first ... sometimes it's second.

We are aware of at least one application that sees the spf2.0 (if it's first) and returns a neutral result for SPF testing. If the spf1 is first in the feedback it gets a pass for SPF. 

ns2.exacttarget.com is running BIND 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2.

Is this a BIND bug? 

Thanks,
Martin Meadows



 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20120309/b814a4cc/attachment.html>