Re: DNS RRTYPEs, the difficulty with

Offlist. I will have an public reply to the message, maybe. I just 
want to hopefully show some basic more friendly approach to your 
statements from one that basically begins a friction:
Scott:

   I know all about how I could publish SPF records.  You are missing 
my point.
Revised friendly, no friction.

   Yes, but perhaps you may missed my points....

Why? because I did not miss your point and I could easily say:

   "Scott, I always saw your point, the problem is you are missing the
    point of others."

So in essence, it shows we are talking pass each other and the way you 
stated just feeds into the people like Murray's who will now say, "He 
is always missing the point."
So understand your  MAIN point and always did and that is why I 
started with this thread when I asked:
    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.

And why you see most, if not all of the infrastructure people who 
posted, including Patrick, Mark, Paul and others like Burton express 
the same belief that new RR types are preferred.
Every one of us agreed that there are valid arguments and issues, and 
that is why I am saying
   "Ok, is it still a preferred ideal and are the issues are too 
problematic,
    and also importantly, the HARDWARE/SOFTWARE and DATABASES have 
improved
    so much that it means many of the early and current concerns 
obsolete."
See that last point - even current concerns regarding wasted calls. 
If you argue the point that it is WASTED CALLS, then you are making an 
infrastructure consideration that it will benefit DNS large scale 
usage by not use new RR types that already have a TXT backup.
But that is not the argument you are making, you are using low usage, 
and its even harder to see that as valid, when A) its not "honest" and 
B) the migration we wanted is exactly that happen.
Try to understand these subtle points because if you believe it was 
important, then you may see that the solution is to now promote the 
publishing in order to begin getting a payoff with the clients already 
doing the SPF type call.  I would also suggest that we help embark a 
technical sales marketing campaign to get hosting companies to begin 
supporting  the new IETF protocols with their specific RR types.
Scott say:

   No one is going to switch providers and risk downtime in order to 
publish a
   record that to a very, very close approximation accomplished nothing.

Revised friendly text:

   I suspect or don't have the confidence domain owners will switch 
providers
   and risk downtime in order to publish a record that to a very, very
   close approximation accomplished nothing.

Why?

Highly subjective.  Its a crystal ball opinion and one that comes with 
very high potential to see  domains beginning to use SPF types, 
especially those who have an Infrastructure Optimizing belief that it 
will help with contributing to a lesser SPF TXT only impact on DNS.
You completely ignore that I stated. Before the migration evidence 
shown that has proved the original intent was correct, I was 100% with 
you.  But the migration path that was discovered, I am 100% eager now 
to support it.
You ignored the next step for the migration now that clients are 
ready, promoting SPF type publishing perhaps starting with a dual 
publishing as well as the next migration expected.
And finally, you might be not aware of, but if you are, then ignoring, 
the very important points in the DNSOPS thread I started with Paul 
Vixie input showing perhaps what is the solution we should be repeated 
with Additional Info queries like it was with A/MX records.
   http://www.ietf.org/mail-archive/web/dnsop/current/msg09447.html
   http://www.ietf.org/mail-archive/web/dnsop/current/msg09451.html
   http://www.ietf.org/mail-archive/web/dnsop/current/msg09453.html


What I am saying use a solid engineering logic based on technical 
merit, and not a "practically factor" to dismiss what is still 
important considerations.  The reason overall is that you are are 
saying these ISP will never change and that is a "prediction" that can 
be very easily become untrue.
All it takes a better IETF promotion and marketing to get more ISP to 
support new RR types.

Scott Kitterman wrote:
> On Tuesday, February 28, 2012 07:52:37 PM Hector wrote:
> > Scott Kitterman wrote:
> > > > If your DNS hosting company doesn't support them find another one
> > > > or complain to them.  You are paying them to host your DNS services
> > > > and this is a basic part of the job.
> > > To what hosting company should I switch if I want to publish SPF records
> > > of Type SPF?
> > SMTP hosting systems are not stuck using their ISP's primary name
> > servers currently limited in their customer's UI management of
> > domain(s) zone file(s).
> >
> > You could always use your own name server or use another that is more
> > flexible. No need to switch ISPs. Some may even allow you to do
> > offline editing (export/import) of your zone files.
> >
> > If you don't wish to have your own primary DNS server, there are many
> > out there you can switch to, some even free, and perhaps for only
> > using a faster, more 24x7 reliable name server than their ISP's name
> > servers who could be tier limiting the customer.
> >
> > I've gone through this issue a # of times just with SRV with customers
> > and their ISPs was limited in the UI in some way. Not an issue today
> > with SRV,  but the idea of installing or switching the name servers
> > was always a last recourse option considered.
> >
> > Yet, even if the ISP or with your own name server you added the SPF
> > type, that still didn't mean all query paths taken would be
> > successful. It could work 100% with testing short distance paths and
> > locally, but from a remote different path?  It may not work.  That was
> > the early RFC3597 issues I experienced that basically made you just
> > punt of the idea of using new RR type with the obvious overhead waste.
> >   But my experience today, the RFC3597 issues are much less.  I would
> > not hesitate to finally enabling SPF type as a default option in our
> > wares, at least give a new look for reasonable feasible results on par
> > with the migration that has materialized.
> Hector,
>
> I know all about how I could publish SPF records.  You are missing my point.
>
> In the previous message it was suggested that people who use a hosted DNS 
> service should switch if their service doesn't support Type SPF.  The problem 
> is that, as far as I'm aware, none of them do.  
>
> I have not determined any source of economic motivation to get that to change.  
> "Support this or I'll take my business to someone that does" is an empty 
> threat unless someone actually does.  It's also not something anyone other 
> than DNS purists would worry about.  No one is going to switch providers and 
> risk downtime in order to publish a record that to a very, very close 
> approximation accomplished nothing.
> Scott K
> _______________________________________________
> Ietf mailing list
> Ietf(_at_)ietf(_dot_)org
> https://www.ietf.org/mailman/listinfo/ietf
--
Sincerely

Hector Santos
http://www.santronics.com
jabber: hector(_at_)jabber(_dot_)isdg(_dot_)net

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