Nsupdate and TTL

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Nsupdate and TTL

Bind-Users forum mailing list
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 know she's in there," said Verence, holding his crown in his hands
        in the famous Ai-Se-or-Mexican-Bandits-Have-Raided-Our-Village
        position


_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Nsupdate and TTL

Evan Hunt
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 send an update, so nothing changed..

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:

> zone example.com
> ttl 3600
> update del example.com in a
> update add example.com in a 192.0.2.1
> update add example.com in a 192.0.2.2
> update add example.com in a 192.0.2.3
> send

--
Evan Hunt -- [hidden email]
Internet Systems Consortium, Inc.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Nsupdate and TTL

Mark Andrews


> On 23 Apr 2020, at 07:20, Evan Hunt <[hidden email]> 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 mean ttl 3600 in all the
> records I send". You didn't actually send an update, so nothing changed..
>
> 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:
>
>> zone example.com
>> ttl 3600
>> update del example.com in a
>> update add example.com in a 192.0.2.1
>> update add example.com in a 192.0.2.2
>> update add example.com in a 192.0.2.3
>> send

Also don’t forget to add a prerequisite section to ensure you are removing
the records you think you are.

zone example.com
ttl 3600
prereq yxrrset example.com in a 192.0.2.1
prereq yxrrset example.com in a 192.0.2.2
prereq yxrrset example.com in a 192.0.2.3
update del example.com in a
update add example.com in a 192.0.2.1
update add example.com in a 192.0.2.2
update add example.com in a 192.0.2.3
send

Also note you can’t do it this way for the NS RRset at top of zone.  You need to
delete the NS RRs individually and then add them back without deleting all the
NS at any point in the process as the NS RRset is required to always exist.

Note: named only keeps a single TTL for a RRset so it will update the TTL on all
the records when you add a new one with a different TTL but this is not part of
the UPDATE RFC.

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [hidden email]

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Nsupdate and TTL

Petr Bena
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
have TTL overriden with the last one you add.

On 23/04/2020 01:06, Mark Andrews wrote:

>
>> On 23 Apr 2020, at 07:20, Evan Hunt <[hidden email]> 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 mean ttl 3600 in all the
>> records I send". You didn't actually send an update, so nothing changed..
>>
>> 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:
>>
>>> zone example.com
>>> ttl 3600
>>> update del example.com in a
>>> update add example.com in a 192.0.2.1
>>> update add example.com in a 192.0.2.2
>>> update add example.com in a 192.0.2.3
>>> send
> Also don’t forget to add a prerequisite section to ensure you are removing
> the records you think you are.
>
> zone example.com
> ttl 3600
> prereq yxrrset example.com in a 192.0.2.1
> prereq yxrrset example.com in a 192.0.2.2
> prereq yxrrset example.com in a 192.0.2.3
> update del example.com in a
> update add example.com in a 192.0.2.1
> update add example.com in a 192.0.2.2
> update add example.com in a 192.0.2.3
> send
>
> Also note you can’t do it this way for the NS RRset at top of zone.  You need to
> delete the NS RRs individually and then add them back without deleting all the
> NS at any point in the process as the NS RRset is required to always exist.
>
> Note: named only keeps a single TTL for a RRset so it will update the TTL on all
> the records when you add a new one with a different TTL but this is not part of
> the UPDATE RFC.
>
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Nsupdate and TTL

Mark Andrews


> On 23 Apr 2020, at 17:31, Petr Bena <[hidden email]> 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 add another NS record to a zone, all existing NS records will have TTL overriden with the last one you add.

Which is a side effect of BIND having a single TTL per RRset as I
said below.

To use UPDATE to change records on any DNS server please use the
methods listed below. The UPDATE message is a bit larger but it is
robust.

Mark

> On 23/04/2020 01:06, Mark Andrews wrote:
>>
>>> On 23 Apr 2020, at 07:20, Evan Hunt <[hidden email]> 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 mean ttl 3600 in all the
>>> records I send". You didn't actually send an update, so nothing changed..
>>>
>>> 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:
>>>
>>>> zone example.com
>>>> ttl 3600
>>>> update del example.com in a
>>>> update add example.com in a 192.0.2.1
>>>> update add example.com in a 192.0.2.2
>>>> update add example.com in a 192.0.2.3
>>>> send
>> Also don’t forget to add a prerequisite section to ensure you are removing
>> the records you think you are.
>>
>> zone example.com
>> ttl 3600
>> prereq yxrrset example.com in a 192.0.2.1
>> prereq yxrrset example.com in a 192.0.2.2
>> prereq yxrrset example.com in a 192.0.2.3
>> update del example.com in a
>> update add example.com in a 192.0.2.1
>> update add example.com in a 192.0.2.2
>> update add example.com in a 192.0.2.3
>> send
>>
>> Also note you can’t do it this way for the NS RRset at top of zone.  You need to
>> delete the NS RRs individually and then add them back without deleting all the
>> NS at any point in the process as the NS RRset is required to always exist.
>>
>> Note: named only keeps a single TTL for a RRset so it will update the TTL on all
>> the records when you add a new one with a different TTL but this is not part of
>> the UPDATE RFC.
>>
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>
> bind-users mailing list
> [hidden email]
> https://lists.isc.org/mailman/listinfo/bind-users

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [hidden email]

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Nsupdate and TTL

Tony Finch
In reply to this post by Mark Andrews
Mark Andrews <[hidden email]> wrote:
> > On 23 Apr 2020, at 07:20, Evan Hunt <[hidden email]> 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 of the slightly unexpected UPDATE semantics that we
discussed at the start of the month
(https://lists.isc.org/mailman/htdig/bind-users/2020-April/102851.html)

If an update message contains a new record with the same RDATA as an
existing record, then the new record replaces the existing record. This is
usually a no-op, because all the other fields in the record necessarily
match - except if you are changing the TTL!

So you can simply re-write an existing RRSet with a new TTL, without
deleting anything. This has the great advantage of avoiding the
contradictory ordering requirements that you get from apex NS records
and CNAME records: to change a CNAME you must delete then add, but to
(completely) change an apex NS RRset you must add then delete.

nsdiff always does a delete then add so that it doesn't need special case
code for one weird RRset. The apex NS RRset case is very rare - the only
time I encounter it is when bootstrapping a zone from scratch, in which
case I need a second run of nsdiff to get rid of my "empty" zone `NS
localhost` record :-)

> Also don’t forget to add a prerequisite section to ensure you are removing
> the records you think you are.

nsdiff takes another shortcut here: it only uses the SOA serial number as
a prerequisite check, because if the serial number matches, then the zone
hasn't changed from the source zone file that nsdiff was working from.
nspatch includes an automatic retry loop in case the zone changes
unexpectedly, which is safe so long as conflicting changes only happen
from DNSSEC signing activity.

http://dotat.at/prog/nsdiff/

Tony.
--
f.anthony.n.finch  <[hidden email]>  http://dotat.at/
Forth, Tyne, Dogger: Northeast backing north later, 3 or 4. Slight. Fog
patches later. Good, becoming poor or very poor later.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users