Mark Andrews wrote:
> > On 23 Apr 2020, at 07:20, Evan Hunt wrote:
> >
> > As far as I can recall, the only way to change a TTL in nsupdate is to
> > delete the whole RRset and then add it back in the same transaction:
There's actually a standard shortcut for TTL changes which is a
consequence o
> On 23 Apr 2020, at 17:31, Petr Bena wrote:
>
> Hello,
>
> From my experience you don't need to delete whole set, I was actually doing
> this quite recently and discovered and interesting behavior of BIND server -
> last record you add will override the TTL value for a set.
>
> So if you a
Hello,
From my experience you don't need to delete whole set, I was actually
doing this quite recently and discovered and interesting behavior of
BIND server - last record you add will override the TTL value for a set.
So if you add another NS record to a zone, all existing NS records will
h
> On 23 Apr 2020, at 07:20, Evan Hunt wrote:
>
> On Wed, Apr 22, 2020 at 03:04:38PM -0600, @lbutlr via bind-users wrote:
>> # nsupdate -k /path/to/key
>>> zone example.com
>>> ttl 3600
>>> send
>>> ^d
>>
>> No errors, but no change in the TTL.
>
> "ttl 3600" just means "from now on assume I m
On Wed, Apr 22, 2020 at 03:04:38PM -0600, @lbutlr via bind-users wrote:
> # nsupdate -k /path/to/key
> > zone example.com
> > ttl 3600
> > send
> > ^d
>
> No errors, but no change in the TTL.
"ttl 3600" just means "from now on assume I mean ttl 3600 in all the
records I send". You didn't actually
What is the proper syntax gor changing the TTL on a zone with nsupdate?
Does the existence of $TTL 86400 in the domain.conf file override nssupdate’s
attempts to change the TTL?
# nsupdate -k /path/to/key
> zone example.com
> ttl 3600
> send
> ^d
No errors, but no change in the TTL.
--
"I k
6 matches
Mail list logo
