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
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 bmcdonal...@gmail.com wrote:
No, and there seems to be sparse documentation of the
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
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
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 are
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,
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
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 mailman.2601.1440783131.26362.bind-us...@lists.isc.org,
Darcy Kevin (FCA) kevin.da...@fcagroup.com 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
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 mailman.2604.1440796547.26362.bind-us...@lists.isc.org,
Darcy Kevin (FCA) kevin.da...@fcagroup.com 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
11 matches
Mail list logo
