Dallas Engleken of SARE has suggested that we add a dataset directive to our rbldnsd zone files:
Can we please add a $DATASET definition to rbldnsd zone files for sc,ws, and be?
Ie.. On the 3rd line after $NS and $SOA, add a line labeled,
$DATASET dnset @
It will not break anything currently set up, but it will give those of use that use the 'combined' type with multi files in rbldnsd (called via uribl.surbl.org:combined:sc,be,ws) to merge ws, sc, and be together to create a single query.
Does anyone have any comments on this, good, bad or otherwise? Do other RBLs do it? Is it safe?
Here's the man page entry: :-)
man rbldnsd
combined This is a special dataset that stores no data by itself but acts like a container for several other datasets of any type except of combined type itself. The data file contains an optional common section, where various specials are recognized like $NS, $SOA, $TTL (see above), and a series of sections, each of which defines one (nested) dataset and several subzones of the base zone, for which this dataset should be consulted. New (nested) dataset starts with a line $DATASET type subzone subzone... and all subsequent lines up to the end of current file or to next $DATASET line are interpreted as a part of dataset of type type. Note that combined datasets cannot be nested. Every subâ zone will always be relative to the base zone name specified on command line. If subzone specified as single character "@", dataset will be connected to the base zone itself. This dataset type aims to simplify subzone maintenance, in order to be able to include several subzones in one file for easy data transfer, atomic operations and to be able to modify list of subzones on remote secondary nameservers. Note that $NS and $SOA values applies to the base zone only, regardless of the placement in the file. Unlike the $TTL values and $n substitutions, which may be both global and local for a given (subâ)dataset.
Thumbs up or thumbs down? ;-)
Jeff C.
Hi,
Jeff Chan wrote:
Dallas Engleken of SARE has suggested that we add a dataset directive to our rbldnsd zone files:
Can we please add a $DATASET definition to rbldnsd zone files for sc,ws, and be?
Ie.. On the 3rd line after $NS and $SOA, add a line labeled,
$DATASET dnset @
It will not break anything currently set up, but it will give those of use that use the 'combined' type with multi files in rbldnsd (called via uribl.surbl.org:combined:sc,be,ws) to merge ws, sc, and be together to create a single query.
Does anyone have any comments on this, good, bad or otherwise? Do other RBLs do it? Is it safe?
Here's the man page entry: :-)
I'm all for that and I'd love to see the $SOA and $NS lines removed completely from the rbldnsd files.
There is no need for them and they tend to screw up people who are running their own rbldnsd local rbl's because of the $NS entries.
Example, I run ws.spa.aei.ca, from the ws.surbl.org dataset. The first query will work correctly, but all subsequent queries will fail because the $NS records will point to hosts that do not host ws.spa.aei.ca.
If you really want high volume mail servers to rsync the data and use their own local rbldnsd servers, you may want to rethink using $SOA and $NS in the rbldnsd files.
Yes, I know I can do it using ws.surbl.org and setting ws.surbl.org to my own IP but it's kludgey and and hack. Maybe I don't want to share my name servers with others (or in my case I'm not allowed to) so my hack to get it working is open for abuse.
Just my $0.02.
Regards,
Rick
Hi!
Yes, I know I can do it using ws.surbl.org and setting ws.surbl.org to my own IP but it's kludgey and and hack. Maybe I don't want to share my name servers with others (or in my case I'm not allowed to) so my hack to get it working is open for abuse.
You can do this 3with forwarders in bind, and you can also define a vieuw in bind so only you can use it, i dont see a problem there.
I DO see an advantage that i am using for some other RBLs also, you can then combine the zones into one big list on the nameservers itself...
Like this:
sbl -r/var/named/spamhaus -t21600 -c60 -b127.0.0.1/430 \ sbl.spamhaus.org:ip4set:sbl \
xbl -r/var/named/spamhaus -t21600 -c60 -b127.0.0.1/330 \ xbl.spamhaus.org:ip4set:xbl \
sbl-xbl -r/var/named/spamhaus -t21600 -c60 -b127.0.0.1/230 \ sbl-xbl.spamhaus.org:ip4set:sbl \ sbl-xbl.spamhaus.org:ip4set:xbl \
Bye, Raymond.
On Wednesday, April 28, 2004, 12:27:18 AM, Raymond Dijkxhoorn wrote:
I DO see an advantage that i am using for some other RBLs also, you can then combine the zones into one big list on the nameservers itself...
Like this:
sbl -r/var/named/spamhaus -t21600 -c60 -b127.0.0.1/430 \ sbl.spamhaus.org:ip4set:sbl \
xbl -r/var/named/spamhaus -t21600 -c60 -b127.0.0.1/330 \ xbl.spamhaus.org:ip4set:xbl \
sbl-xbl -r/var/named/spamhaus -t21600 -c60 -b127.0.0.1/230 \ sbl-xbl.spamhaus.org:ip4set:sbl \ sbl-xbl.spamhaus.org:ip4set:xbl \
Hmm, what does that mean in terms of the presence of $SOA and $NS in each rbldnsd zone file? Do those help or hurt what you do above?
Also, any opinions on $DATASET dnset @ ?
Jeff C.
Hi!
sbl-xbl -r/var/named/spamhaus -t21600 -c60 -b127.0.0.1/230 \ sbl-xbl.spamhaus.org:ip4set:sbl \ sbl-xbl.spamhaus.org:ip4set:xbl \
Hmm, what does that mean in terms of the presence of $SOA and $NS in each rbldnsd zone file? Do those help or hurt what you do above?
I dont use them, but they also supply:
[root@vmx01 spamhaus]# more xbl-extras $SOA 3600 need.to.know.only. hostmaster.spamhaus.org. 0 1h 10m 5d 1200 $NS 86400 a.ns.spamhaus.org c.ns.spamhaus.org e.ns.spamhaus.org f.ns.spamhaus.org g.ns.spamhaus.org m.ns.spamhaus.org n.ns.spamhaus.org q.ns.spamhaus.org t.ns.spamhaus.org w.ns.spamhaus.org x.ns.spamhaus.org y.ns.spamhaus.org z.ns.spamhaus.org $NS 86400 c.ns.spamhaus.org $NS 86400 e.ns.spamhaus.org $NS 86400 f.ns.spamhaus.org $NS 86400 g.ns.spamhaus.org $NS 86400 m.ns.spamhaus.org $NS 86400 n.ns.spamhaus.org $NS 86400 q.ns.spamhaus.org $NS 86400 t.ns.spamhaus.org $NS 86400 w.ns.spamhaus.org $NS 86400 x.ns.spamhaus.org $NS 86400 y.ns.spamhaus.org $NS 86400 z.ns.spamhaus.org
So people who want them can also load them up.
They are not needed for rbldnsd to function however.
Bye, Raymond.
On Wednesday, April 28, 2004, 12:40:57 AM, Raymond Dijkxhoorn wrote:
Hi!
sbl-xbl -r/var/named/spamhaus -t21600 -c60 -b127.0.0.1/230 \ sbl-xbl.spamhaus.org:ip4set:sbl \ sbl-xbl.spamhaus.org:ip4set:xbl \
Hmm, what does that mean in terms of the presence of $SOA and $NS in each rbldnsd zone file? Do those help or hurt what you do above?
I dont use them, but they also supply:
[root@vmx01 spamhaus]# more xbl-extras $SOA 3600 need.to.know.only. hostmaster.spamhaus.org. 0 1h 10m 5d 1200 $NS 86400 a.ns.spamhaus.org c.ns.spamhaus.org e.ns.spamhaus.org f.ns.spamhaus.org g.ns.spamhaus.org m.ns.spamhaus.org n.ns.spamhaus.org q.ns.spamhaus.org t.ns.spamhaus.org w.ns.spamhaus.org x.ns.spamhaus.org y.ns.spamhaus.org z.ns.spamhaus.org $NS 86400 c.ns.spamhaus.org
...
$NS 86400 y.ns.spamhaus.org $NS 86400 z.ns.spamhaus.org
(Any ideas why they list c through z twice?)
So people who want them can also load them up.
They are not needed for rbldnsd to function however.
Hmm, that's pretty much what Mark Reynolds was asking for earlier: rbldnsd headers and domains supplied separately.
Should we perhaps offer them separately also, in addition to the existing complete rbldnsd zone files?
I suppose our "extras" could include the testpoints and @ record, as in (basically the top of the file but not the spam domains):
$SOA 600 ns1.freeapp.net zone.surbl.org 1083137775 600 300 604800 600 $NS 600 ns1.surbl.org ns2.surbl.org ns3.surbl.org ns4.surbl.org ns5.surbl.org ns 6.surbl.org ns7.surbl.org ns8.surbl.org ns9.surbl.org ns10.surbl.org ns11.surbl. org ns12.surbl.org ns13.surbl.org ns14.surbl.org :127.0.0.2:Message body contains SpamCop spamvertised domain. @ 66.170.2.60 test.surbl.org :2:sc.surbl.org permanent test point test.sc.surbl.org :2:sc.surbl.org permanent test point surbl-org-permanent-test-point.com :2:sc.surbl.org permanent test point 2.0.0.127 :2:sc.surbl.org permanent test point
We could name such new files with something like:
sc.surbl.org.headers.rbldnsd sc.surbl.org.domains.rbldnsd
Jeff C.
Hi!
[root@vmx01 spamhaus]# more xbl-extras $SOA 3600 need.to.know.only. hostmaster.spamhaus.org. 0 1h 10m 5d 1200 x.ns.spamhaus.org y.ns.spamhaus.org z.ns.spamhaus.org $NS 86400 c.ns.spamhaus.org
...
$NS 86400 y.ns.spamhaus.org $NS 86400 z.ns.spamhaus.org
(Any ideas why they list c through z twice?)
If i am right the old format only supported one NS at a line. But in new rbldnsd ones thats not needed anymore.
They are not needed for rbldnsd to function however.
Hmm, that's pretty much what Mark Reynolds was asking for earlier: rbldnsd headers and domains supplied separately.
Should we perhaps offer them separately also, in addition to the existing complete rbldnsd zone files?
Wont harm.
I suppose our "extras" could include the testpoints and @ record, as in (basically the top of the file but not the spam domains):
I would leave those in the zonefile itself, the extra is 'unneeded' data like NS sets.
6.surbl.org ns7.surbl.org ns8.surbl.org ns9.surbl.org ns10.surbl.org ns11.surbl. org ns12.surbl.org ns13.surbl.org ns14.surbl.org :127.0.0.2:Message body contains SpamCop spamvertised domain. @ 66.170.2.60 test.surbl.org :2:sc.surbl.org permanent test point test.sc.surbl.org :2:sc.surbl.org permanent test point surbl-org-permanent-test-point.com :2:sc.surbl.org permanent test point 2.0.0.127 :2:sc.surbl.org permanent test point
We could name such new files with something like:
sc.surbl.org.headers.rbldnsd sc.surbl.org.domains.rbldnsd
Please dont change the curent names, only add .extra for the new one.
Bye, Raymond.