spf-discuss
[Top] [All Lists]

Re: solving the demon problem: use the zonecut

2004-04-26 06:16:33

About a month ago, the subject of what to do with subdomains that
don't publish SPF records (when the parent domains does) was
discussed.  I posted the following message, and the response was
reasonably well received.

I would like to see the zonecut check be made offical.  What do others
think?


Here is the post I made:


In <20040304015740(_dot_)651B7584(_at_)dumbo(_dot_)pobox(_dot_)com> 
mengwong(_at_)dumbo(_dot_)pobox(_dot_)com (Meng Weng Wong) writes:

so suppose domain.com publishes SPF.

but workstation.domain.com does not.

right now SPF tells you to publish an SPF record for every single
subdomain that has either A or MX.  but that's yucky.

I agree, it is very yucky.

One of the things that is on my TODO list for libspf-alt is to use
the res_findzonecut function to find the zone cut and look for SPF
records there.

I suggestion that this is the "best" way to handle this missing SPF
records for subdomains.



The res_findzonecut uses the same algorithm that is used for finding
zone cuts in bind and for the DNSSEC stuff.  Basically, it finds where
points of namespace delegation are and DNSSEC only allows new certs
and such to be placed at those spots.  I figure that these are the
same spots that make sense for default SPF records.

Here is the definition of a zone cut from RFC2181:

    6. Zone Cuts
    
       The DNS tree is divided into "zones", which are collections of
       domains that are treated as a unit for certain management purposes.
       Zones are delimited by "zone cuts".  Each zone cut separates a
       "child" zone (below the cut) from a "parent" zone (above the cut).
       The domain name that appears at the top of a zone (just below the cut
       that separates the zone from its parent) is called the zone's
       "origin".  The name of the zone is the same as the name of the domain
       at the zone's origin.  Each zone comprises that subset of the DNS
       tree that is at or below the zone's origin, and that is above the
       cuts that separate the zone from its children (if any).  The
       existence of a zone cut is indicated in the parent zone by the
       existence of NS records specifying the origin of the child zone.  A
       child zone does not contain any explicit reference to its parent.


Zone cuts can usually be found with just a few DNS queries (I think
often just one).

Here is a description of how res_findzonecut function works from the
bind source:

/*
 * int
 * res_findzonecut(res, dname, class, zname, zsize, addrs, naddrs)
 *      find enclosing zone for a <dname,class>, and some server addresses
 * parameters:
 *      res - resolver context to work within (is modified)
 *      dname - domain name whose enclosing zone is desired
 *      class - class of dname (and its enclosing zone)
 *      zname - found zone name
 *      zsize - allocated size of zname
 *      addrs - found server addresses
 *      naddrs - max number of addrs
 * return values:
 *      < 0 - an error occurred (check errno)
 *      = 0 - zname is now valid, but addrs[] wasn't changed
 *      > 0 - zname is now valid, and return value is number of addrs[] found
 * notes:
 *      this function calls res_nsend() which means it depends on correctly
 *      functioning recursive nameservers (usually defined in /etc/resolv.conf
 *      or its local equivilent).
 *
 *      we start by asking for an SOA<dname,class>.  if we get one as an
 *      answer, that just means <dname,class> is a zone top, which is fine.
 *      more than likely we'll be told to go pound sand, in the form of a
 *      negative answer.
 *
 *      note that we are not prepared to deal with referrals since that would
 *      only come from authority servers and our correctly functioning local
 *      recursive server would have followed the referral and got us something
 *      more definite.
 *
 *      if the authority section contains an SOA, this SOA should also be the
 *      closest enclosing zone, since any intermediary zone cuts would've been
 *      returned as referrals and dealt with by our correctly functioning local
 *      recursive name server.  but an SOA in the authority section should NOT
 *      match our dname (since that would have been returned in the answer
 *      section).  an authority section SOA has to be "above" our dname.
 *
 *      however, since authority section SOA's were once optional, it's
 *      possible that we'll have to go hunting for the enclosing SOA by
 *      ripping labels off the front of our dname -- this is known as "doing
 *      it the hard way."
 *
 *      ultimately we want some server addresses, which are ideally the ones
 *      pertaining to the SOA.MNAME, but only if there is a matching NS RR.
 *      so the second phase (after we find an SOA) is to go looking for the
 *      NS RRset for that SOA's zone.
 *
 *      no answer section processed by this code is allowed to contain CNAME
 *      or DNAME RR's.  for the SOA query this means we strip a label and
 *      keep going.  for the NS and A queries this means we just give up.
 */

-wayne


<Prev in Thread] Current Thread [Next in Thread>