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 int
s, 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
ion 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, Mon
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.
--
/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
7;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 o
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
ife 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 unma
ot 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 a
norance 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,
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,
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.conc
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
ought 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
14 matches
Mail list logo
