Subject: Caching SOA records (was Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt)

From: Matt Larson <[email-masked]>
Date: Wed, 12 Jan 2005 15:24:17 -0500

On Wed, 12 Jan 2005, Paul Vixie wrote:
> but as SOA is not cached,

This statement is contradicted by RFC 1034, section 4.3.4:

  Name servers and resolvers should never attempt to add SOAs to the
  additional section of a non-authoritative response, or attempt to infer
  results which are not directly stated in an authoritative response.
  There are several reasons for this, including: cached information isn't
  usually enough to match up RRs and their zone names, SOA RRs may be
  cached due to direct SOA queries, and name servers are not required to
  output the SOAs in the authority section.

and RFC 2182:

  7.2. TTLs on SOA RRs

     It may be observed that in section 3.2.1 of RFC1035, which defines
     the format of a Resource Record, that the definition of the TTL field
     contains a throw away line which states that the TTL of an SOA record
     should always be sent as zero to prevent caching.  This is mentioned
     nowhere else, and has not generally been implemented.
     Implementations should not assume that SOA records will have a TTL of
     zero, nor are they required to send SOA records with a TTL of zero.

FWIW, my BIND 9.2.4 recursive name server clearly caches SOA records,
as do a few other BIND recursive servers of random or unknown version
numbers that I queried.

Matt

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: "william(at)elan.net" <[email-masked]>
Date: Wed, 12 Jan 2005 17:30:42 -0800 (PST)

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@.  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
[email-masked]