-----Original Message-----
From: owner-ietf-mxcomp(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-mxcomp(_at_)mail(_dot_)imc(_dot_)org]On Behalf Of Matthias
Leisi
Sent: Sunday, September 05, 2004 10:41 AM
To: 'IETF MARID WG'
Subject: Re: consensus call of RR prefix
terry(_at_)ashtonwoodshomes(_dot_)com wrote:
-not all dns servers support "_"
Just for clarification: Which DNS servers do /not/ support
underscores?
Sorry, that should read: DNS providers whose UI on the server does not support
"_".
I know from testing that BIND 9 is happy with them; since
Microsoft uses
them for some AD stuff, I guess that at least newer
implementations of
their DNS services will not choke on them.
Local DNS libraries seem to be able to handle it - at least I haven't
heard of resolver-library incompatibility with products that
use Apple's
Rendezvous, which is based on kind-of-SRV records and also use SRV's
_<service>._<proto> scheme.
Of course, further testing would be fine, but technically
most relevant
pieces of DNS software around should not have issues underscores.
-many dns providers do not allow subdomains (or not easily
via an interface, and we need to keep
publishing easy or it won't get done)(yes I know many ISPs
don't support TXT RR either, but that
*is* changing and it *is* an RFC compliant DNS standard,
even if SPF abuses it)
Which DNS providers do (not) allow subdomains and/or TXT records?
Again, its not just about whether the DNS provider refuses. My personal DNS
provider does not
support, TXT, so I had to wade through a support call (which turned into
emails) to get them to set
my vanity domain with an SPF record. But not everyone (most?) with domains
(vanity or otherwise)
would go to that effort.
I expect many/most DNS providers will enhance their UI to allow TXT records
(all I have contacted or
heard about have said "coming soon"). But at least some (including mine) are
not allowing
subdomains or extensions beyond the usual www, ftp etc. (Course, the subdomain
could become one of
"the usual", if its ratified)
Adding something a record for "_spf" should not be any different from
adding a "www" record to a domain.
Agreed. But its not me that needs convincing, its the DNS providers.
(Adding TXT records to the admin GUI of my non-profit ISP took me a
couple of minutes.)
Agreed it can be done (providing the backend DNS server can do it). But some
DNS providers have big
fancy (aka crappy) integrated (often flash based, ugh!) UI's (e.g. look.ca)
Changing those UI's can
be non trivial.
IMO, there are no technical or admin issues for or against RR
prefixes.
Provided you don't consider deployment/adoption technical, and you never have
to explain to a "*
Certified * Engineer" how/why things actually work. You really cannot just
look at technical
issues, you have to look at all that are reasonably relevant and can have an
actual impact.
Having said that, there are of course policy reasons to
consider - eg if
we go for a dedicated record type for "MARID", there is no need for a
prefix (after all, we don't have a prefix for MX records).
Agreed. And that *is* where I think (and believe) we are going, our own RR
type.
Still IMO, a prefix would only make sense if the TXT record
workaround
were a long-term solution.
I suspect within about 4 years of dedicated RR type approval the significant
majority of published
domains would have switched. (Or at least published new type, hence the second
lookup on the TXT
type becomes unnecessary). This opinion is based on the idea that those who
published TXT would be
just as willing/eager to adopt the RR type, and that the new RR type is
approved and deployed BEFORE
SPF publishing becomes a "standard requirement" before sending email.
As this quite possibly is not the intention
of this working group, using a prefix does not offer any
benefits other
than possibly keeping the DNS response size below the magical
418 bytes,
a restriction which can be easily worked around using
redirects by those
few(?) that would need it.
Agreed.
Terry
-- Matthias
--
Brain-Log http://matthias.leisi.net/