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