[forwarded here so that people are aware of discussions on spf & dns]
On Wed, 12 Jan 2005, Paul Vixie wrote:
As I said, on the tests it appears that dns servers (bind 8 and bind 9
at least) do provide this information nearly all the time including for
NOERROR/NODATA, so I don't think querying for SOA is going to be needed
very often.
this is namedroppers@, not bind-workers(_at_)(_dot_) how a particular
implementation
behaves is of no interest to the ietf, other than if a widely implemented
protocol violation (which this is not) makes it necessary to design-around
(which this does not).
BIND is not the only dns server that returns SOA in authority section for
NODATA. Verisign's server does the same too and ULTRADNS is doing same.
The point is that if in 99% of cases dns servers already return an answer
that we're looking for, then trying to use that is certainly not stupid or
bad idea (as long as we know how to get the answer in the remaining cases).
And yes it does sound weird for non-dns service to query for soa, but
its not breaking anything either as far as I can see and querying for
soa can be usefull for more then just dns internal communication, for
example to find tech/hostmaster address if whois is not available (ok,
you can go ahead and blame me for this trick and inappropriate use :)
that's what RP RR's are for.
How many RPs have you seen in the wild lately? Its practicly a dead RR...
or did you not know that SOA was never cached?
I believe SOA responses are not cached only if its for non-existing domains.
Its possible that RFCs say that SOA lookups may or may not be cached, but
the same is true for all other DNS RR lookups too and I do believe that
direct queries for SOA are in fact cached.
But it is certainly true that you might expect special treatment for
piece of data that is carrying caching information.
i really am pretty sure that the dns servers will be changed to support
SPF other than to support a new RRtype when y'all get around to
proposing that.
s/will/won't/, sorry. though i suppose it was clear in context.
No wonder I got surprised that it was so easy to get a yes answer ...
Should I take as that you're willing to support such a feature (synthetic
wildcard for existing hostname but without needed RR) in future versions
of bind?
no. i misspoke. BIND will implement the dns protocol as defined by the
ietf, with occasional experimental features if those do not violate the
protocol defined by the ietf.
The slow process of adding new features to dns (both protocol and to
implementation) is why most in SPF community want to simulate wildcard
with user-level queries on zonecut for default record. Same is why they
chose to use TXT RR instead of new RR.
I believe the solution lies in the middle - we should proceed with both
user-level queries and with process of adding new zonecut-default wildcard
to DNS system. This way the currently proposed system of user-level queries
for zonecut records will become absolute and not used in the future any more.
The above is similtar to what was proposed by Ted Hardie at MARID meeting -
allow to use TXT temporarily (maybe 5 years) and get new RR and provide
ways to use both with in the future moving towards new RR and changing
from SHOULD check both records to MUST check SPF RR first and then
absoluting TXT 10 years down the road.
In that case it makes sense for this to become a new dns protocol
feature so that other dns servers would know how to support it too, so
I think it would be good idea to write it out as ietf document
(separate and not just part of spf draft).
even though i misspoke, there's a path forward illuminated by the mistake.
if you want rrtype-specific wildcards, like for example an "**" label in a
zone file should be a wildcard but only for the rrtypes at the "**" node,
then go ahead and propose it. if ietf approved such a standard, then BIND
will implement it. i suspect that the process would be too long for SPF's
requirements.
I maybe willing to wait and go through the process, but I certainly dont
expect that majority of spf community would (i.e. considering that they
did not even agree to use prefix for placement of data with primary argument
againt being that it was not always correct character in the dns user
interface that they get to use with the web hosting company). Good
technical reasons and arguments and trying to follow proper standards
process don't appear to always work the right way when dealing with spf ...
In any case for more practical question. Do youthink getting draft like
this to experimental status be possible within say a year (not necessarily
just for spf reasons)?
And to make it possible to identify dns records where such new wildcard
does need to be supported, I think we do need special prefix (and its not
too late as I don't even know any spf implementation that is doing zonecut
default checks yet).
that's not a reason for a special prefix.
There are several reasons for it that I discussed at SPF (current situation
requires special handling with complex redirects when somebody does need it
to be different; with introduction of EHLO checks and without scoping it
has larger chance for confusion and incorrectly blocked email, etc). And
with prefix it has a chance to accomondate protocols other then just SPF.
but as SOA is not cached, it is not something that should be queried for
other than as part of DNS operations such as serial number queries
governing IXFR/AXFR or UPDATE.
I do not believe that there is any documents that specifically limits SOA
use in this way. But I'll investigate further if doing NS checks instead
of SOA has any difference in the result, however if it turns out that
doing SOA provides correct information all the time or faster then I'll
advocate for that (and if I remember right your own code for finding
zonecuts is in fact using SOA!)
since SPF does not yet do any zonecut checks, please remove that part of
the draft.
Not up to me, I've already asked for it to be removed or modified twice
at spf-discuss as I'm not willing to support it the way it is now because
it will lead to way too many queries to ISP mail servers and to much
cofusion for dns administrators.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net