Re: Problems with spf testsuite and dns specification

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stuart D. Gathman wrote:
> On Sat, 16 Jun 2007, Stefano Bagnara wrote:
> > So this lead to inconsistent result when someone publishes multiple
> > identical records: you cannot tell if users will receive PermError or
> > they will accept it... IMHO unpredictable result is bad for a
>
> Publishing multiple SPF records is forbidden by rfc4408, whether they
> are identical or not.  The effect of your issue is that often
> an implementation can't tell that multiple records were published
> so as to return the required PermError.  That is the only reason that
> an alternate result would be allowed in the test suite - because with
> live DNS, you can't tell whether a cache combined identical records.
> Ideally, you would return a Permerror because multiple records are
> forbidden by the RFC, but ideals are not always attainable attainable in
> practice.

I am against allowing multiple results for the "multispf{1,2}" test cases.  
As I said, I'd rather resolve the issue by turning the "multiple identical 
records" into "multiple differing records" as follows:

- --- rfc4408-tests.yml   (revision 89)
+++ rfc4408-tests.yml   (working copy)
@@ -272,10 +272,10 @@
     - TXT:  V=sPf1 +all
   example7.com:
     - SPF:  v=spf1 -all
- -    - SPF:  v=spf1 -all
+    - SPF:  v=spf1 +all
   example8.com:
     - SPF:  v=spf1 -all
- -    - SPF:  v=spf1 -all
+    - SPF:  v=spf1 +all
     - TXT:  v=spf1 +all
   example9.com:
     - SPF:  v=SpF1 ~all

That would nicely continue to test for RFC 4408 4.5/6 while avoiding to 
accidentally test for RFC 2181 5/1.

Stuart, do you see a problem with this approach?

> That is why I would like to tag tests for liveDNS vs stubbed resolver.
> The stubbed resolver can test for the correct result when multiple
> identical records are in fact passed through.

I don't see that as a good idea.  Stub resolvers should always try to 
conform to the same RFCs as live resolvers, and any ambiguities in those 
RFCs must be considered legal by the RFC 4408 test suite, i.e., it must 
NOT test them.

> Just because the DNS you are testing with happens to combine them,
> doesn't mean that in production you won't run into a cache that doesn't.

So what?

> The inconsistency is a red herring.  You could publish multiple
> non-identical records with differing TTL and get a similar inconsistency
> where resolvers could see either or both depending on timing.

That's true.  But it still doesn't mean that the RFC 4408 test suite 
should, implicitly or explicitly, test for compliance with some "should" 
in RFC 2181.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGdDNkwL7PKlBZWjsRArvbAJ9KI6s14t5djbuCftacHM/iqtLhSACg2DY6
yWB8pLZZ+XsWcV9YB3oAPyk=
=1Py3
-----END PGP SIGNATURE-----

-------------------------------------------
-----------------------------------------------------------------------
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to http://v2.listbox.com/member/?member_id=6959932&user_secret=62b4c45f
Powered by Listbox: http://www.listbox.com