I have found what appears to be a bug.
It's in the distance field of an mx record, if I create two records in
the default_records table, the distance field is set in the db as
I filled it in, with 10 and 20 for the distance.
However when I create a record based on these defaults, the distance field
is set to 0 for both.
If I edit those two records manually and set the distance to 10 and 20,
and then export them to the tinydns data file, they appear OK
So the bug lies somewhere in the code that creates a new record based on
the settings in default_records.
I have found it, in domains.php, line 265
here is a diff
--- /var/vegadns-0.8.1/src/domains.php Fri Jun 18 04:45:48 2004
+++ /var/www/vegadns-0.8.1/src/domains.php Wed Jul 14 10:34:13 2004
@@ -257,11 +257,12 @@
while(list($key,$row) = each($records_array)) {
$host = ereg_replace("DOMAIN", $domain, $row['host']);
$val = ereg_replace("DOMAIN", $domain, $row['val']);
- $q = "insert into records (domain_id,host,type,val,ttl)
+ $q = "insert into records (domain_id,host,type,val,distance,ttl)
values('$id',
'".mysql_escape_string($host)."',
'".$row['type']."',
'$val',
+ '".$row['distance']."',
'".$row['ttl']."')";
mysql_query($q) or die(mysql_error());
dns_log($id, "added ".$row['type']." $host with value $val");
works now
vegadns is nice, I would personally prefer to use . and = type records, but it
does appear to be producing good dns records, at least on my devbox ;-)
I suspect that using Z and & type records might interact better with bind/
named, but I don't really know and can't test that thesis easily.
Hope this helps
