Dave Crocker wrote:
I keep waiting for proponents of this 'feature' to solicit technical
review from independent DNS and security experts, for assessing the
likely benefit as balanced against the likely cost.
I have been soliciting technical review from the DNS folks, literally,
for years, on this and prior iterations. I recall quite clearly a
lengthy discussion I had with Peter Koch at IETF 65 in Dallas just over
two years ago. I have been less concerned with independent security
review, since we are in that area and I expect that will happen with the
specification as a whole, not just this aspect of it.
The requirement to publish large numbers of ADSP records is a barrier
to its widespread adoption
That's a view I do not recall seeing phrased quite that way before.
It's nicely succinct and pragmatic. The only question is where is its
basis and, again, the broad support for the assessment that
substantiates it?
For example, John has provided some counter-arguments suggesting that
the actual, incremental effort to deal with a large number of
parallel, related domains -- for this particular RR -- is not all that
high, particularly in light of the core requirement for change to
tools, needed to support even only one name and record. In addition,
I haven't seen an analysis that explains who all these affected domain
name owners are likely to be. In other words, to be a serious barrier
to adoption, it must be a serious barrier and it must affect a
significant portion of potential adopters. Where is the analysis that
demonstrates this? Where is the groundswell of their calling for this
feature?
I don't see an analysis for John's assertion either.
broad coverage for domains. This can be addressed with tools, but
the requirement to add tooling to achieve good ADSP coverage is also
a deployment barrier.
As John noted, there is already a requirement for modifying tools, in
order to support ADSP.
Not DNS tools. The requirement to modify DNS tools to achieve broad
coverage would be an additional requirement.
Similar concerns led the WG to the use of TXT records rather than a
new RR.
Not really. The infrastructure barrier to support of a new RR exists
with both those who create the record as well as those access it.
The barrier for ADSP is only with those who create the record. Very,
very different dynamic.
Agree that ADSP requires changes only on the publication side. I still
believe that this introduces a significant barrier.
There are a lot of DNS management tools out there that would need
to change in order to publish the necessary ADSP records, and this
would take considerable time.
They already need to change, to support one record (for one domain.)
How is there something fundamentally worse about having to support many?
The tools don't need to change; the additional TXT record for ADSP can
just be published independently using existing tools.
We have two approaches to this problem, one approach which requires more
effort on the part of ADSP publishers (either manual publication of
additional records or deployment of new DNS tools), and one approach
that requires more effort on the part of ADSP users, although that
effort is largely contained within the software implementing ADSP and
transparent to the deployer. Let's just treat this as an engineering
tradeoff.
I'm rather surprised this has become such an issue for you and John
since this same approach is used in draft-levine-asp-00, which John
edited and on which you collaborated.
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html