new, but seems always to be the same
as the later query name. What is it for? If it meant to be the name of the
client it has got it horribly wrong!
The ARM for 9.9.0rc1 still describes the old format.
--
Chris Thompson
Email: c...@cam.ac.uk
___
Please
invalid" as the SOA.rname, but BIND
still uses "." for empty zones (apparently even in 9.9.0rc1). I imagine
we will change that if/when BINS does.
--
Chris Thompson
Email: c...@cam.ac.uk
___
Please visit https://lists.isc.org/mailman/listin
27;t really meant to perform this experiment
at this time... it happened as a result of specifying a set of key
publication and activation times in January 2011 when January 2012
was intended :-)
--
Chris Thompson
Email: c...@cam.ac.uk
___
Please visit h
han my one from RFC 1035. How did I miss it?
Well, it turns out that the word "two" above occurs at the beginning of a
line in rfc1034.txt, and I was searching for the string " two" ... :-(
[Too many false drops if you search for just the three-character string,
because of
"How many secondaries?":
| The DNS specification and domain name registration rules require at
| least two servers for every zone.
before going on to recommend more than two in most cases.
--
Chris Thompson
Email: c...@cam.ac.uk
___
Please visit h
"gov", just because the early reports were from the
US and no-one around here seems to have had their recursive nameservers
crash. [We upgraded to BIND 9.8.1-P1 anyway, of course.]
--
Chris Thompson
Email: c...@cam.ac.uk
___
Please visit
the new raw format (e.g. as a result
of dynamic updates), then one would have a problem backing off to earlier
BIND versions?
--
Chris Thompson
Email: c...@cam.ac.uk
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscr
gorithm represented in the DNSKEY RRset: at least one KSK
| and one ZSK per algorithm. If there is any algorithm for which this
| requirement is not met, this option will be ignored for that algorithm.
--
Chris Thompson
Email: c...@cam.ac.uk
___
Please visit
subject to negotiation!) to provide automatic scaling
according to the size of the zone.
Do other people have this problem? Any other ideas?
--
Chris Thompson
Email: c...@cam.ac.uk
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubsc
ry to perform an RFC 5011
rollover on it, using dnssec-revoke and/or the -R option of dnssec-settime,
meanwhile tracking it on another system via a managed-keys entry, but then
if it all went pear-shaped it might not be clear whether I had performed
the rollover correctly or not.
--
Chris Thompson
E
y's ad hoc command into something publishable,
it would be better to use
dig +nocmd +nostats +onesoa AXFR zone | awk ...
(although for +onesoa you need the dig from BIND 9.8 or later).
--
Chris Thompson
Email: c...@cam.ac.uk
___
Please visit https://lists.
quot;relative" (to the zone) or "non-absolute" rather than
"unqualified" there. Also, don't do this if you are using dynamic updates
on either zone, or the shared zone file will end up in a horrible mess.
--
Chris Thompson
Email: c...@cam.ac.uk
__
fetch from B" is acyclic.
Otherwise servers can get into the state that A thinks its copy of the
zone is up to date because B told it so, and B thinks so because A told
it so (or longer loops, of course), while neither of them are true masters
for it.
On Nov 2 2011, Jan-Piet Mens wrote:
Note, the new .XXX TLD is included in that list.
Does that mean it is or isn't safe for work? ;-)
It depends on whether the XXX TLD acquires a signed delegation or not.
(Presumably it should, as you wouldn't want to get the *wrong* porn ...)
imes, however, a slave is listed as the SOA MNAME in
| hidden master configurations and in that case you would want the
| ultimate master to still send NOTIFY messages to all the nameservers
| listed in the NS RRset.
--
Chris Thompson
Email: c...@cam.ac.uk
_
ons:
use-v4-udp-ports { range 32768 65535; };
use-v6-udp-ports { range 32768 65535; };
This is the same as the (default) anonymous port range.
--
Chris Thompson
Email: c...@cam.ac.uk
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to
27;t respond)
rather than 116.197.146.5.
--
Chris Thompson
Email: c...@cam.ac.uk
___
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
refers to redirecting names that are being used
for evil purposes to e.g. a local monitoring station - not the same thing
at all.
--
Chris Thompson
Email: c...@cam.ac.uk
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from
egal) nor one in the parent would have the effect of
a "CNAME at the apex".
A *CNAME* in the parent would, but only as long as you didn't mind
losing all the rest of the zone.
2. Use a A (and other records as needed) instead of a CNAME.
This is, of course, the usual solution.
--
C
quite
seriously about using it for the re-implementation of the hidden master
for our "managed zone service" (for vanity domains, although that's not
how we describe them to the punters), but even there it didn't work out,
primarily for Phil's reasons #5 and #6.
Has anyone any clues about this one? Or observed anything similar?
We never did manage to track down exactly what was wrong with the
NSEC3 records, but the problem seems to have been cured by the zone
signer being upgraded from OpenDNSSEC 1.2.1 to 1.3.2.
--
Chris Thompson
Email:
while you are at it).
Use update operations for (very nearly) everything.
[*] in the absence of my long-sig, which I don't use on this list:
"we" is the University Computing Service in the University of
Cambridge, England.
--
Chris Thompson
Email: c...@cam.ac.uk
___
all types of
queries, I would perform calculations on this number, correct?
If you are interested in queries per second sent to the nameserver,
yes. (This doesn't of course necessarily mean queries successfully
responded to from the client
ut this one? Or observed anything similar?
--
Chris Thompson
Email: c...@cam.ac.uk
___
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/mailma
On Sep 6 2011, Mark Andrews wrote:
[...]
Named doesn't yet have the ability to disable DNSSEC validation
for specified namespaces.
"Yet"? Is there a hint of a future change there?
--
Chris Thompson
Email: c...@cam.ac.uk
___
Ple
ional".
--
Chris Thompson
Email: c...@cam.ac.uk
___
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
'empty-zones-enable/disable-empty-zone' not set:
disabling RFC 1918 empty zones
Apologies for going into nitty detail here, but their half-way status
isn't described in the ARM (yet?) and I had to work it out for myself ...
--
Chris Thompson
Email: c...@cam.ac.uk
_
's default cutoff value of 3 hours can be altered by using
max-ncache-ttl option if you need to.
--
Chris Thompson
Email: c...@cam.ac.uk
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users ma
d instead would work, but of course what
is really needed is to get the delegation in step with the zone itself.
Having more than one nameserver for the zone wouldn't be a bad idea,
either ...
--
Chris Thompson
Email: c...@cam.ac.uk
__
er,
reflecting a belief that (a) it would be misused and/or (b) even local
zones should be signed anyway?
--
Chris Thompson
Email: c...@cam.ac.uk
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users ma
rted it to dnsad...@dell.com on 28 June. Deafening silence.
They should be returning "nodata" rather than NXDOMAIN for the
query, of course.
--
Chris Thompson
Email: c...@cam.ac.uk
___
Please visit https://lists.isc.org/mailman/listinfo/bind-
On Jul 16 2011, Evan Hunt wrote:
BIND 9.8.1b3 is the third beta release of BIND 9.8.
I am a bit intrigued by this entry in the CHANGES file
3133. [bug] Change #3114 was incomplete. [RT #24577]
as I can't find a reference to #3114 or RT #24577 anywhere else...
--
g bind9.xsl from the distribution into the top level
of the DOCUMENTROOT, but it's nigglingly annoying.
So is there anything that could go wrong if the style sheet reference *was*
relative rather than absolute?
--
Chris Thompson
Email: c...@cam.ac.uk
_
Now that RFC 6303 <http://www.rfc-editor.org/rfc/rfc6303.txt> has been
published, and includes the fourteen RFC 1918 reverse zones (section 4.1),
can we expect future versions of BIND to have them as automatic empty
zones - i.e. the "#ifdef notyet" in bin/named/server.c to disa
date -l" (see the ARM
for details). BIND always writes a new session key at startup whether
it's going to be used or not. If you don't want it, and it is trying to
write it somwehere it can't, specify an alternative writable location
(e.g. in BIND's working directory) with &q
there was
delay of over 3 hours between webster receiving the message and passing
it on.
--
Chris Thompson
Email: c...@cam.ac.uk
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
nerally available at
this time. Black hats are, after all, listening to us.)
Upgrade, in any case, if you can.
--
Chris Thompson
Email: c...@cam.ac.uk
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bin
. NS ns2.foo.com.
Neither seems to to need glue in either "com" or "net", but without
either the domains cannot be resolved. This was a significant issue
when VeriSign changed the way the *.gltd-servers.net responded last
year.
--
Chris Thompson
Email: c...@cam.ac.uk
7-Jun-2011
That's just a peculiarity of whois.nic.uk. It only understands (acceptable)
3rd-level domain names under the 2nd-level ones that Nominet manage.
There are 18 sub-domains of "uk", only 8 of which are managed by Nominet.
"nhs.uk" is one of the othe
nt16 + uint8) but you
only checked there is place for two bytes, which is the bug.
Yes - I really should have seen that! And of course, when I look back
at what my source at ISC (sorry, Evan) *actually* said, those lines
*were* all included.
--
Chris Thompson
Email: c...@cam.ac.uk
___
rtainly have that code.
--
Chris Thompson
Email: c...@cam.ac.uk
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
ce of the CNAME ns.il does not
affect the perfectly good A record for (e.g.) nse.ns.il in any way.
--
Chris Thompson
Email: c...@cam.ac.uk
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
To follow up on this thread (there's been much more about it on DNS-OARC
than here), it was a bug that is fixed (change 3020) together with the
more serious security problem (change 3121) in the new BIND versions
9.6-ESV-R4-P1, 9.7.3-P1 and 9.8.0-P2.
--
Chris Thompson
Email: c...@cam.
absolutely no clarification from the Original Poster
as to what the he was on about, I suggest speculation on this
point is moot.
--
Chris Thompson
Email: c...@cam.ac.uk
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
of course.
--
Chris Thompson
Email: c...@cam.ac.uk
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
oddities:
dig +dnssec dnskey [zone] gives the right answer *without* the ad bit
dig +dnssec soa [zone] gives SERVFAIL, unless +cd is used as well.
--
Chris Thompson
Email: c...@cam.ac.uk
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
23 -> ZSK with tag 4814), should it?
It may be significant that this problem was reported to us on the same
day that obscured DNSKEY records were introduced into the "de" zone...
--
Chris Thompson
Email: c...@cam.ac.uk
___
bind-users mailing
readable versions in the .key files are in the timezone in
which dnssec-keygen or dnssec-settime was run ... which might not be
the same as that on the nameserver on which they are subsequently
deployed.
But only the numeric UTC versions have any effect on the actual behavior
of BIND.
--
Chr
.131.in-addr.arpa) do now have DNSSEC chains of trust all the way
from the root zone. But I haven't removed their entries from dlv.isc.org
yet, and in fact am still quite undecided as to when it will be
appropriate to do so.
--
Chris Thompson
Email: c...@cam.ac.uk
th the modification times of the
master files. But sadly, it didn't ...
--
Chris Thompson
Email: c...@cam.ac.uk
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
oot hints (compiled in or otherwise), not
by using the OS resolver.
--
Chris Thompson
Email: c...@cam.ac.uk
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
even in 9.8.0, without source
modifications)? Referencing RFC 3330 muddies the issue even more, as most
of the addresses listed there, *except* the RFC 1918 ones, *are* covered
by automatic empty zones.
I think ISC need to do a bit of work on the documentation here.
--
Chris Thompson University
"dig +dnssec ns whitehouse.gov" and you should see
the ad flag. (Anyway, it's working for me at the moment.)
Or even "dig +dnssec cname www.whitehouse.gov". The CNAME is signed,
its target isn't.
--
Chris Thompson
Email: c...@cam.ac.uk
_
OTOH, journal files are updated in place, as well as new versions being
created and renamed when they are shortened.
--
Chris Thompson
Email: c...@cam.ac.uk
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
rpa | tail -1 | awk '{print $1}'
Oh, yuck. There is a perfectly good program shipped with BIND to do this:
$ type arpaname
arpaname is /usr/local/sbin/arpaname
$ arpaname 2001:7b8:c05::80:1
1.0.0.0.0.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.0.C.0.8.B.7.0.1.0.0.2.IP6.ARPA
--
Chris Thompson
E
sing your favorite shell.
The real answer to the OP, I'm afraid, is RTFM. The (horrible) syntax
of nslookup option settings is perfectly well described in its man page.
--
Chris Thompson
Email: c...@cam.ac.uk
___
bind-users mailing list
bind-users@
d referral. Distinguishing these is a sensitive business,
as RFC 2308 section 2.2 explains.
--
Chris Thompson
Email: c...@cam.ac.uk
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
to check it contains what you hope for.
If those look OK, then it's something else in the configuration of
either master or slaves. I take it you aren't doing anything as
obvious as specifying "request-ixfr no" or "provide-ixfr no" in
server statements.
--
Chris Thompson
eping"
threads, but I would like to know what, exactly, those threads do.
This is standard in any threaded BIND - it isn't specific to your OS.
There are $N worker threads and 3 overhead/management ones. I wouldn't
mind a description of the latter from ISC myself ...
--
Chr
t;dnssec-lookaside auto". It ends up with trust anchors for both
the root and dlv.isc.org, as shown by all of
* rndc secroots
* what appears in managed-keys.bind
* "ad" bit on appropriate "dig +dnssec" calls
which sort of convinces me ... :-)
--
Chris Thompson
Email: c...@c
rue!).
Personally, on production servers, I would rather not rely on what ISC
are doing with this file, but have my own managed-keys statement and
avoid "dnssec-lookaside auto;".
--
Chris Thompson
Email: c...@cam.ac.uk
___
bind-users mailing list
bin
On Feb 14 2011, Chris Buxton wrote:
On Feb 14, 2011, at 6:31 AM, Chris Thompson wrote:
We are running BIND 9.7.2-P3, and update our zones with nsupdate calls
that look like this:
nsupdate -v -k keys/update-key <[input] >/dev/null 2>[errors]
This is run from a Solaris 10_x86 non-glo
dns_dispatch_getudp (v4): permission denied
This seems to strike at random, and goes away on retrying the same
nsupdate call. What's really strange here is that nsupdate is being
told to use TCP (the -v option), so why is it messing around with UDP?
Has anyone else seen this?
--
Chris Thomps
.ac.uk.
preview CNAME cms.admin.cam.ac.uk.
$ORIGIN admin.cam.ac.uk.
could have been replaced by
preview.blogCNAME cms
just as in the latter case.
--
Chris Thompson
Email: c...@cam.ac.uk
___
bind-users mailing list
bind-user
automatically by
a separate script. On the other hand, the relative format is more
human-readable and is thus suitable for editing by hand.
"More" does not mean "very", as you have noticed :-)
--
Chris Thompson
Email: c...@cam.ac.uk
_
ll take it that you
want it to do resigning as the RRSIGs approach expiry.
--
Chris Thompson
Email: c...@cam.ac.uk
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
t; should cure that particular case.
(Well, it worked for us for other TLDs, back when we were still using
9.6.2 last year.)
--
Chris Thompson
Email: c...@cam.ac.uk
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
ory that BIND 8 ever had compiled-in
hints.
--
Chris Thompson
Email: c...@cam.ac.uk
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
On Dec 24 2010, Mark Andrews wrote:
I've extracted the CHANGES files for BIND 9.6.3b1, BIND 9.7.3b1 and
BIND 9.8.0a1 and put them in relevant directories on ftp.isc.org.
Thanks, but ...
It would be helpful if this happened for all new versions.
--
Chris Thompson
Email: c...@cam.
NSKEY" count in the statistics display, but a new request
goes back to the authoritative servers again anyway, as shown by the outgoing
queries count and by the SOA in the authority section of the NODATA response
having its original value.
--
Chris Thompson
Email: c...
I am sure some people like the new Release Notes section in these
announcements (or the RELEASE-NOTES-* files at ftp.isc.bind), but
can we have some easier way of getting hold of the CHANGES file for
a new release than downloading the whole thing and picking it out?
--
Chris Thompson
Email: c
to be rolled
over without a lot of publicity, and the managed-keys code still
has the bug described at
https://lists.isc.org/pipermail/bind-users/2010-October/081399.html
--
Chris Thompson
Email: c...@cam.ac.uk
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
r got anything from ISC.
After upgrading to BIND 9.7.2-P3, they appear to have gone away, so
I presume one of the changes (maybe 2970) has fixed them.
--
Chris Thompson
Email: c...@cam.ac.uk
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.is
tion in BIND. "rndc flush"
discards the entire cache. "rndc flushname [name]" discards all
records with that specific name, regardless of type. (All this
per-view, if you use views.)
--
Chris Thompson
Email: c...@cam.ac.uk
___
bin
metimes other fixes from
later releases have applied. But I very much doubt that you will
find anyone distributing a "9.3" version that has anything like
modern support for DNSSEC.
--
Chris Thompson
Email: c...@cam.ac.uk
___
bind-users mai
On Oct 22 2010, Tony Finch wrote:
On Sun, 3 Oct 2010, Chris Thompson wrote:
Oct 3 16:53:10 dnssec: warning: validating @14c9cd70:
98.206.101.95.IN-ADDR.ARPA PTR:
can't validate existing negative responses (not a zone cut)
What do they mean, exactly? And should I be worrying about
both 9.7.1-P2
and 9.7.2-P2. Is this a known problem? Has anyone else
observed it?
It turns out this is quite easy to reproduce, and "rndc reconfig"
even with no change to named.conf reliably causes it. I have
reported it to bind9-b...@isc.org (RT 22296).
--
Chris Thompson
Email: c...@c
m enigmedia.com
Just as you would if you were changing NS records.
--
Chris Thompson
Email: c...@cam.ac.uk
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
m to refer to PTR records (not all of them for IP
addresses in 95.101/16, but many of them are).
--
Chris Thompson
Email: c...@cam.ac.uk
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
ting simply stops completely, until
BIND is restarted. The trust anchors go on being used OK,
and "rndc secroots" still shows them as "managed".
The effect seems to be associated with having used
"rndc reconfig", and I have observed it with both 9.7.1-P2
and 9.7
BIND is restarted.
An empty file managed-keys.bind in BIND's working directory will get it
to shut up.
--
Chris Thompson
Email: c...@cam.ac.uk
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
for it added to the root zone, and has been removed from the ITAR. It's
actually been gone from the ITAR for at least a couple of weeks: if
you are generating trust anchors from the ITAR you need to fetch and
reprocess it (much) more often. Things are changing very fas
time should be limited
and, if so, to how many MINUTES.
Hence BIND's default max-ncache-ttl of 3 hours.
--
Chris Thompson
Email: c...@cam.ac.uk
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
39]: [ID 873579 daemon.notice]
DNS format error from 194.80.160.250#53 resolving odbc.ucas.com/
for client 127.0.0.1#42869: invalid response
However, I haven't yet been able to work out exactly *what* is wrong
with the response, as demonstrated by dig (say). Any ideas?
--
Chris Thompson
E
or A, and SSHFP
types) that got into its cache, and it does set the "ad" bit in that
response.
--
Chris Thompson
Email: c...@cam.ac.uk
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
a)
to both views as well?
It applies to any file that BIND *updates* - hence including files for
slave zones, or for master zones that are dynamically updated.
--
Chris Thompson
Email: c...@cam.ac.uk
___
bind-users mailing list
bind-users@lists.isc
ld be
very helpful for those of us contemplating a move from BIND 9.6 to 9.7
to know more about this.
--
Chris Thompson
Email: c...@cam.ac.uk
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
_caldev._tcp.caldev SRV 10 10 80 server
in your (example.com) zone file. The first component is the protocol
specifier, the third is the (initial component of) the service name.
And such a SRV record can co-exist with your existing CNAME for
caldev.example.com, which is just as well while the
URL itself.)
There isn't any good solution to the problem. One possibility
is to have the apex A records all point to an http redirecting
service that adds the "www." (this assumes HTTP/1.1, but that's
surely safe these days). Then you only have one IP ad
e.f.f.f.f.d.e.1.a.f.1.0.0.0.1.5.1.0.0.b.8.0.1.0.0.2.ip6.arpa/dnssec/
What am I doing wrong?
Nothing that I can see. Maybe dnsviz can't cope with multiple PTR
records in an RRset, as your first case has? (On the other hand it
handles multiple A records in forward zones OK.)
--
Chr
ed for a decent
length of time.
--
Chris Thompson
Email: c...@cam.ac.uk
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
On May 18 2010, fddi wrote:
I wanted to ask if using TXT fields can have some bad implication
security issues
It rather depends what you put in them, doesn't it?
hostname TXT "Root password is AndyPandy"
mc-room TXT "Entacode is 2038"
...
--
Chris Thomp
t of flushing the whole
cache).
Of course, it would be possible to invent arbitrarily refined variants
on this theme - in this case what was wanted was "flush all negative
answers for names matching [f-z]*.de" - but maybe not very productively.
--
Chris Thompson
Email: c...@cam.ac.uk
___
ave to use +dnssec to get this apparent-mismatch effect: +buf=...
or +edns=... are enough.
--
Chris Thompson
Email: c...@cam.ac.uk
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
On May 7 2010, Peter Laws wrote:
On 05/07/10 06:49, Chris Thompson wrote:
Sure - just step into your time machine, go back to before the master
server died, and increase the SOA.expire value there so that it gets
propagated to the slave(s) in time.
If he has a small number of slaves, the OP
ire period before
the old signature is due to expire. With BIND's defaults of a 30-day
signature validity period and resigning 3/4 of the way through that,
an SOA.expire period of 1 week works out quite nicely.
--
Chris Thompson
Email: c...@cam.ac.uk
___
ggered by Mexico defaulting on its debts. Watch out, Greece ...
--
Chris Thompson
Email: c...@cam.ac.uk
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
rly still got quite a mess to sort out here.
--
Chris Thompson
Email: c...@cam.ac.uk
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
with timeouts, while
dig +dnssec +norec +vc dnskey uspto.gov @dns1.uspto.gov.
dig +dnssec +norec +vc dnskey uspto.gov @dns2.uspto.gov.
work fine ... with a 1736-byte answer. Probably the fragmented
UDP response is getting lost somewhere near the authoritative
servers themselves.
--
Chris Thompson
- previously the "type stub" setup
worked OK without a delegation in the signed parent.
--
Chris Thompson
Email: c...@cam.ac.uk
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
101 - 200 of 344 matches
Mail list logo
