In <10297703(_dot_)1079999087(_at_)[10(_dot_)12(_dot_)1(_dot_)18]> Greg Connor
<gconnor(_at_)nekodojo(_dot_)org> writes:
--wayne <wayne(_at_)midwestcs(_dot_)com> wrote:
Yes, this is the approach I have advocated. What you described is
almost the same as what the res_findzonecut() function does. It is
basically the same algorithm that is used for DNSSEC and what is used
internally in Bind. The only major different that I noted is that SOA
records are, sadly, optional, so you may be forced to walk up the DNS
tree until you find authorative nameservers. (Which, again, is what
Bind does.)
Wait a second, in what way are SOA records optional? This is a new
one on me...
Yeah, it was news to me also when I read it in the BIND source.
RFC1035 says:
: 5.2. Use of master files to define zones
:
: [snip]
: 2. Exactly one SOA RR should be present at the top of the zone.
I think the "optional SOA" record is like the "optional MX" record
thing. They were both later creations and no sunset provision was
mandated. Hence, we are stuck with both of them being optional until
such time as a sunset provision is created.
My main concern here was for folks who want to implement something for
their top-level domain (like widgets.com) and haven't thought through
all the implications for all the next-level names (like
support.widgets.com, which may be answered from India :) I do like
the idea of one-TXT-to-rule-them all... but we have to be Extra Extra
careful to explain to folks that they should SPF the next-level
(longer) domains first, even if it is ?all.
Yes, I agree, this is an important consideration.
On the other hand, I suspect that far more people having realized that
they currently must publish SPF records for *every* subdomain that has
an A record to get complete protection.
While surprises will arrise in both cases, I think the
one-TXT-to-rule-them-all case will cause fewer surprises.
-wayne