ietf
[Top] [All Lists]

Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE

2013-05-02 09:53:48
And here we come to a conflict between what we as a community would
like, versus what the market decides.  This leads to a few questions:

1.  Do we have to make a decision at any point from a protocol
standpoint that the market has in fact made a decision?  I ask this
question because I performed an experiment along these lines some years
ago, finding quite a number of proposed standards that were nowhere to
be seen on the 'net.  Earlier we saw discussion about simplifying code
bases, but generally a developer  makes that decision, not the IETF.

2.  What are the timescales involved?  Is it fair to treat IPv6 the same
as a new DHCP option or a DNS RR?  What are the parameters?  One could
reasonably argue with the benefit of hindsight that there was no way we
would see IPv6 adoption until we ran out of IPv4 addresses.  For DNS
RRs, there are some common inhibitors.

3.  What can be done by the IETF to improve likelihood of adoption, and
conversely what should we not bang our heads against?

Eliot



On 5/1/13 7:03 AM, Murray S. Kucherawy wrote:
On Tue, Apr 30, 2013 at 12:52 PM, David Conrad <drc(_at_)virtualized(_dot_)org
<mailto:drc(_at_)virtualized(_dot_)org>> wrote:

    SPF using TXT and hence, SPFBIS forces the uniquification of the
    DNS response into the application instead of in the DNS library.
    Given the ordering of individual TXT RRs within an RRset is not
    guaranteed, I suspect the chances that every application is going
    to do that parsing correctly is relatively low (btw, the example
    in 3.3 in spfbis-14 is a bit misleading: assuming "second string"
    is in a separate TXT RR (which is implied), the concatenation
    might be "second stringv=spf1 ..... first").  The more interesting
    bit is if/when another protocol uses TXT at the same ownername.


Yes, I understand all of that, and I've written code to deal with it. 
It's not rocket science.
 

    The RR has been allocated and it is supported in most DNS servers
    and resolver libraries in one form or another.  Provisioning
    systems take much longer, but that isn't surprising and shouldn't
    be an argument to deprecate (if it is, we might as well close the
    RRtype registry for new entries).


We're not only talking about provisioning systems here.  We're also
talking about interference with queries and replies at the DNS
protocol level.  The survey work done for RFC6686 showed that
something on the order of thousands of domains in the sample set
suffered from this.  It is a very real issue for a deployed protocol.
 

    In the past, the IETF used to make decisions based on long-term
    technical/architectural correctness, even in the face of pragmatic
    complications (e.g., the choice to mandate strong crypto despite
    real world challenges some companies faced in exporting that
    crypto in products). In this particular case, there seems to be an
    argument to explicitly disallow the long-term
    technically/architecturally correct approach because some folks
    choose not to add an RR to their zone files or support that RR in
    their provisioning systems.  As I said in DNSEXT, this seems like
    the wrong approach to me.


All things being equal, I would agree with you.  And if SPF were
starting anew today, I suspect I might have a different opinion.  The
question, then, is the weight of the mitigating circumstances, which
obviously the two communities evaluate quite differently.

-MSK