Re: DNSSEC basic information
Evan Hunt answers Jukka Pakkanen: > In newer releases there's also a configuration option, "validate-except", > which permanently disables validation below specified domains. This can > be used, for example, if you have an internal network using a fake TLD > and you want to prevent it from showing up as bogus. ... and in a separate message, John W. Blue wrote: > 1. DNSSEC was designed for external zones I have a case where I recently had to use "validate-except" because of a domain (not mine) whose external view is signed but not the internal view; my resolver gets the internal view for that zone. Can someone enlighten me as to why "DNSSEC was designed for external zones", and under what circumstances it makes sense to *not* sign an internal view? It seems to me that it would be most consistent to sign both external and internal views. Anne. -- Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8 a...@encs.concordia.ca+1 514 848-2424 x2285 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Modifying data files while named is reloading
Laurent Weislo writes: > After a bunch of years and under heavy load on the master, we lost almost > 4K records because the domain file seems to have been loaded while being > generated. Wouldn't the best solution be to modify your generation process to write to temporary files, and then to move them into place when fully built, rather than leaving significant amounts of time during which your zone file is in a partially built state? Anne. -- Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8 a...@encs.concordia.ca+1 514 848-2424 x2285 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Concatenating more RPZ zones?
>> i have this situation with RPZ zones (and can grow up with more RPZ zones): > > If no-one has replied, it's possible no-one knows the answer. The latest draft of the RPZ specification is: https://tools.ietf.org/html/draft-vixie-dns-rpz-04 I see nothing, even in "6.1. Per-Zone Action Overrides", that would do exactly what you want, unfortunately. > On a more helpful note: yes, first RPZ always wins. If you need > different sets of RPZ for different client IP ranges, you will need to > use views. Using views does seem like a possible solution to your problem, though it would entail maintaining client lists in the nameserver configuration instead of the zone files, which would make sense only if your list of exceptions is very stable. Anne. -- Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8 a...@encs.concordia.ca+1 514 848-2424 x2285 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS view "passthrough" and caching
Mark Andrews <ma...@isc.org> answers "Vladimir-M. Obelic" <vobe...@gbit6.net>:
> Use 'zone "zonename" { in-view "namename"; };' and have all zones
> that the view answers for be in that view. "in-view" was introduced
> in BIND 9.10.0. Configure the zone (master/slave) in the first
> view it appears in.
In that scenario, could one define the first view to match
no clients but contain all the needed zones, then in each
subsequent ("real") view, use the in "in-view" construct to
pull in the zones appropriate for that view?
Anne.
--
Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8
a...@encs.concordia.ca+1 514 848-2424 x2285
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: *Reminder of the* L-Root IPv6 address renumbering
John Bond <b...@johnbond.org> writes: > This is reminder that there is a scheduled change to the IPv6 > addresses for the L-Root server, that will take effect on > March 23, 2016. > > The new IP addresses for the L.ROOT-SERVERS.NET will be: > > 199.7.83.42 > 2001:500:9f::42 ftp://ftp.internic.net/domain/named.cache is still dated Feb 17 and still shows 2001:500:3::42 for L's IPv6 address. Is there any intention to update that? Anne. -- Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8 a...@encs.concordia.ca+1 514 848-2424 x2285 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: SERVFAIL on stub zone (WAS: dig @server foobar +trace +recurse)
Tony Finch suggested:
(I'm syslogging default syslog_all, minus edns-disabled,
lame-servers, rpz, and unmatched.)
Excluding lame-servers might be why you aren't seeing any log
messages.
I tried un-excluding it: nothing.
zone concordia.ca {
type stub;
file StubData/concordia.ca.SEC;
masters {
132.205.1.1 ;
132.205.7.51 ;
};
multi-master yes;
};
[results in transferring:]
--
$ORIGIN .
$TTL 86400 ; 1 day
concordia.caIN SOA ns1.concordia.ca. hostmaster.concordia.ca. (
2028969738 ; serial
43200 ; refresh (12 hours)
1800 ; retry (30 minutes)
2592000; expire (4 weeks 2 days)
1800 ; minimum (30 minutes)
)
NS ns1.concordia.ca.
NS ns2.concordia.ca.
--
[but querying it for NS gives SERVFAIL]
Midnight insight: glue records??? The two listed NS are below the
zone cut. How can a stub zone work in those circumstances, if at all?
I think I'm onto something; with the above stub zone for
concordia.ca (which transfers information listing two NS
records as ns1.concordia.ca and ns2.concordia.ca but no glue
records), I get SERVFAIL (after a clean start of named).
And in that circumstance, the other two stub zones I have set up
(for the IPv4 and IPv6 reverse zones for my parent networks) also
transfer the same set of two NS records, and also fail.
If I comment out the stub zone for concordia.ca, but leave
in the two reverse IP stub zones, then these two zones work
correctly: when I query for NS, they give me ns1.concordia.ca
and ns2.concordia.ca, with their A records in the additional
section.
I think that clinches it: the implementation of stub zones
indeed replicates only the NS records, but not the needed
glue records, so it cannot work in cases where all of the
listed NS are within the zone itself.
It would be a nice enhancement to make the stub zone pick up
glue records. Is this something I should report separately?
Meanwhile, I'll try a static-stub zone for this case...
Tony Finch has also suggested:
Try rndc trace 10. The debug logs are written to named.run (not
syslog) by default.
After a bit of tweaking of my logging configuration, I was
able to get the trace output. I append it (for a query on
the NS records of concordia.ca, with the stub zone in effect),
in case it is of use to anyone.
Anne.
Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8
a...@encs.concordia.ca+1 514 848-2424 x2285
---
15-Jul-2015 14:54:47.342 debug level is now 10
15-Jul-2015 14:54:47.353 client 127.0.0.1#57060: UDP request
15-Jul-2015 14:54:47.353 client 127.0.0.1#57060: using view '_default'
15-Jul-2015 14:54:47.353 client 127.0.0.1#57060: request is not signed
15-Jul-2015 14:54:47.353 client 127.0.0.1#57060: recursion available
15-Jul-2015 14:54:47.353 client 127.0.0.1#57060: query
15-Jul-2015 14:54:47.353 client 127.0.0.1#57060 (concordia.ca):
ns_client_attach: ref = 1
15-Jul-2015 14:54:47.353 client 127.0.0.1#57060 (concordia.ca): query
'concordia.ca/NS/IN' approved
15-Jul-2015 14:54:47.353 client 127.0.0.1#57060 (concordia.ca): replace
15-Jul-2015 14:54:47.353 clientmgr @0x2b31f95c2458: get client
15-Jul-2015 14:54:47.353 clientmgr @0x2b31f95c2458: recycle
15-Jul-2015 14:54:47.353 fetch: concordia.ca/NS
15-Jul-2015 14:54:47.353 client @0x2b31fc0dfa60: udprecv
15-Jul-2015 14:54:47.353 fctx 0x2b3204c7f010(concordia.ca/NS): create
15-Jul-2015 14:54:47.353 log_ns_ttl: fctx 0x2b3204c7f010: fctx_create:
concordia.ca (in 'concordia.ca'?): 1 86400
15-Jul-2015 14:54:47.353 fctx 0x2b3204c7f010(concordia.ca/NS): join
15-Jul-2015 14:54:47.353 fetch 0x2b31f5babd18 (fctx
0x2b3204c7f010(concordia.ca/NS)): created
15-Jul-2015 14:54:47.353 fctx 0x2b3204c7f010(concordia.ca/NS): start
15-Jul-2015 14:54:47.353 fctx 0x2b3204c7f010(concordia.ca/NS): try
15-Jul-2015 14:54:47.353 fctx 0x2b3204c7f010(concordia.ca/NS): cancelqueries
15-Jul-2015 14:54:47.353 fctx 0x2b3204c7f010(concordia.ca/NS): getaddresses
15-Jul-2015 14:54:47.354 fetch: ns1.concordia.ca/A
15-Jul-2015 14:54:47.354 fctx 0x2b3204cc0010(ns1.concordia.ca/A): create
15-Jul-2015 14:54:47.354 log_ns_ttl: fctx 0x2b3204cc0010: fctx_create:
ns1.concordia.ca (in 'concordia.ca'?): 1 86400
15-Jul-2015 14:54:47.354 fctx 0x2b3204cc0010(ns1.concordia.ca/A): join
15-Jul-2015 14:54:47.354 fetch 0x2b31f5babd78 (fctx
0x2b3204cc0010(ns1.concordia.ca/A)): created
15-Jul-2015 14:54:47.354 dns_adb_createfind: started A fetch for name
ns1.concordia.ca
SERVFAIL on stub zone (WAS: dig @server foobar +trace +recurse)
Tony Finch d...@dotat.at enlightens me thus:
The difference between stub and static-stub is that stub works like the
root zone hints, i.e. the servers in the zone override the ones that you
configure for a stub zone, whereas the servers you configure for a
static-stub zone override the servers in the zone.
... so, since I want my parent zone to be able to give me the
set of servers it wants me to use, I configured my resolver
to have (this snippet from named-checkconf -p to deal with
include files and such):
zone concordia.ca {
type stub;
file StubData/concordia.ca.SEC;
masters {
132.205.1.1 ;
132.205.7.51 ;
};
multi-master yes;
};
named-checkconf gave no errors. I issued a reconfig, again
no errors logged or reported. I can confirm that the zone was
transferred correctly (showing me the internal view), because
I have masterfile-format text as a general option (small
enough number of zones that performance is not an issue, but
human ability to debug *is*), and StubData/concordia.ca.SEC
contains a perfectly normal-looking zone stub:
--
$ORIGIN .
$TTL 86400 ; 1 day
concordia.caIN SOA ns1.concordia.ca. hostmaster.concordia.ca. (
2028969738 ; serial
43200 ; refresh (12 hours)
1800 ; retry (30 minutes)
2592000; expire (4 weeks 2 days)
1800 ; minimum (30 minutes)
)
NS ns1.concordia.ca.
NS ns2.concordia.ca.
--
It all looks just peachy, but when I issued:
dig @localhost -t ns concordia.ca.
it gave me a SERVFAIL. I couldn't find anything abnormal
in the syslogs. I can't for the life of my figure out why
it's unhappy. How can I debug this? Is it normal that a
zone could be badly enough out of whack to SERVFAIL, yet
the named would syslog nothing?
(I'm syslogging default syslog_all, minus edns-disabled,
lame-servers, rpz, and unmatched.)
Anne.
--
Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8
a...@encs.concordia.ca+1 514 848-2424 x2285
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: SERVFAIL on stub zone (WAS: dig @server foobar +trace +recurse)
zone concordia.ca {
type stub;
file StubData/concordia.ca.SEC;
masters {
132.205.1.1 ;
132.205.7.51 ;
};
multi-master yes;
};
[results in transferring:]
--
$ORIGIN .
$TTL 86400 ; 1 day
concordia.caIN SOA ns1.concordia.ca. hostmaster.concordia.ca. (
2028969738 ; serial
43200 ; refresh (12 hours)
1800 ; retry (30 minutes)
2592000; expire (4 weeks 2 days)
1800 ; minimum (30 minutes)
)
NS ns1.concordia.ca.
NS ns2.concordia.ca.
--
[but querying it for NS gives SERVFAIL]
Midnight insight: glue records??? The two listed NS are below the
zone cut. How can a stub zone work in those circumstances, if at all?
Anne.
--
Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8
a...@encs.concordia.ca+1 514 848-2424 x2285
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: dig @server foobar +trace +recurse
Tony Finch d...@dotat.at recommends:
As for the problem itself, I'll probably fix it by setting up
a forwarding zone for my parent zone on my resolvers, to make
sure that I always get the internal view for their data.
Note that the target server of a forward zone should offer recursive
service. You will have problems if the target is authoritative-only, and
serves the zone you are forwarding but not some child zone.
It does offer recursion, but your suggestion is most helpful nevertheless:
Better to use
static-stub in that case; that makes BIND do normal iterative resolution
except it overrides the NS records for just that zone, not its children.
Good point; I want queries for its children (my zones!) to be answered
by my resolvers (which are authoritative for my zones).
(We make our recursive servers authoritative for our zones to avoid
problematic dependency cycles - the kind of horror you find out about
when trying to recover from a power outage.)
Indeed. Here we're blessed with having had a long-duration
(days!) planned power outage lately for major electrical work,
so my careful redundancy planning has been well tested. :-)
The local resolvers are totally standalone - no dependencies
on directory services, NFS, or anything but the presence of
the local network and power.
Now back to the static-stub zones... reading the ARM, I see that
I cannot use server-names because the internal-view servers
for my parent zone are in the zone itself, thus I must use
server-addresses. But I'm told that if I specify:
zone example.com {
type static-stub;
allow-query { APPROPRIATE_ACL_HERE };
server-addresses { 192.0.2.1; 192.0.2.2; };
};
then the following RR's are internally configured:
example.com. NS example.com.
example.com. A 192.0.2.1
example.com. A 192.0.2.2
But my parent (call it example.com) *has* an A record;
they use it for their web server, I believe. Will the above
internally configured A RR not interfere with getting the
correct data for host -t a example.com? Or does the sentence
These records are internally used to resolve names under the
static-stub zone imply that they are used *only* for this
purpose, and never leaked out?
I guess I can test that in any case; just being paranoid!
Thanks for your suggestion; static-stub is indeed a better solution.
Anne.
--
Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8
a...@encs.concordia.ca+1 514 848-2424 x2285
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: dig @server foobar +trace +recurse
For my part, I'd be curious to know what sort of problem you're trying to solve with dig. Oh, I solved it. I was getting different data for my parent zone depending where I queried from, but the differences didn't match what I expected based on an internal/external view classification of the client resolver. I eventually realized that for the data I was examining, my resolvers (which have access to the outside world) could randomly select an external authoritative nameserver for my parent zone (external view), or an internal one (internal view), hence the difference. And of course there was caching involved as well, so data seemed to toggle randomly back and forth on my various resolvers. It's by tracing the queries down from the root zone several times with dig +trace that it finally hit me what was going on, and in retrospect it's obvious. At first I had been looking for some kind of race condition with delegation data from the grandparent zone getting cached, and then being overridden by my parent zone's own NS records. At that point, I was trying to use @server to try to affect that server's cache by forcing it to pull certain data into its cache. But it turns out that it isn't a child overriding its parents delegations that was the problem; it's the fact that as an internal client, I am able to access external views as well. And in the process of investigating all this, I realized that of course if I use +trace, all queries after the first one will *not* use the @server. Duh. I just thought I might save someone else the muddy thinking by offering a clarification for the manpage. As for the problem itself, I'll probably fix it by setting up a forwarding zone for my parent zone on my resolvers, to make sure that I always get the internal view for their data. We might be able to shed a little more light on what the best command would be for you. It all worked fine when I stopped barking up the wrong tree. ;-) The +recurse gets overridden when you use +trace: +[no]recurse ... Recursion is automatically disabled when the +nssearch or +trace query options are used. so you're getting iterative queries whether you want them or not: +trace means you're treating yourself as a recursive nameserver, Yes; an overly quick reading of the docs on my part. I was trying to treat myself as a recursive nameserver, so I stuck in +recurse, which was the wrong thing to do - fortunately it didn't work. ;-) If you send a single query to a remote nameserver, you're only going to get a single response--that's how DNS works. So if you're looking to see the chain of lookups that a remote recursive nameserver takes to reach its final response, you can run dig +trace from the remote nameserver, or you could run a series of dig @server +norecurse hostname queries to get what you're looking for. Right; I wanted the former, and that's what, despite myself, I got. That's what comes from not looking seriously at DNS stuff for months at a time and then trying to reload a lot of context all at once! I admit ignorance on the +showsearch option: I'm not seeing the query flags change, nor am I seeing any different output when I run: dig @8.8.8.8 trombone.org +showsearch [...] versus dig @8.8.8.8 trombone.org [...] Does anyone have insight on +showsearch, I'm sure someone does, but it's not me - I've bumped into enough walls for one day! :-) Anne. -- Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8 a...@encs.concordia.ca+1 514 848-2424 x2285 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
dig @server foobar +trace +recurse
I've been trying to debug a problem with dig, and it has finally occurred to me that, if I understand this correctly, the +trace option essentially overrides the @server specification, except for the initial query for the root zone nameservers. (I was using +showsearch +trace +recurse.) Is my understanding correct? If it is, it might be helpful to add a quick note to the dig manpage, perhaps under SIMPLE USAGE, server, something like: Note that if when the +trace and +recurse options are in use, only the initial query for the root zone uses the server specified by server (or in /etc/resolv.conf); subsequent queries use the authoritative servers in the chain of delegation. Anne. -- Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8 a...@encs.concordia.ca+1 514 848-2424 x2285 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dig @server foobar +trace +recurse
Mark Andrews ma...@isc.org responds to my suggestion: [...] the +trace option essentially overrides the @server specification, except for the initial query for the root zone nameservers. [...] Is my understanding correct? If it is, it might be helpful to add a quick note to the dig manpage, perhaps under SIMPLE USAGE, server, something like: [deleted] Given +trace isn't simple usage (dig @server name type), why would one say that in the simple usage section? Fair enough, and well taken; I can modify my suggestion. +trace states that it is going to talk to each server in turn. Very true, and very painfully obvious in retrospect, but while I was in the throes of trying to figure out my problem, this managed to somehow escape me for quite a while. It would still be nice to clarify it to avoid other people having the same problem. How about this: +[no]trace Toggle tracing of the delegation path from the root name servers for the name being looked up. Tracing is disabled by default. When tracing is enabled, dig makes iterative queries to resolve the name being looked up. It will follow referrals from the root servers, showing the answer from each server that was used to resolve the lookup. If @server is also specified, it affects only the initial query for the root zone name servers. +dnssec is also set when +trace is set to better emulate the default queries from a nameserver. Anne. -- Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8 a...@encs.concordia.ca+1 514 848-2424 x2285 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: How reliable is RPZ in production? I'm seeing flakiness in testing.
John, thanks for helping.
You might start things out by giving us your bind version
9.10.1-P1
and your response-policy {} config.
response-policy {
zone rpz-whitelist policy given;
zone rpz-quarantine policy given;
zone rpz-phish policy given;
zone rpz-malware policy given;
zone rpz-isc-suspicious policy given;
zone rpz-mwdoms-doms policy given;
zone rpz-mwdoms-hostspolicy given;
};
At the moment, only the first four contain any records
aside from SOA and NS.
Also print out the exact rules (one or two
examples should suffice) you're using for client quarantining --
that'll help narrow things down.
rpz-whitelist has QNAME/passthru entries for names in
my domain and for patch sites. It also has rpz-ip/passthru
entries for IP addresses of the same. To show a few examples,
first for our University's public network:
concordia.caCNAME rpz-passthru.
*.concordia.ca CNAME rpz-passthru.
205.132.in-addr.arpaCNAME rpz-passthru.
*.205.132.in-addr.arpa CNAME rpz-passthru.
16.0.0.205.132.rpz-ip CNAME rpz-passthru.
... and for a patch site:
12.0.0.0.23.rpz-ip CNAME rpz-passthru. ; Akamai
(Note that I added the in-addr.arpa lines just lately, and
haven't re-run the tests with those in place, but those weren't
the names I was testing for; I was testing with nslookup.)
rpz-quarantine had, when I was testing, my workstation's address:
32.192.47.205.132.rpz-client-ip CNAME serv-quarantine.encs.concordia.ca.
rpz-phish and rpz-malware have a few test entries, for example:
nonexistent.porcupine.caCNAME serv-fishnet.encs.concordia.ca.
*.nonexistent.porcupine.ca CNAME serv-fishnet.encs.concordia.ca.
emaillimitedequota.yolasite.com CNAME serv-fishnet.encs.concordia.ca.
*.emaillimitedequota.yolasite.com CNAME serv-fishnet.encs.concordia.ca.
Also, how are you publishing to your
client quarantine zones? Presumably you're using some sort of DDNS
publishing that gets triggered when a client does something
suspicious.
No, actually, so far it's all manual (edit the zone file and
issue a reload), and the first four will remain that way.
The last three will contain data we obtain automatically from
offsite, but my download-parse-update-reload script will do
essentially the same as my manual operation. We don't use
DDNS at all.
I'm going to re-run my tests with a fresh mind (I last tested
before I took a vacation in December, and I needed that
vacation!), though I find it hard to see what I could possibly
have done wrong that would have the nameserver changing its
responses to me without the data having been touched.
I'll report back with my new test results.
Anne.
--
Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8
a...@encs.concordia.ca+1 514 848-2424 x2285
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
How reliable is RPZ in production? I'm seeing flakiness in testing.
Happy New Year, folks. I posted last December to dnsfirewalls, but I'm told that RPZ is no longer particularly new, and I'd be more likely to get feedback here. So here goes... I'm playing with RPZ with a view to both quarantining internal compromised or vulnerable hosts, and capturing attempts at communication with known external bad hosts. I start with a fairly extensive whitelist, to avoid lying about any of my own hosts, and to give truthful answers for patch sites, so that my users can patch their systems even when otherwise quarantined. The masters for my RPZs do not themselves use the zones for policy (nor do they recurse on queries). However the nameservers that do recursive resolution for my network are slaves for those RPZs, and *do* use them for policy. My set-up works, but sporadically - it's as though the RPZs wink in and out of use for no apparent reason, even when I'm not changing the data. At one point while testing last December, my by-client-IP test quarantine rule just stopped matching (based on no logged hits, and no redirection of my queries from the quarantined host). Only a restart of named on the resolver brought the quarantine back, but then the whitelist worked only partially. I don't know what to make of this; it looks as though the technology is several years old, and my experience with ISC bind is usually excellent. Has anyone else encountered this type of flakiness? If not, any advice about how to debug this? Anne. -- Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8 a...@encs.concordia.ca+1 514 848-2424 x2285 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
