Disclaimer:
I agree with everyone in this thread that explicit is better than
implicit, and that auto-magic is much worse than operators lowering
their TTL in time and then setting it back when they are done.
Of course, RIPE NCC can be a pioneer among registries and expose TTL to
domain admin
Hi Petr,
> I think lowering both TTLs is a step in right direction, but let me ask
> provocative question:
>
> Why not make the TTL _dynamic_, based on time of last change in the RIPE
> database?
Because explicit is better than implicit. Magically calculated dynamic values
rarely match operat
Tim Wicinski wrote:
> I support lowering the TTL on the DS records to 3600.
> I support lowering the TTL on the NS records - I was going to put my
> hat in for 21600, but Mr van Dijk's suggestion of 3600 is very
> enticing.
> But I liked Mr. Lawrence's suggestion on gatherin
gregory> Maybe allow users to set TTL on "domain" object in RIPE
gregory> database?
Be nice if we could expand to a more sane/standard set of TTLs for NS/DS
in TLD/SLDs, which makes this non-functional for a slew of such zones.
gregory> Allowed values can be constrained to few common lengths of
g
If we are lowering the TTL, i support Gregorys suggestion by having a TTL field in the RIPE database.I would like to have a high as possible TTL on our zones. A week TTL is fine.Jørgen
At 13:02 02/12/2021 (UTC), Gregory Brzeski wrote:
Maybe allow users to set TTL on "domain" obj
On Thu, Dec 02, 2021 at 01:11:17PM +0100, Jeroen Massar via dns-wg wrote:
> > Same. I support this, and I also support lowering NS even further, even
> > to 3600.
>
> Another Aye from me on DS & NS to TTL 3600.
I'm slightly reminded of the solar activity cycle by another instance of
a race to lo
> On 2 Dec 2021, at 13:46, Petr Špaček wrote:
>
> Why not make the TTL _dynamic_, based on time of last change in the RIPE
> database?
Because it’s a very bad idea?
1) The RIPE database and its reverse zone DNS data are orthogonal things
(modulo the nameserver objects for bits of the revers
> - Quick turnaround around changes and potential problems. Most
> problems happen right after change, in which case even 1 hour is PITA.
One hour should then be your upper (stable) limit. From experience I know DNS
problems can occur anytime anywhere unplanned, not just after a change in the
RI
On 02/12/2021 14:46, Petr Špaček wrote:
Why not make the TTL _dynamic_, based on time of last change in the
RIPE database?
I belive this is an interesting approach, however requires that same
logic will be applied to all users on server side.
The question arises if same logic fits all user
On 12/2/21 2:46 PM, Petr Špaček wrote:
Why not make the TTL _dynamic_, based on time of last change in the RIPE
database?
Here is a wild example how it could work - all constants are made up, feel free
to substitute your own:
Step 1: Define upper bound for NS & DS TTLs which are "stable". Say
On 29. 11. 21 12:59, Anand Buddhdev wrote:
Dear colleagues,
Users may request reverse DNS delegation by creating "domain" objects in
the RIPE Database. Such domain objects must contain "nserver" attributes
to specify the name servers for a reverse DNS zone, and may contain
"ds-rdata" attribut
On Thu, Dec 2, 2021 at 6:35 AM Peter van Dijk
wrote:
> On Mon, 2021-11-29 at 17:07 +0100, Ralf Weber wrote:
> > Moin!
> >
> > On 29 Nov 2021, at 12:59, Anand Buddhdev wrote:
> >
> > > We propose to lower, in the first quarter of 2022, the TTL on NS records
> > > to 86400 and on DS records to 3
Maybe allow users to set TTL on "domain" object in RIPE database?
Allowed values can be constrained to few common lengths of time? The
default would be one decided here.
This way users would have a choice.
Gregory
On 02/12/2021 12:49, Tim Wicinski wrote:
I support lowering the TTL on the
I support lowering the TTL on the DS records to 3600.
I support lowering the TTL on the NS records - I was going to put my hat in
for 21600,
but Mr van Dijk's suggestion of 3600 is very enticing.
But I liked Mr. Lawrence's suggestion on gathering data on lowering the NS
records TTL.
Perhaps the T
On Mon, 2021-11-29 at 17:07 +0100, Ralf Weber wrote:
> Moin!
>
> On 29 Nov 2021, at 12:59, Anand Buddhdev wrote:
>
> > We propose to lower, in the first quarter of 2022, the TTL on NS records to
> > 86400 and on DS records to 3600.
> I very much support that and would go even lower for for NS re
15 matches
Mail list logo
