Patrick, I agree 100% with your well stated, outlined functional and
technical position, which is why I want to get a feel for what is the
current mindset which seems to be one of simplicity and not one that
no longer relates or less concern with the original ideals of using
specific RR types optimizes DNS large scale application usage. Yes, I
don't think we should give up.
The specific case is with SPF and it 2006 fast track WG consensus to
include a registration for a new type 99 SPF type. It help appease
many of the DNS concerns and perhaps would help with the IETF politics
(endorsement). That is how I saw it.
Yet, giving the practically realities, our own implementation disabled
the SPF type lookup, and like many I believe think, it would be a
useless wasted call.
Now a new BIS effort has started and to my surprise the original
environment migration path of first getting clients to support types,
the data evidence have shown that original intent right on, a short
term hiccups and expectation for the necessity of getting DNS servers
to be updated and a long term expectation that the new RR type would
be eventually be dominate and successful. In the mean time, some
initial overhead would be expected.
But what has happen is that its now a "Who's Who" using it criteria as
a measuring stick to abandon the new type. I am sure there will be
those who say that is not the criteria and thats find, I understand it.
It is excludes what the original ideal and intention was and all
evidence is showing that the migration path expected is on par and
right on, - get the clients to support both before a new BIS
specification can safely recommend a pure single RR type to be
published rather than both type 99 and TXT.
So I believe revisiting the original ideal goal will help in these
decisions regarding the exploration of using new RR types - not a
"who's who" highly subjective criteria that has nothing to do with
with the fundamental ideal of improving DNS operations.
I'm not getting any traction using this fundamental consideration and
its odd to me, to be frank.
� wrote:
On 27 feb 2012, at 21:19, Hector wrote:
Thanks Patrick.
Is there an element, or include, the "Simplicity" argument that has been presented to you?
Thats the feeling I am getting - Fast entry, don' sweat the DNS impact and today, its high OS/software, DB speeds and overall robustness is good enough. Once upon a time, the idea of redundancy (calls) was a concern, at least that seem to be the general mindset, but over time, I have seen statements that we shouldn't worry about it - just do it! Better caching resolves much of the redundancy related overhead concerns.
PS: I agree with your position.
The arguments I hear are I think very unfortunate, but I of course understand them. They include for example:
- GUI (as in actual web interface or such) does not support the RRType
Example: Many DNS hosting providers do not allow even NAPTR or SRV RRTypes today. Even fewer URI or SPF.
- Code in for example bind and other name server software do not support the new RRType
Example: Even if one use Emacs, VI or whatever else txt tool one have to add the RR using hex which for complicated RRTypes might be very hard to calculate.
- The protocol used in clients is not DNS
Example: The actual lookup can only be of data that is proxied to various RRTypes that are "known"
- Local software do not handle new RRTypes
Example: Programmer want to use some resolver library that only support a subset of RRTypes that exists, and to use other RRTypes one must use "unknown" RRType or be able to at least enumerate exactly the #id of the RRType itself, and then parse the raw data that comes back.
- Firewall software do not handle new RRTypes
Example: Deep packet inspection of DNS flow(s) do only allow certain DNS RRTypes to pass through
...and more...
I do though think limiting us to certain types will have impact not only for effective use of HTTP and other protocols (I think we need SRV, URI etc), but also have impact on for example deployment of DNSSEC.
The first (successful) step was to ensure DNS core software do understand "unknown RRTypes" which I claim is now deployed "in the core". Edge is still questionable (see above).
I do not want to give up proper deployment though. I just do not do that.
Some people with very old software that can not be updated will loose. They will not get the new features new RRTypes can give.
Yes, a pain. But...we just must be able to get new RRTypes deployed. And not give up.
Patrik
I would like to poise this general question to the IETF/DNS community:
Given higher modern DNS server support for unnamed types, should
new protocols continues to pursue new RR types or does the
DNS Community believe this original infrastructure ideal is no longer
necessary and new protocols can use TXT records with a high
degree of DNS support confidence for robustness.
Many new protocols use the TXT records simply as a fast entry, high support mechanism to store data on DNS. Is the mindset today such that this is still desirable, is there an DNS impact with this on going direction?
I have not heard anything else than arguments in RFC5507 against reusing same RRType for many different kind of use.
5507 Design Choices When Expanding the DNS. IAB, P. Faltstrom, Ed., R.
Austein, Ed., P. Koch, Ed.. April 2009. (Format: TXT=44045 bytes)
(Status: INFORMATIONAL)
So, still, no, you should not reuse TXT. You should have your own RRType. Other choices makes your design very complex.
Yes, many people will still disagree with me, using arguments I do not agree with...
Patrik
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf