On 28 aug 2013, at 14:24, S Moonesamy <sm+ietf(_at_)elandsys(_dot_)com> wrote:
It's difficult, some might say impossible, to get agreement on
draft-ietf-spfbis-4408bis. I would like to ask each of you, and anyone else,
to provide your opinion about the following:
RFC 5507 primarily raises three concerns about TXT records:
As the main editor of RFC5507 I might have a different view of what RFC 5507
says than others...but...that said, here are my comments.
RFC5507 first of all lists a number of prerequisites that should always be
taken into account when extending the functionality of the domain name system.
The intention was that the alternatives in section 3 where to be taken
seriously as a way to solve the main problem, that the client when querying the
DNS should be able to do a selection of what records the client needs by
including the selector inside the triple {owner, type, class}. To solve that,
there are a number of possible solutions.
Then there are specific discussions about the TXT resource record as you say,
and those issues are included in the three issues you list below.
1. The data in TXT is unstructured and subject to misinterpretation by other
applications.
The data is in fact structured, in the form of a series of strings, each one of
them max 255 bytes long. But you are correct in the fact that RFC5507 does not
go into those details. But, the SPF specification do not use this structuring
that do exist, although it do (which is good) explicitly say that multiple such
strings should first be concatenated before progressing with parsing the SPF
record.
There is though no registry for the various formal uses of TXT records, and
because of that there might be confusion among the various uses. Note that I am
not saying that it is harder to write parsers, as for example an attacker can
intentionally try to feed whatever data into whatever format a resource record
do have. The parser must be robust regardless of the format.
Whether the SPF format itself is too complicated (I see various theoretical
calculations on hundreds of RRSets be needed to get one SPF resolution correct)
or not, that is *NOT* something I am evaluating here.
2. Wildcard issues.
Correct.
3. Size issues.
Correct, in two ways. It explicitly talks about the size of the TXT record, but
RFC5507 also talks about the size of a Resource Record Set, which is what is
returned to the client that queries. One also have to think about the size of
the transaction, and specifically the complete response sent from the server,
that contain multiple resource record sets.
I.e. we have:
3.1. The size limit 255 bytes for one string in the TXT record
3.2. The size of one TXT resource record (because the data is stored as text
and not binary)
3.3. The size of a resource record set with the same owner, type and class
3.4. The size of a response to a query for a specific owner, type and class
The draft addresses (3) by discussing size considerations, and tangentially
addresses (1) in Section 3.4.
If we take the size issue first (3) it sort of looks at all of (3.1)-(3.4)
above but not in a very clear way. The discussion in specifically section 3.4
is very confusing. It mixes up DNS response size with UDP payload size with MTU
size. Because the text is not clear in its assumptions, it is very hard to say
whether one agree or not with the conclusions. In turn, that leads to it being
even harder to decide whether one agree or not with the conclusions on being as
backward compatible with "old implementations" as is claimed being a necessity.
I.e. there are a lot of claims in 3.4 based on unclear assumptions.
Further, if 3.4 is looking at the full response size, then it should also look
at the response size in a similar way that has been done for DNSSEC, where also
DNSSEC material is part of the response size (but then of course EDNS0 is in
use).
Regarding the structure of the data, (1) above, it touches on it in section 3.3
and 3.4, but in reality the structure is really up to the parser and I think
that is for this discussion sort of a non-issue.
I am more worried over (3.3) above, which is the core of RFC5507 that is really
a problem, specifically together with the lack of a registry for the selectors
that is part of the RDATA. If we compare with the other experience we do have,
NAPTR, where this problem is a fact, we at least have a registry for the
selectors so that we do know there will not be any collisions.
Yes, I do know SPF syntax do have an ability to refer to a record with a
prefix, but that does not really help as the large RRSet is sent back in the
response already to the first query.
I would like to ask everyone not to turn this into a debate by not discussing
about the opinion stated by someone else.
Regards,
S. Moonesamy (as document shepherd)
Patrik
signature.asc
Description: Message signed with OpenPGP using GPGMail