Re: Re: DNS load research

Andy Bakun wrote:
> On Thu, 2005-03-24 at 11:43, David MacQuigg wrote:
>
> > So far I've 
> > only heard vague objections to making an SPF record compiler part of the 
> > running setup on a DNS server.  
>
> I think this is based on the fact that DNS gurus were kind of turned off
> by what SPF was doing with TXT,
Did they explain the reasons for the turn-off? Could it be the 
script-like behaviour of SPF ? I can see that being rejected, due to the 
potential for abuse I've demonstrated.
> and no one could come to an official
> agreement on if SPF should use TXT, or its own record, and no one really
> thought making changes to DNS servers was a viable option for
> wide-spread deployment. 
I think we are largely agreeing with this position. We agree that making 
changes to servers is not a requirement for the success of SPF ?
The changes that we are proposing are optional, and they only offer 
convenience of publishing expensive records, and have them automatically 
translated to simple records.
> I believe someone with prominent placement in
> bind9's development (Vixie maybe?  Forgive me if I'm wrong or
> misremembering) said they were not going support making any changes to
> bind9 to support SPF.  As such, concepts related to touching DNS servers
> at all are somewhat sticky points.
Yes, it is risky business messing with DNS servers. But that should not 
prevent us from running a test case, and observing any unanticipated 
issues that develop.
> > It certainly doesn't require abandoning 
> > SPF, or even patching the DNS servers.  An SPF compiling daemon could 
> > interface with a DNS server by simply updating the DNS records.
Absolutely. Just like you can have master NS servers and secondary 
servers, you can have the master server be a compiler is neither 
published in the SOA, nor responds to public queries, and have it do 
zone transfers to the slave NS servers. The slaves would be high volume 
servers running production, stable releases of DNS server software. This 
scheme is widely used (ie, a master server which is not public, and 
slaves that are). The zones would be vulnerable to bugs in the compiler 
master server, but due to the expire/retry nature of zone transfer 
scheduling, there is probably plenty of time (days) to restart the 
master server or otherwise deal with the issue.
In any case, until we can demonstrate a master compiling server that is 
stable and can run reliably for months at a time, we'll see a lot of 
reluctance to this new and risky idea. Face it, from the perspective of 
a network admin who has a reliable DNS running, any changes to NS 
infrastructure are risky.
> I may be wrong on this, but deploying a script that runs via cron and
> updates zone files may be considered risker than just deploying a new
> DNS server package from your vendor that is SPF aware (the latter
> implies source changes to the DNS server, even though it doesn't
> necessarily mean that).
>
> I have spent some time wading through the bind9 source trying to figure
> out how to add MX records (and the resultant A records) to the
> additional section of the response when sending an SPF TXT RR, as a
> first step (admittedly not the final step) to making DNS servers SPF
> aware and cutting down on total queries.  Unfortunately, I have not made
> as much progress as I'd like.
>
> It might be better to set up a zone that gets updates via DDNS, and have
> the compiler publish them that way.  Before I consider starting on this,
> there has to be someone already working on this obvious solution, right?
> :)
I will be integrating the libspf2 1.0.6 compiler into MyDNS.

MyDNS is an open-source authoritative DNS server that uses MySQL for 
backend storage. There is a functional web interface to add new entries 
into the  MySQL tables, which will then be served instantly, without 
needing to restart or reload anything, as with BIND. Google MyDNS for 
more info.
I picked this one because it uses MySQL, the updates are live, the 
developer is active on the mailing list, and several people are running 
it with good results. There was even someone who runs the current 
version for 6 months (6 month uptime), and gets about 1 million 
queries/day. Based on the mailing list, there are a few quirks, but it 
seems that the developer is very receptive and is working on them. 
Overall, I think it will be a great testbed for the SPF compiler.
Since it is an authoritative server without recursion, it will only be 
compiling the records of the domains it hosts. In any case, a caching NS 
server should not compile any SPF records. (It may be possible, I 
haven't thought enough about it, but I will start with a simple case of 
a non-caching server first)
The tables are well described, and I plan on adding the following hooks:

1. a separate temporary table for the compiled TXT records.
2. In the SQL query function, I will insert the following hook:
   When TXT entries are seeked, a routine to re-compile the sought
   record will be called, if its TTL counter has expired. This maps
   into the libspf2 library.
   Then the query will be done in the temporary table rather than
   the main table. The result returned to the sender.

   The uncompiled (raw/convenient) records are still maintained in the
   main SQL table, and will not be touched by the SPF compiler.

Nothing else will be changed.

Perhaps a new SPF-specific web interface can be designed, based on the 
existing web-enabled interface (uses PHP).
Greetings,
Radu.