ietf
[Top] [All Lists]

Re: DNS RRTYPEs, the difficulty with

2012-02-27 14:30:58
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