Re: dig -t txt output variation
On 3/9/2012 5:42 PM, Mark Andrews wrote: In message, "M. Meadows" writes: 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=3Dspf1 a mx ip4:207.250.79.101 ip4:207.67.98.192/27 ip4:72.18.216.98 inc= lude:cust-spf.exacttarget.com include:salesforce.com include:message1-spf-i= nc.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 includ= e:cust-senderid.exacttarget.com include:salesforce.com include:message1-sen= derid-inc.exacttarget.com include:hotels-senderid-inc.exacttarget.com ip4:2= 06.246.157.1 -all" And=20 "spf2.0/pra ip4:207.250.79.101 ip4:207.67.98.192/27 ip4:72.18.216.98 includ= e:cust-senderid.exacttarget.com include:salesforce.com include:message1-sen= derid-inc.exacttarget.com include:hotels-senderid-inc.exacttarget.com ip4:2= 06.246.157.1 -all" "v=3Dspf1 a mx ip4:207.250.79.101 ip4:207.67.98.192/27 ip4:72.18.216.98 inc= lude:cust-spf.exacttarget.com include:salesforce.com include:message1-spf-i= nc.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 ... sometim= es it's second. We are aware of at least one application that sees the spf2.0 (if it's firs= t) and returns a neutral result for SPF testing. If the spf1 is first in th= e feedback it gets a pass for SPF.=20 The application is broken. True, and the breakage goes very deep indeed. "spf2.0" isn't SPF at all; it's Sender ID, a very different animal from SPF. See http://www.openspf.org/SPF_vs_Sender_ID - Kevin ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dig -t txt output variation
In message , "M. Meadows" writes: > 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=3Dspf1 a mx ip4:207.250.79.101 ip4:207.67.98.192/27 ip4:72.18.216.98 inc= > lude:cust-spf.exacttarget.com include:salesforce.com include:message1-spf-i= > nc.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 includ= > e:cust-senderid.exacttarget.com include:salesforce.com include:message1-sen= > derid-inc.exacttarget.com include:hotels-senderid-inc.exacttarget.com ip4:2= > 06.246.157.1 -all" > > > And=20 > > "spf2.0/pra ip4:207.250.79.101 ip4:207.67.98.192/27 ip4:72.18.216.98 includ= > e:cust-senderid.exacttarget.com include:salesforce.com include:message1-sen= > derid-inc.exacttarget.com include:hotels-senderid-inc.exacttarget.com ip4:2= > 06.246.157.1 -all" > "v=3Dspf1 a mx ip4:207.250.79.101 ip4:207.67.98.192/27 ip4:72.18.216.98 inc= > lude:cust-spf.exacttarget.com include:salesforce.com include:message1-spf-i= > nc.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 ... sometim= > es it's second. > > We are aware of at least one application that sees the spf2.0 (if it's firs= > t) and returns a neutral result for SPF testing. If the spf1 is first in th= > e feedback it gets a pass for SPF.=20 The application is broken. > ns2.exacttarget.com is running BIND 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2. > > Is this a BIND bug?=20 No. The DNS does not preserve record order. This is documented in RFC 1035. > Thanks=2C > Martin Meadows -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dig -t txt output variation
Alan wrote on 03/09/2012 02:38:25 PM: > Don't base anything on RRset ordering. > > Be sure that the application is able to handle the "random" order -- you > never know who owns the intermediate caching servers, so you will never > know the order even if you "fix" it on the authoritative. That prompted me to look at the original post... The owner of the domain needs to reconcile the two records (including included records) and verify all allowed servers are listed. It's more of an email/spam filtering issue than a BIND problem. Confidentiality Notice: This electronic message and any attachments may contain confidential or privileged information, and is intended only for the individual or entity identified above as the addressee. If you are not the addressee (or the employee or agent responsible to deliver it to the addressee), or if this message has been addressed to you in error, you are hereby notified that you may not copy, forward, disclose or use any part of this message or any attachments. Please notify the sender immediately by return e-mail or telephone and delete this message from your system. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dig -t txt output variation
On 3/9/2012 2:24 PM, M. Meadows wrote: > Thanks to both of you for your feedback. > I see the rrset ordering explanation in the arm. > Good information. Don't base anything on RRset ordering. Be sure that the application is able to handle the "random" order -- you never know who owns the intermediate caching servers, so you will never know the order even if you "fix" it on the authoritative. AlanC -- a...@clegg.com | 1.919.355.8851 signature.asc Description: OpenPGP digital signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: dig -t txt output variation
Thanks to both of you for your feedback. I see the rrset ordering explanation in the arm. Good information. > To: sun-g...@live.com > CC: bind-users@lists.isc.org > Subject: Re: dig -t txt output variation > From: wbr...@e1b.org > Date: Fri, 9 Mar 2012 13:54:47 -0500 > > sun-guru wrote on 03/09/2012 01:45:33 PM: > > > > Is this a BIND bug? > > Check ARM for RRSet Ordering. > > > > Confidentiality Notice: > This electronic message and any attachments may contain confidential or > privileged information, and is intended only for the individual or entity > identified above as the addressee. If you are not the addressee (or the > employee or agent responsible to deliver it to the addressee), or if this > message has been addressed to you in error, you are hereby notified that > you may not copy, forward, disclose or use any part of this message or any > attachments. Please notify the sender immediately by return e-mail or > telephone and delete this message from your system. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dig -t txt output variation
sun-guru wrote on 03/09/2012 01:45:33 PM: > Is this a BIND bug? Check ARM for RRSet Ordering. Confidentiality Notice: This electronic message and any attachments may contain confidential or privileged information, and is intended only for the individual or entity identified above as the addressee. If you are not the addressee (or the employee or agent responsible to deliver it to the addressee), or if this message has been addressed to you in error, you are hereby notified that you may not copy, forward, disclose or use any part of this message or any attachments. Please notify the sender immediately by return e-mail or telephone and delete this message from your system. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
dig -t txt output variation
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 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
