On 2015-08-28 14:15, Darcy Kevin (FCA) wrote:
As you pointed out (correctly), this isn't an issue which affects anything that goes "on the
wire", e.g. master-slave replication via AXFR/IXFR, since, "on the wire" the TTL is
always included with the RR. It's only an issue for how the zone files a
In article ,
"Darcy Kevin (FCA)" wrote:
> Negative-caching TTL and regular TTL have little to do with each other; it's
> not a reasonable assumption that one should stand in as a default for the
> other.
True, but that's water long under the bridge.
Note that if a server is authoritative-onl
On Fri, Aug 28, 2015 at 07:24:23PM +0200, Robert Senger wrote:
> Is that the intended behaviour, or do I miss a point to get the zones
> resigned in one single action (and transfered with one single IXFR)
> rather than getting each RR resigned separately?
It is intentional; it spreads out the work
Negative-caching TTL and regular TTL have little to do with each other; it's
not a reasonable assumption that one should stand in as a default for the
other. I know analogies are frequently dangerous, but to me, that's kind of
like saying that the amount of time that normally elapses between rep
On 28.08.15 17:32, Darcy Kevin (FCA) wrote:
RFC 2308 said that the use of the last field of the SOA to set
negative-caching TTL is "the new defined meaning of the SOA minimum
field". So you can *call* it "minimum", but it is *actually* supposed to
function as something else...
Eventually I hope
In article ,
"Darcy Kevin (FCA)" wrote:
> What's in a name? :-)
>
> RFC 2308 said that the use of the last field of the SOA to set
> negative-caching TTL is "the new defined meaning of the SOA minimum field".
> So you can *call* it "minimum", but it is *actually* supposed to function as
> so
What's in a name? :-)
RFC 2308 said that the use of the last field of the SOA to set negative-caching
TTL is "the new defined meaning of the SOA minimum field". So you can *call* it
"minimum", but it is *actually* supposed to function as something else...
Eventually I hope BIND will conform to
Hi all,
after upgrading from Debian Wheezy to Jessie, the dnssec-tools package
(including rollerd for automatic ZSK key rollover) is no longer
available.
So I've set up bind9 to do the signing:
zone "mydomain.de" in
{
Thank you all for your help! I found that the reconfig command was
called by a script executed by wide-dhcpv6-client. In wheezy, this
script was called once when the ipv6 address of the public ppp interface
changed, in Jessie it was called every 30 minutes for whatever reason.
Fixed that.
Cheers,
> Is that really still true? I thought that use of the Minimum field went
> away when it was changed to be the negative cache TTL.
Barry,
Yes, it’s still true. If you don’t set a default TTL, then the last field of
the SOA record does double duty as both a default TTL and a negative caching
TT
On 8/28/15 9:19 AM, Bob McDonald wrote:
> It appears that receiving an NSID response depends on having server-id
> set in the options block. However, I'm seeing no way to restrict such
> queries.
You don't have to set the server-id information to anything that an
external entity would find interes
It appears that receiving an NSID response depends on having server-id set
in the options block. However, I'm seeing no way to restrict such queries.
regards,
Bob
On Fri, Aug 28, 2015 at 7:48 AM, Bob McDonald wrote:
> No, and there seems to be sparse documentation of the use of NSID in
> troub
No, and there seems to be sparse documentation of the use of NSID in
troubleshooting. I'm all ears. I would. however, like to restrict queries
to inside networks/users and negate access to that data from the outside
altogether.
TIA,
Bob
Alan Clegg wrote:
> Has anyone recommended doing debugging
13 matches
Mail list logo
