Re: Re: Problems with spf testsuite and dns specification

Stuart D. Gathman ha scritto:
> On Sat, 16 Jun 2007, Julian Mehnle wrote:
> 
>> 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.
> 
> The point is, a live resolver *just might* return multiple identical
> records.  In that case (as unlikely as it may be in practice), rfc4408 says the
> result is PermError.  So this is a legitimate thing to test for.  The
> more unlikely, the more important to test for it.  (More likely bugs will show
> up in operation right away anyhow.)  The fact that jSPF is unable to
> test this scenario is a deficiency in the test setup.  The stub
> resolver has different deficiencies.  No test setup is perfect.

Wait, the problem is not jSPF: in fact we simply found something weird
between DNS specification and SPF specification. We are already able to
test in a mock environment that specific behaviour but IMO it does not
make sense at all!

Why should we care that an implementation will return PermError on
multiple identical records when DNS caches are SUPPOSED to combine them?
I think that an implementation that treat multiple identical records as
a single record would be COMPLIANT because of DNS specification, and
being SPF based on DNS it MUST comply with what DNS states.

In fact we found an issue that probably you don't even tested in
implementation you declared "compliant" because we didn't limit
ourselves to mocked testing but we also created integration testing to
be sure we check also real resolution.

While I'm here I'd like to tell that current jSPF trunk perform SPF
lookups asynchronously and with a SEDA approach, so it should scale
better than other implementation. I still have to create tests for
throughput.

>>> 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?
> 
> So you should produce the rfc mandated result given multiple identical records.

IMO the spec should leverage the underlying DNS "transport", so it
should permit both result. if it was not an errata I would really prefer
to have the SPF spec to require different behaviour on multiple
identical records than multiple different records so to have a
predictable result for a given configuration, but the spec has already
been published and probably it is better to simply warn people about
that issue and let implementation to treat multiple identical records as
a single record (as many resolvers/caches will already do that).

>>> 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.
> 
> The MUST is in RFC 4408.  The only difficulty is that a particular test setup
> has trouble reproducing the multiple identical records scenario.

It is not about test setups. Please try to understand that you can
publish multiple identical records but you can't really predict what the
SPF clients will receive. This is IMO really bad as the SPF spec
currently require different behavior given the resolvers/caches in the
transport layer.

> Now if you feel that RFC 4408 didn't really mean to mandate a permerror
> for multiple records when they are identical (in light of 2181), then we can
> discuss that.  We can also allow both results in the test suite to reflect
> that lack of consensus.

+1

Stefano

-------------------------------------------
-----------------------------------------------------------------------
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