Re: Re: Problems with spf testsuite and dns specification

Stuart D. Gathman ha scritto:
> On Sat, 16 Jun 2007, Julian Mehnle wrote:
> 
>>> 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.
>> No, it isn't.  Testing it like the test suite currently does means 
>> implicitly testing for obeyance or non-obeyance of a "should" in RFC 2181.  
>> A resolver (be it live or stub) may very well combine multiple identical 
>> records into a single one and NOT be incompliant with RFC 4408!  Or are 
>> you saying that using a DNS resolver/cache that conforms to RFC 2181 5/1 
>> makes an SPF implementation _incompliant_ with RFC 4408?
>>
>>> The more unlikely, the more important to test for it.
>> This has nothing to do with probabilities.  Both combining and not 
>> combining multiple identical records is legal according to RFC 2181.
> 
> That is irrelevant.  What is relevant is that if you see multiple
> records, whether identical or not, the 4408 result is PermError.
> That 4408 compliance is what we are testing for.  The 2181 behaviour
> makes testing trickier when using live DNS, but otherwise is
> unrelated.

But rfc2181 let anyone working with DNS RRs to compact identical
records. So if I compact them just before applying SPF rules then I will
process the record instead of returning the PermError.

>> But it is obviously relative to RFC 2181 5/1.  _Why_ can a stub resolver 
>> (or test suite driver) not conform to RFC 2181 5/1?  I don't see this 
>> written anywhere.  Why would using a combining _live_ resolver be legal, 
>> whereas using a combining _stub_ resolver would not?
> 
> They are both legal.  But 4408 says that when your stub/resolver 
> gives you multiple identical records, the result is PermError.
> The test suite tests for that very nicely in the case of a stub.
> Live DNS is more difficult to test for this case due to 2181 5/1.

As Julien already told, rfc2181 does IMO apply also to stup
implementations of a DNS resolver.
Why should you use a MUST in a specification when the application of
rfc2181 5/1 invalidate at all your MUST in case of multiple identical
records depending on the transport/implementation choices?
Your MUST will only work when no layer accepted to follow a SHOULD in
the dns specification.

Btw, I think I explained well enough the problem. I hope the SPF council
will analyze this and will report an official decision.

> This is a testing problem, NOT a "what does the standard say" problem.
> The reason to allow both results is not because the standard is
> unclear, but because it is too difficult in practice to do the
> test properly with live DNS.  Live DNS testing is valuable because it
> tests more of the whole system, so making some accomodations for it
> is reasonable.  Also, we promised to also support live DNS in the test
> suite goals.

In rfc2181 there is not "Live" concept, so I don't understand why you
keep referring "Live DNS testing".
Again, IMO the problem with the specification is that it requires a
behaviour that is unknown when you publish the duplicated records.
If you publish multiple different records every compliant implementation
will return PermError indipendently from the DNS implementations in the
chain, if you publish a single record every compliant implementation
will analyze the rule, if you publish multiple identical records you
don't know what a compliant implementation will return because you CAN'T
know what dns resolver/caches/server you have there.

It does not make sense at all: if you are simply telling that what is
wrote in the 4408 is like something said by God and cannot be wrong,
then ok, we can skip this discussion at all, otherwise it should be
considered that the rfc4408 may be inappropriate about this OR the
multiple result must be accepted because of rfc2181 5/1.

The intent of rfc2181 is to have multiple identical records to behave as
a single record. If you implement a specification on top of DNS you
cannot change the intents of the underlying transport and so IMO
considering multiple identical RRs as a single one is perfectly VALID
for rfc4408 because it is built on top of rfc2181 and we simply SHOULD
do that. To be strict the testsuite is simply testing that the
implementor did not follow a SHOULD in rfc2181, nothing more: it seems
to enforce a bad practice at all.

As Julian told the test should be changed to show multiple different
records.

Your explanation did not convice me at all: is like I'm building a
specification that uses TCP/IP as a transport and I add a requirement in
my specification to be followed when IP packet retransmission happens.
Packet retransmission should be hidden inside TCP/IP and protocols build
on top of it do never require different behaviour depending on something
that only belongs to TCP/IP. Whether identical RRs SHOULD be considered
as a single RRs and SHOULD be compacted it already clearly stated in
rfc2181, so anything different in rfc4408 is simply invalid.

Please read again rfc2181 5:
"It is meaningless for two records to ever have label, class, type and
 data all equal"

It is MEANINGLESS means that you cannot add meaning to the existence of
multiple identical records. I'm sure rfc4408 does not suggest to ignore
the dns specification.

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