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
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
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
> 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
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,
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
{
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
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
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
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 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
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 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
13 matches
Mail list logo
