Re: [DNSOP] New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt

[Ted Lemon <[e-mail]>]

Well, okay, but isn't this just for garbage collection?   Why is it a
problem if the garbage collection is delayed?   If the primary is down,
it's not like some other device could claim that name anyway.

On Sat, Aug 25, 2018 at 2:11 PM Tom Pusateri <[e-mail]> wrote:

> This is a valid question.
>
> In most cases, having the primary remember the lease lifetime should be
> enough. But if the outage is longer than the lease lifetime, it would
> better if the secondary would also have that information.
>
> But more importantly, the primary has to store the lease lifetimes for
> it’s own use for protection against restarts, reboots, and crashes. Keeping
> the lease lifetime closest to the records they reference is a good
> principle and so storing them as records along with the records they
> reference seems not only reasonable, but preferred.
>
> Whether or not they are transferred to the secondary is of secondary
> importance. But having them treated as regular records has been recommended
> so having them transferred during AXFR/IXFR will be looked upon with favor.
>
> Thanks,
> Tom
>
>
>
> On Aug 25, 2018, at 11:11 AM, Ted Lemon <[e-mail]> wrote:
>
> Right; my question is, is this an operational problem people are having
> IRL?   If it is, then it makes sense to do something about it.   If it's
> not, it doesn't.   I've never seen people do what you're describing in
> practice; that's why I'm asking.   And we definitely agree that there needs
> to be a cleanup process; the question is, does it have to be done this
> way.   E.g., if the lease isn't part of the zone, is that actually a
> problem?   Does the lease *need* to be part of the zone transfer, or is
> it enough that the primary has it?   For my part, it seems unnecessary for
> the secondaries to have it, since they can't update the zone anyway.   As
> long as the primary remembers that there's a lease, the right thing will
> happen.
>
> On Sat, Aug 25, 2018 at 10:30 AM Mark Andrews <[e-mail]> wrote:
>
>> It avoids leaving dangling records published longer than necessary.
>>
>> Network dies so the machine can’t do the cleanup it was intending.
>>
>> Last second cleanup as the lid closes doesn’t get through.
>>
>> It’s relatively easy to implement, no more difficult than resigning for
>> DNSSEC at the cost of a small amount of space.  It also transfers the
>> necessary state to all the slaves allowing them to take over if the master
>> server fails presuming they have the keying material for DNSSEC.
>>
>> --
>> Mark Andrews
>>
>> On 25 Aug 2018, at 22:53, Ted Lemon <[e-mail]> wrote:
>>
>> I'm not saying nobody does it.   I'm trying to understand how this helps.
>>
>> On Fri, Aug 24, 2018 at 11:24 PM Mark Andrews <[e-mail]> wrote:
>>
>>> Ted stop being daft. People have been registering addresses of machines
>>> in the public DNS for decades.   SLAAC. Is just one source of addresses.
>>> DHCP is another. Come up with a third method and they will do it with it.
>>>
>>> Also DHCP servers from ISPs don’t have authority to update DNS servers
>>> for my machines. Only those machines have such authority so don’t discount
>>> DHCP derived addresses.
>>>
>>> --
>>> Mark Andrews
>>>
>>> On 25 Aug 2018, at 12:53, Ted Lemon <[e-mail]> wrote:
>>>
>>> When would that happen?
>>>
>>> On Fri, Aug 24, 2018 at 10:52 PM Mark Andrews <[e-mail]> wrote:
>>>
>>>> Registering slaac derived addresses in the DNS.  These are tied to
>>>> prefix lifetimes.
>>>>
>>>>
>>>> --
>>>> Mark Andrews
>>>>
>>>> On 25 Aug 2018, at 05:02, Tom Pusateri <[e-mail]> wrote:
>>>>
>>>>
>>>>
>>>> On Aug 24, 2018, at 2:59 PM, Ted Lemon <[e-mail]> wrote:
>>>>
>>>> On Aug 24, 2018, at 2:43 PM, Tom Pusateri <[e-mail]> wrote:
>>>>
>>>> It seems odd to take the position that the authoritative server
>>>> shouldn’t need to clean up stale entries because it assumes the client will
>>>> do it for you. I can’t imagine you taking this position under any other
>>>> scenario.
>>>>
>>>>
>>>> The issue here is that this is a pretty major change to the DNS.   If
>>>> we really want something this heavy, we should have a good reason for
>>>> wanting it.   That's all.
>>>>
>>>> The idea that some unnamed DHCP server somewhere doesn't do the right
>>>> thing with cleaning up stale entries doesn't seem like a good enough
>>>> reason, particularly given that the DHCID record tags the thing as having
>>>> been added by the DHCP server, and considering that there are several open
>>>> source implementations that do automatically delete records when the lease
>>>> expires.
>>>>
>>>> I think it might make sense to just wait on this.  I agree that it's an
>>>> interesting idea for completeness, but we don't have enough operational
>>>> experience yet to know whether we have a problem worth solving.   With
>>>> respect to the DHCP use case, I'm certain we don't.
>>>>
>>>> The good news is that if we do need this, you've done a design, and we
>>>> also have Paul's design to look at.   So if operational experience a few
>>>> years down the road shows us that we have a gap here, we can move on it
>>>> pretty easily. I just don't see any reason to rush into it.
>>>>
>>>>
>>>> Ok, great. Hopefully others have some use cases they can share. In the
>>>> mean time, back to learning Rust…
>>>>
>>>> Thanks,
>>>> Tom
>>>>
>>>> _______________________________________________
>>>> DNSOP mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/dnsop
>>>>
>>>>
>