ietf-clear
[Top] [All Lists]

[clear] Plan of Action for CSV?

2005-06-21 18:36:20
In <20050622021328(_dot_)26136(_dot_)qmail(_at_)xuxa(_dot_)iecc(_dot_)com> John 
Levine <clear(_at_)johnlevine(_dot_)com> writes:

By the way, the comment about BIND doing round robin is pretty
persuasive.

Round robin within a RR set is different than rotate the list of
answers returned when the RR set is too large.


             Now that I think about it, if you look at the semantics
of all of the other RR types, if there are a whole bunch of records
and you only get some of them, that's OK because they're telling you
about multiple alternate places to get equivalent services, and any
will do.  But now we have a design that depends on getting all of the
RRs in a set.

When the RR set doesn't fit in the answer section, the TC bit is
supposed to be set, so that you can fall back to TCP to get the
complete set.  (See RFC1035)

If you get an incomplete set, you aren't supposed to cache the answer
and all TTLs are supposed to be the same in a RR set.  (Also see
RFC1035)

The rules for getting a complete RR set are even stronger with DNSSEC
'cause you can't sign a partial set.



So let's say I have a pool of 50 hosts that HELO as, say, blurch.com,
so I set up a SRV record that refers to _csv.blurch.com, and then add
50 A records for _csv.blurch.com for all those hosts.  Will DNS servers
return all 50 of them, or will they pick a dozen and figure that's all
I need. 

Things in the authoratative and additional sections can be dropped,
which can cause additional actual DNS packets (rather than just more
queries to the local resolver) when getting all A records for MX or
SRV RR sets.


         Has anyone done experiments, particularly with bind 4.x?

I'm sure everyone will be shocked to learn that djbdns breaks things.
Or, at least, that was our experience in the http://www.pool.ntp.org
project where we have several hundred NTP servers that need to be
rotated through.  In order to prevent TCP fallback, the zone file is
regenerated periodically, but the djbdns secondary would only serve
about half of the A records.  This secondary NS for pool.ntp.org has
since been dropped from the list.

I really don't know about bind 4, but we didn't have a huge selection
of name servers for the pool.ntp.org zone.

I thought AOL did something similar to the NTP Pool project with their
MX records, but I can't seem to reproduce the results now.  Maybe it
was one of the other large ISPs, it has been at least a year since I
investigated this kind of thing.



This problem affects SPF, too, but I don't think it has occurred to them.

If I were you, I wouldn't bet my life on that.  I consider this one of
those "Doctor! Doctor!  It hurts when I do this!" things.  I guess I
should have put a warning into the SPF I-D to make sure people are
aware of this.


-wayne