ietf
[Top] [All Lists]

Re: DNS RRTYPEs, the difficulty with

2012-02-27 15:04:21
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf