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

[Mark Andrews]

> On 22 Feb 2019, at 9:52 am, Joe Abley  wrote:
> 
> On 21 Feb 2019, at 14:34, Mark Andrews  wrote:
> 
>> Machines die. Machines are unplugged.  Server are unreachable at critical 
>> times. Externally driven cleanup can never be reliable. 
> 
> I'm not disputing any of that. I guess my first question was first whether 
> cleanup is necessary, and second (assuming it is) whether cleanup can't just 
> be handled as an implementation detail as opposed to a protocol extension.
> 
> If the master server that receive UPDATEs matching particular names could be 
> configured to remove them after a suitable interval, wouldn't that do the 
> trick?

No.  How do you make “permanent” changes to the zone using UPDATE?

> Slave servers would get new copies of the zones concerned following the 
> updates in the normal manner. Zone propagation is pretty swift with NOTIFY. 
> The master could apply policy based on criteria like owner name pattern 
> matching or source of the update. Garbage collection might not happen with 
> the kind of split-second accuracy that I sense this mechanism's proponents 
> are suggesting, but does it need to? Don't we believe that applications that 
> expect more than loose coherence from the DNS are broken?

Nothing in this draft changes loose coherence.  Everything is done by the 
master.  The slave has the data so it has the state to become the master when 
the machine that was the master dies.

> I hear and acknowledge there is a desire for this kind functionality (i.e. I 
> believe you that it's necessary) but I'm still not clear on what need there 
> is for interoperability (and hence standardisation). Every DNS implementation 
> contains their own special features that are not standardised and that don't 
> need to be. Couldn't this be another one?

No.  There are plenty of our customers that want features to work cross 
platform.  They also want to be able to switch to a different code base when 
there is a security issue in another one.  They also want things to work as 
well as possible for disaster recovery.  Having the GC information is a vendor 
neutral form achieves these objectives.

There are plenty of customers where all the slaves are transferring data from 
two masters all the time.  Those masters are from different vendors with 
transfers flowing from which ever is currently configured as the ultimate 
master between them.  The may also be configured to transfer from all of the 
slaves as well.  If current master dies / is taken out of service the backup 
master will get the newest copy of the zone that has made it to any of the 
other servers within minutes.  It can then be reconfigured as the active master 
and continue straight away.  Throwing proprietary GC into this does not work.

> I remain open to the idea that I am just missing the point because I don't 
> spend enough time in enterprise or campus networks. I think I'm possibly not 
> the only one in that boat, though, and I don't think it's unreasonable for 
> the draft to explore its applicability and explain clearly why 
> standardisation or in-zone signalling (hence RRs) is necessary as a 
> prerequisite to standardisation. As I mentioned before, the bar for 
> experimental is surely much lower, and the bar for simple codepoint 
> assignment lower still.

What are the terms of the experiment if you want experimental?  What are you 
wanting to discover?  That the protocol works?

> Joe

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ted Lemon]

On Feb 21, 2019, at 2:52 PM, Joe Abley  wrote:
> The master could apply policy based on criteria like owner name pattern 
> matching or source of the update. Garbage collection might not happen with 
> the kind of split-second accuracy that I sense this mechanism's proponents 
> are suggesting, but does it need to? Don't we believe that applications that 
> expect more than loose coherence from the DNS are broken?

The impression that you are working from here seems to be that what is being 
designed is a hacky kludge that would go well with heuristics like this.   But 
what is actually being worked on here is a system that is not a hacky kludge, 
and that does not have leaks, and does not rely on clever heuristics to 
approximate good behavior.   Please read the service registration protocol 
document I mentioned in a previous message (draft-ietf-dnssd-srp).

Granted, I am not convinced that the document we are discussing is the right 
solution to the problem, but it’s an actual solution to the problem, not a 
hacky kludge, and that’s definitely a good thing.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Joe Abley]

On 21 Feb 2019, at 14:34, Mark Andrews  wrote:

> Machines die. Machines are unplugged.  Server are unreachable at critical 
> times. Externally driven cleanup can never be reliable. 

I'm not disputing any of that. I guess my first question was first whether 
cleanup is necessary, and second (assuming it is) whether cleanup can't just be 
handled as an implementation detail as opposed to a protocol extension.

If the master server that receive UPDATEs matching particular names could be 
configured to remove them after a suitable interval, wouldn't that do the 
trick? Slave servers would get new copies of the zones concerned following the 
updates in the normal manner. Zone propagation is pretty swift with NOTIFY. The 
master could apply policy based on criteria like owner name pattern matching or 
source of the update. Garbage collection might not happen with the kind of 
split-second accuracy that I sense this mechanism's proponents are suggesting, 
but does it need to? Don't we believe that applications that expect more than 
loose coherence from the DNS are broken?

I hear and acknowledge there is a desire for this kind functionality (i.e. I 
believe you that it's necessary) but I'm still not clear on what need there is 
for interoperability (and hence standardisation). Every DNS implementation 
contains their own special features that are not standardised and that don't 
need to be. Couldn't this be another one?

I remain open to the idea that I am just missing the point because I don't 
spend enough time in enterprise or campus networks. I think I'm possibly not 
the only one in that boat, though, and I don't think it's unreasonable for the 
draft to explore its applicability and explain clearly why standardisation or 
in-zone signalling (hence RRs) is necessary as a prerequisite to 
standardisation. As I mentioned before, the bar for experimental is surely much 
lower, and the bar for simple codepoint assignment lower still.


Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Mark Andrews]

Machines die. Machines are unplugged.  Server are unreachable at critical 
times. Externally driven cleanup can never be reliable. 

-- 
Mark Andrews

> On 22 Feb 2019, at 06:21, 神明達哉  wrote:
> 
> At Wed, 20 Feb 2019 07:51:51 -0500,
> Joe Abley  wrote:
> 
> > The crux of the use case seems to be that it is commonplace for names in 
> > the DNS to exist for short periods of time and that for some applications a 
> > name that overstays its welcome can cause an operational problem.
> > 
> > While I can understand the philosophical desire to complete the UPDATE 
> > specification so that it is possible to engineer around this scenario, I 
> > don't see the practical application.
> 
> I happen to know there's a practical application related to this
> proposal..  As Mark says not all DHCP servers behave politely; there
> are servers that just add RRs via DDNS and forget them.  We could say
> that it's a problem of poorly implemented DDNS clients, not something
> that should be solved in the DNS protocol.  I wouldn't necessarily be
> opposed to that view.  In fact, given the higher bar with the "camel"
> test, I'm not yet really convinced about the need for a protocol-based
> solution to this problem either.  But at least this is related to a
> practical problem, not just a philosophical one.
> 
> --
> JINMEI, Tatuya
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[神明達哉]

At Wed, 20 Feb 2019 07:51:51 -0500,
Joe Abley  wrote:

> The crux of the use case seems to be that it is commonplace for names in
the DNS to exist for short periods of time and that for some applications a
name that overstays its welcome can cause an operational problem.
>
> While I can understand the philosophical desire to complete the UPDATE
specification so that it is possible to engineer around this scenario, I
don't see the practical application.

I happen to know there's a practical application related to this
proposal.  As Mark says not all DHCP servers behave politely; there
are servers that just add RRs via DDNS and forget them.  We could say
that it's a problem of poorly implemented DDNS clients, not something
that should be solved in the DNS protocol.  I wouldn't necessarily be
opposed to that view.  In fact, given the higher bar with the "camel"
test, I'm not yet really convinced about the need for a protocol-based
solution to this problem either.  But at least this is related to a
practical problem, not just a philosophical one.

--
JINMEI, Tatuya
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Dick Franks]

On Thu, 21 Feb 2019 at 12:25, Tony Finch  wrote:

> Mark Andrews  wrote:
> > > On 21 Feb 2019, at 6:30 am, Tony Finch  wrote:
> > >
> > > Does it need to be per-record? Why not GC the whole RRset?
> >
> > Because there are scenarios where you do want to GC as single
> > record from the RRset. AD has them with SRV.  Each server adds
> > its own SRV record to the RRset.
>
> Oh I see, that makes sense. Things like this need explaining in the
> document.
>
> Why not simplify the RDATA format so there is just one item per record,
> instead of containing a list of lists? Aren't the individual items going
> to be added/removed independently of each other?
>

Good idea.

A more radical approach would be to have just one hash per item per record.
This has the attraction of allowing a truncated hash to be used, without
the need for length fields.

--Dick
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Tony Finch]

Mark Andrews  wrote:
> > On 21 Feb 2019, at 6:30 am, Tony Finch  wrote:
> >
> > Does it need to be per-record? Why not GC the whole RRset?
>
> Because there are scenarios where you do want to GC as single
> record from the RRset. AD has them with SRV.  Each server adds
> its own SRV record to the RRset.

Oh I see, that makes sense. Things like this need explaining in the
document.

Why not simplify the RDATA format so there is just one item per record,
instead of containing a list of lists? Aren't the individual items going
to be added/removed independently of each other?

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Shannon, Rockall: Southerly or southeasterly 6 to gale 8, increasing severe
gale 9 at times, perhaps storm 10 later in northwest Rockall. Very rough or
high. Rain. Moderate or poor.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Mark Andrews]

> On 21 Feb 2019, at 6:30 am, Tony Finch  wrote:
> 
> Mark Andrews  wrote:
>> 
>> All that is missing is the automated cleanup.  DNS servers are quite
>> capable of doing that once specified how.
> 
> Does it need to be per-record? Why not GC the whole RRset?

Because there are scenarios where you do want to GC as single
record from the RRset. AD has them with SRV.  Each server adds
its own SRV record to the RRset.  When a server goes away without
cleaning up you want the SRV to go but the RRset to remain.

A machine has permanent and time limited addresses.

I’m sure there will be other cases where you want selective deletion
from a RRset.

Mark

> Tony.
> -- 
> f.anthony.n.finchhttp://dotat.at/
> Fair Isle: Southwesterly 5 or 6, occasionally 7 later in west. Moderate or
> rough, occasionally very rough at first in west. Rain. Good, occasionally
> moderate.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Vixie]

Tony Finch wrote on 2019-02-20 11:30:

Mark Andrews  wrote:


All that is missing is the automated cleanup.  DNS servers are quite
capable of doing that once specified how.


Does it need to be per-record? Why not GC the whole RRset?


+1. this is what DEFUPD did.

(https://datatracker.ietf.org/doc/draft-ietf-dnsind-defupd/)

--
P Vixie

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Tony Finch]

Mark Andrews  wrote:
>
> All that is missing is the automated cleanup.  DNS servers are quite
> capable of doing that once specified how.

Does it need to be per-record? Why not GC the whole RRset?

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Fair Isle: Southwesterly 5 or 6, occasionally 7 later in west. Moderate or
rough, occasionally very rough at first in west. Rain. Good, occasionally
moderate.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Mark Andrews]

Joe, look at active directory. The names in the DNS are garbage cleaned by 
undocumented processes that prevent UPDATE being used to manage the “static” 
content. 

You have registering  and PTR records with SLAAC. You don’t want stale 
records to continue to exist in the zones. You will be sent to the wrong 
machine () or the zone will become a garbage dump of stale records (PTR).   
But until the support is there you can’t safely do this. 

Today you can use SIG(0) to register your  records and use TCP to 
authenticate PTR  additions to the DNS zones. All that is missing is the 
automated cleanup.  DNS servers are quite capable of doing that once specified 
how.   DHCP servers mostly do this for IPv4 but even that is problematic.  
Records still get left behind because there was a communication failure at 
lease expiry / release. 

DNS-SD has the same issues. Garbage collection. 

You also need it as standards track so people won’t think it is something that 
is going away and to encourage everyone who implements UPDATE to support it.  
Clients and servers. 
-- 
Mark Andrews

> On 20 Feb 2019, at 23:51, Joe Abley  wrote:
> 
>> On 20 Feb 2019, at 00:35, Paul Wouters  wrote:
>> 
>>> On Wed, 20 Feb 2019, Mark Andrews wrote:
>>> 
>>> Think disaster recovery and promoting a slave to master.  You have to
>>> transfer state between servers.  You can transfer it in band or out of
>>> band.  If you transfer it out of band you need to invent / specify
>>> yet-another-protocol to do it on top of specifying when records need to
>>> be removed.
>> 
>> That is not very convincing to me. disaster recovery scenarios seem to
>> be solvable by proper admin and by the daemon properly writing state to
>> disk which can be saved off-site. It also seems a rather rare occurance.
> 
> I agree.
> 
> The crux of the use case seems to be that it is commonplace for names in the 
> DNS to exist for short periods of time and that for some applications a name 
> that overstays its welcome can cause an operational problem.
> 
> While I can understand the philosophical desire to complete the UPDATE 
> specification so that it is possible to engineer around this scenario, I 
> don't see the practical application. The existence of the requirement in the 
> first place seems unproven (at least there are no obvious examples given); 
> the scenario in which the purported operational problem arises seems likely 
> to be rare; workarounds surely exist and, really, the damage in the event 
> that the stars align and a temporary name does persist seems very low.
> 
> If the goal is to try this out and have no impact on existing implementations 
> (e.g. there is some side code that is imagined that will poll a transferred 
> zone for TIMEOUT records and do local UPDATEs in order to remove RRSets that 
> should not be there) then all that is really needed here is a code point for 
> the TIMEOUT RR. The existence of the draft is nice since documentation is 
> good, but I think "experimental" would be a better target than "standards 
> track". It's surely possible that this mechanism will solve some as-yet 
> unnoticed, large-scale problem and will one day be considered essential 
> functionality, but I don't think we're there today. There be camels.
> 
> 
> Joe
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Dick Franks]

On Wed, 20 Feb 2019 at 12:36, Tony Finch  wrote:

> Dick Franks  wrote:
> >
> > Unsigned 32 bit RRSIG time is good for travel until 7th February 2106.
>
> No, it lasts indefinitely. It covers +/- 68 years relative to current
> POSIX time using serial number arithmetic.
>

The value is  ( t - Jan1970 ) mod 2**32,  for any integer t,   which is
certainly
not relative to current time, always positive, and I agree lasts
indefinitely.
The point I was trying to make was that the wrapping occurs in 2106,
not 2038 as some have claimed.
RFC1982 serial number arithmetic is mandated for comparison of these values,
not for defining the values themselves.


[RFC4034] 3.1.5.  Signature Expiration and Inception Fields

   The Signature Expiration and Inception fields specify a validity
   period for the signature.  The RRSIG record MUST NOT be used for
   authentication prior to the inception date and MUST NOT be used for
   authentication after the expiration date.

   The Signature Expiration and Inception field values specify a date
   and time in the form of a 32-bit unsigned number of seconds elapsed
   since 1 January 1970 00:00:00 UTC, ignoring leap seconds, in network
   byte order.  The longest interval that can be expressed by this
   format without wrapping is approximately 136 years.  An RRSIG RR can
   have an Expiration field value that is numerically smaller than the
   Inception field value if the expiration field value is near the
   32-bit wrap-around point or if the signature is long lived.  Because
   of this, all comparisons involving these fields MUST use "Serial
   number arithmetic", as defined in [RFC1982].  As a direct
   consequence, the values contained in these fields cannot refer to
   dates more than 68 years in either the past or the future.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ted Lemon]

On Feb 20, 2019, at 4:51 AM, Joe Abley  wrote:
> The crux of the use case seems to be that it is commonplace for names in the 
> DNS to exist for short periods of time and that for some applications a name 
> that overstays its welcome can cause an operational problem.
> 
> While I can understand the philosophical desire to complete the UPDATE 
> specification so that it is possible to engineer around this scenario, I 
> don't see the practical application. The existence of the requirement in the 
> first place seems unproven (at least there are no obvious examples given); 
> the scenario in which the purported operational problem arises seems likely 
> to be rare; workarounds surely exist and, really, the damage in the event 
> that the stars align and a temporary name does persist seems very low.
> 
> If the goal is to try this out and have no impact on existing implementations 
> (e.g. there is some side code that is imagined that will poll a transferred 
> zone for TIMEOUT records and do local UPDATEs in order to remove RRSets that 
> should not be there) then all that is really needed here is a code point for 
> the TIMEOUT RR. The existence of the draft is nice since documentation is 
> good, but I think "experimental" would be a better target than "standards 
> track". It's surely possible that this mechanism will solve some as-yet 
> unnoticed, large-scale problem and will one day be considered essential 
> functionality, but I don't think we're there today. There be camels.

The goal of this is to automate name publication for situations where this is 
desirable.   You’re probably not going to use this for your public servers.   
See https://tools.ietf.org/html/draft-ietf-dnssd-srp-00 
 (expired, but we’ll be 
submitting an update soon).

I say this not to specfically support this proposal, which I think has 
problems, but simply to point out that there is an itch here to scratch.   I 
don’t think this is something that we need in every different kind of DNS 
server, but something like this could definitely be useful in some operational 
situations.   Of course it can be done out of band, but there’s something to be 
said for keeping all the state in one place.   I don’t have enough operational 
experience with this yet to have formed a preference.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Joe Abley]

On 20 Feb 2019, at 00:35, Paul Wouters  wrote:

> On Wed, 20 Feb 2019, Mark Andrews wrote:
> 
>> Think disaster recovery and promoting a slave to master.  You have to
>> transfer state between servers.  You can transfer it in band or out of
>> band.  If you transfer it out of band you need to invent / specify
>> yet-another-protocol to do it on top of specifying when records need to
>> be removed.
> 
> That is not very convincing to me. disaster recovery scenarios seem to
> be solvable by proper admin and by the daemon properly writing state to
> disk which can be saved off-site. It also seems a rather rare occurance.

I agree.

The crux of the use case seems to be that it is commonplace for names in the 
DNS to exist for short periods of time and that for some applications a name 
that overstays its welcome can cause an operational problem.

While I can understand the philosophical desire to complete the UPDATE 
specification so that it is possible to engineer around this scenario, I don't 
see the practical application. The existence of the requirement in the first 
place seems unproven (at least there are no obvious examples given); the 
scenario in which the purported operational problem arises seems likely to be 
rare; workarounds surely exist and, really, the damage in the event that the 
stars align and a temporary name does persist seems very low.

If the goal is to try this out and have no impact on existing implementations 
(e.g. there is some side code that is imagined that will poll a transferred 
zone for TIMEOUT records and do local UPDATEs in order to remove RRSets that 
should not be there) then all that is really needed here is a code point for 
the TIMEOUT RR. The existence of the draft is nice since documentation is good, 
but I think "experimental" would be a better target than "standards track". 
It's surely possible that this mechanism will solve some as-yet unnoticed, 
large-scale problem and will one day be considered essential functionality, but 
I don't think we're there today. There be camels.


Joe

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Tim Wattenberg]

Dick,

> On 20. Feb 2019, at 13:35, Tony Finch  wrote:
> 
> Dick Franks  wrote:
>> 
>> Unsigned 32 bit RRSIG time is good for travel until 7th February 2106.
> 
> No, it lasts indefinitely. It covers +/- 68 years relative to current
> POSIX time using serial number arithmetic.

you might want to give RFC 1982 a read... I got that wrong before, too ;-)

Tim

smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Tony Finch]

Dick Franks  wrote:
>
> Unsigned 32 bit RRSIG time is good for travel until 7th February 2106.

No, it lasts indefinitely. It covers +/- 68 years relative to current
POSIX time using serial number arithmetic.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Shannon, Rockall: South 6 to gale 8. Rough or very rough, becoming very rough
or high. Occasional rain or drizzle. Good, occasionally poor.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Mark Andrews]

> On 20 Feb 2019, at 4:35 pm, Paul Wouters  wrote:
> 
> On Wed, 20 Feb 2019, Mark Andrews wrote:
> 
>> Think disaster recovery and promoting a slave to master.  You have to
>> transfer state between servers.  You can transfer it in band or out of
>> band.  If you transfer it out of band you need to invent / specify
>> yet-another-protocol to do it on top of specifying when records need to
>> be removed.
> 
> That is not very convincing to me. disaster recovery scenarios seem to
> be solvable by proper admin and by the daemon properly writing state to
> disk which can be saved off-site. It also seems a rather rare occurrence.

So you write it to disk then transfer it off site which breaks atomicity
of the zone’s meta state or do it in band with TIMEOUT.

> If the primary does DNSSEC, you also have to transfer private keys and
> that isn't happening in-band either. So I'm not convinced by the
> promotion of secondary to master either.

You can pass the keys before you start to use them.  They are essentially
static information.

> It also seems these two use cases are mostly solved if you keep your
> dynamic update clients within their own zone, which I think is pretty
> normal for DHCP based nodes that can make up their own hostname anyway
> and shouldn't be able to muck with real static records or apex records.

Policy about who can update what is unrelated to making sure content gets
cleaned up.  There isn’t always a DHCP server to do the garbage collection.
This is especially true with IPv6 and SLAAC.

> Paul
> 
>>> On 20 Feb 2019, at 9:26 am, Paul Wouters  wrote:
>>> 
>>> 
>>> I have read the document.
>>> 
>>> I have a question about:
>>> 
>>>  A zone administrator may
>>>  want to enforce a default lifetime for dynamic updates (such as the
>>>  DHCP lease lifetime) or the DNS Update may contain a lifetime using
>>>  an EDNS(0) Update Lease option [I-D.sekar-dns-ul].
>>> 
>>> This seems a local policy and local implementation issue only.
>>> 
>>> However, this
>>> lease lifetime is not communicated to secondary servers and will not
>>> endure through server software restarts.
>>> 
>>> Why does the secondary server need to know the lease lifetime? Only the
>>> primary needs to know this because it will need to purge the records and
>>> update the appropriate DNSSEC entries, something the secondary cannot do
>>> anyway? In fact, Section 8 agrees with me:
>>> 
>>>  A secondary server MUST NOT expire the records in a zone it maintains
>>>  covered by the TIMEOUT resource record and it MUST NOT expire the
>>>  TIMEOUT resource record itself when the last record it covers has
>>>  expired.  The secondary server MUST always wait for the records to be
>>>  removed or updated by the primary server.
>>> 
>>> So why is the TIMEOUT record needed? If the secondary argument is
>>> gone, the only argument left from the Introduction is server software
>>> restart. Which seems to me to be an application issue and not a protocol
>>> issue?
>>> 
>>> As others pointed out, introducing SHA3 into the DNS right now is not
>>> appropriate.
>>> 
>>> I see a use for clients telling the dns update server what the maximum
>>> possibly lifetime can be, so it can go and perform a delete request on
>>> behalf of vanished clients. But again I don't see this as a protocol
>>> issue needing a TIMEOUT RRTYPE ?
>>> 
>>> Did I miss anything?
>>> 
>>> Paul
>>> 
>>> ___
>>> DNSOP mailing list
>>> DNSOP@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dnsop
>> 
>> -- 
>> Mark Andrews, ISC
>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>> PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org
>> 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Wouters]

On Wed, 20 Feb 2019, Mark Andrews wrote:


Think disaster recovery and promoting a slave to master.  You have to
transfer state between servers.  You can transfer it in band or out of
band.  If you transfer it out of band you need to invent / specify
yet-another-protocol to do it on top of specifying when records need to
be removed.


That is not very convincing to me. disaster recovery scenarios seem to
be solvable by proper admin and by the daemon properly writing state to
disk which can be saved off-site. It also seems a rather rare occurance.

If the primary does DNSSEC, you also have to transfer private keys and
that isn't happening in-band either. So I'm not convinced by the
promotion of secondary to master either.

It also seems these two use cases are mostly solved if you keep your
dynamic update clients within their own zone, which I think is pretty
normal for DHCP based nodes that can make up their own hostname anyway
and shouldn't be able to muck with real static records or apex records.

Paul


On 20 Feb 2019, at 9:26 am, Paul Wouters  wrote:


I have read the document.

I have a question about:

  A zone administrator may
  want to enforce a default lifetime for dynamic updates (such as the
  DHCP lease lifetime) or the DNS Update may contain a lifetime using
  an EDNS(0) Update Lease option [I-D.sekar-dns-ul].

This seems a local policy and local implementation issue only.

 However, this
 lease lifetime is not communicated to secondary servers and will not
 endure through server software restarts.

Why does the secondary server need to know the lease lifetime? Only the
primary needs to know this because it will need to purge the records and
update the appropriate DNSSEC entries, something the secondary cannot do
anyway? In fact, Section 8 agrees with me:

  A secondary server MUST NOT expire the records in a zone it maintains
  covered by the TIMEOUT resource record and it MUST NOT expire the
  TIMEOUT resource record itself when the last record it covers has
  expired.  The secondary server MUST always wait for the records to be
  removed or updated by the primary server.

So why is the TIMEOUT record needed? If the secondary argument is
gone, the only argument left from the Introduction is server software
restart. Which seems to me to be an application issue and not a protocol
issue?

As others pointed out, introducing SHA3 into the DNS right now is not
appropriate.

I see a use for clients telling the dns update server what the maximum
possibly lifetime can be, so it can go and perform a delete request on
behalf of vanished clients. But again I don't see this as a protocol
issue needing a TIMEOUT RRTYPE ?

Did I miss anything?

Paul

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org



___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Dick Franks]

On Tue, 19 Feb 2019 at 21:27, Tim Wattenberg  wrote:

> 8<

> RRSIG, SIG, TKEY (32 bits with serial number arithmetic relative to now)
> >
> > TSIG (48 bits)
>
> thanks for bringing up this point again. I was aware of the way RRSIG
> presents time but thanks for pointing us to TSIG – I hadn’t considered this
> earlier.
>

TSIG is an aberration. Using a timescale of 8.9 million years to specify a
window of a few minutes around the current time was a monumental blunder.



> Given these possible representations, is there a preference over one of
> the two?
>

Unsigned 32 bit RRSIG time is good for travel until 7th February 2106.
The fact that 2100 will not be a leap year is likely to be a bigger issue
than wrap-around.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Mark Andrews]

Think disaster recovery and promoting a slave to master.  You have to
transfer state between servers.  You can transfer it in band or out of
band.  If you transfer it out of band you need to invent / specify
yet-another-protocol to do it on top of specifying when records need to
be removed.

Mark

> On 20 Feb 2019, at 9:26 am, Paul Wouters  wrote:
> 
> 
> I have read the document.
> 
> I have a question about:
> 
>   A zone administrator may
>   want to enforce a default lifetime for dynamic updates (such as the
>   DHCP lease lifetime) or the DNS Update may contain a lifetime using
>   an EDNS(0) Update Lease option [I-D.sekar-dns-ul].
> 
> This seems a local policy and local implementation issue only.
> 
>  However, this
>  lease lifetime is not communicated to secondary servers and will not
>  endure through server software restarts.
> 
> Why does the secondary server need to know the lease lifetime? Only the
> primary needs to know this because it will need to purge the records and
> update the appropriate DNSSEC entries, something the secondary cannot do
> anyway? In fact, Section 8 agrees with me:
> 
>   A secondary server MUST NOT expire the records in a zone it maintains
>   covered by the TIMEOUT resource record and it MUST NOT expire the
>   TIMEOUT resource record itself when the last record it covers has
>   expired.  The secondary server MUST always wait for the records to be
>   removed or updated by the primary server.
> 
> So why is the TIMEOUT record needed? If the secondary argument is
> gone, the only argument left from the Introduction is server software
> restart. Which seems to me to be an application issue and not a protocol
> issue?
> 
> As others pointed out, introducing SHA3 into the DNS right now is not
> appropriate.
> 
> I see a use for clients telling the dns update server what the maximum
> possibly lifetime can be, so it can go and perform a delete request on
> behalf of vanished clients. But again I don't see this as a protocol
> issue needing a TIMEOUT RRTYPE ?
> 
> Did I miss anything?
> 
> Paul
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Wouters]

I have read the document.

I have a question about:

   A zone administrator may
   want to enforce a default lifetime for dynamic updates (such as the
   DHCP lease lifetime) or the DNS Update may contain a lifetime using
   an EDNS(0) Update Lease option [I-D.sekar-dns-ul].

This seems a local policy and local implementation issue only.

  However, this
  lease lifetime is not communicated to secondary servers and will not
  endure through server software restarts.

Why does the secondary server need to know the lease lifetime? Only the
primary needs to know this because it will need to purge the records and
update the appropriate DNSSEC entries, something the secondary cannot do
anyway? In fact, Section 8 agrees with me:

   A secondary server MUST NOT expire the records in a zone it maintains
   covered by the TIMEOUT resource record and it MUST NOT expire the
   TIMEOUT resource record itself when the last record it covers has
   expired.  The secondary server MUST always wait for the records to be
   removed or updated by the primary server.

So why is the TIMEOUT record needed? If the secondary argument is
gone, the only argument left from the Introduction is server software
restart. Which seems to me to be an application issue and not a protocol
issue?

As others pointed out, introducing SHA3 into the DNS right now is not
appropriate.

I see a use for clients telling the dns update server what the maximum
possibly lifetime can be, so it can go and perform a delete request on
behalf of vanished clients. But again I don't see this as a protocol
issue needing a TIMEOUT RRTYPE ?

Did I miss anything?

Paul

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Tim Wattenberg]

Tony,

> Am 19.02.2019 um 13:27 schrieb Tony Finch :
> 
> The DNS currently has a couple of representations of absolute (POSIX
> flavoured) time:
> 
> RRSIG, SIG, TKEY (32 bits with serial number arithmetic relative to now)
> 
> TSIG (48 bits)

thanks for bringing up this point again. I was aware of the way RRSIG presents 
time but thanks for pointing us to TSIG – I hadn’t considered this earlier.

Given these possible representations, is there a preference over one of the two?

Tim
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Robert Story]

On Tue 2019-02-19 12:28:08+1100 Mark wrote:
> Where is the need to use SHA-3?  This is introducing a new algorithm
> for the sake of introducing a new algorithm.  Just because TLS 1.3
> uses SHAKE128 is not a reason for DNS to use SHAKE128.  There are
> plenty of platforms that don’t need to use TLS at all.  They don’t
> have web interfaces.  Transaction security is provided by something
> other than TLS.
> 
> There are also lots of old server platforms that just won’t ever
> upgrade their OpenSSL package.  Adding SHA-3 creates yet another
> dependancy / impediment-to upgrading the DNS server.

I agree with Mark. Even the draft says:

5.  Cryptographic Hash Requirements

   The cryptographic hash algorithm used SHOULD provide the following
   properties:

   1.  Well known algorithm with implementations easily available

I have no objections to SHAKE128 being one of the supported algorithms,
but one of the SHA-2 algorithms should be selected for MUST implement.

-- 
Robert Story 
USC Information Sciences Institute 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Tony Finch]

Tom Pusateri  wrote:
>
> I think we have addressed all of the comments except for the Date format
> concern from Mark. That is still an outstanding issue.

The DNS currently has a couple of representations of absolute (POSIX
flavoured) time:

RRSIG, SIG, TKEY (32 bits with serial number arithmetic relative to now)

TSIG (48 bits)

It seems silly to invent a third one and prevent servers from re-using
code.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
the widest possible distribution of wealth

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Mark Andrews]

> On 19 Feb 2019, at 11:47 am, Tom Pusateri  wrote:
> 
> Mark,
> 
>> Just closing the issue isn’t addressing it.
> 
> That’s not a fair point about closing issue #19.
> 
> Your main concern was that SHA-3 algorithms might not be easily available 
> but, luckily, they shipped with TLS 1.3 in OpenSSL 1.1.1 and so I thought #19 
> was a solved issue.
> 
> Regardless, sooner or later, someone will be the first to use a SHA-3 
> algorithm that’s better than the SHA-2 algorithms DNS uses today. It’s only a 
> matter of time. SHA-3 has been out since 2015. As soon as you support TLS 
> 1.3, you’ll have all the SHA-3 algorithms with a simple API call and it 
> should be available everywhere because TLS 1.3 will be needed everywhere.

Where is the need to use SHA-3?  This is introducing a new algorithm for the 
sake of
introducing a new algorithm.  Just because TLS 1.3 uses SHAKE128 is not a 
reason for
DNS to use SHAKE128.  There are plenty of platforms that don’t need to use TLS 
at
all.  They don’t have web interfaces.  Transaction security is provided by 
something
other than TLS.

There are also lots of old server platforms that just won’t ever upgrade their 
OpenSSL
package.  Adding SHA-3 creates yet another dependancy / impediment-to upgrading 
the DNS
server.

And before someone mentions DoT and DoH. DoT/DoH have their uses but not 
everywhere
needs to use DoT/DoH.  DoT/DoH adds baggage which isn’t always justified.

Mark

> I will reopen this issue for discussion but I don’t see yet how this is a 
> problem.
> 
> Thanks,
> Tom
> 
>> On Feb 18, 2019, at 7:27 PM, Mark Andrews  wrote:
>> 
>> I have yet to seen a justification for using SHAKE128 vs any of the existing
>> hash algorithms used in DNS.  You really need to justify this choice on 
>> security
>> concerns.  DNS server implementers need to support multiple crypto backends 
>> and
>> adding yet another algorithm is not as easy as just calling OpenSSL.  It’s 
>> writing /
>> expanding a shim layer.  It’s checking for the existence on all the platforms
>> the server is built on.  
>> 
>> https://github.com/pusateri/draft-pusateri-dnsop-update-timeout/issues/19
>> 
>>> On 19 Feb 2019, at 10:34 am, Tom Pusateri  wrote:
>>> 
>>> DNSOP,
>>> 
>>> We have updated the TIMEOUT resource record draft based on the great 
>>> feedback from Mark Andrews, Joe Abley, Ted Lemon, and Paul Vixie. I think 
>>> we have addressed all of the comments except for the Date format concern 
>>> from Mark. That is still an outstanding issue. Please comment on it if you 
>>> have an opinion or feel free to open other issues against the document or 
>>> send comments to the list.
>>> 
>>> The TIMEOUT RR is just like any other resource record now with no special 
>>> handling.
>>> 
>>> Issues are on Github:
>>> https://github.com/pusateri/draft-pusateri-dnsop-update-timeout/issues
>>> 
>>> Thanks,
>>> Tom & Tim
>>> 
>>> 
 Begin forwarded message:
 
 From: internet-dra...@ietf.org
 Subject: New Version Notification for 
 draft-pusateri-dnsop-update-timeout-01.txt
 Date: February 18, 2019 at 6:26:35 PM EST
 To: "Tim Wattenberg" , "Tom Pusateri" 
 
 
 
 A new version of I-D, draft-pusateri-dnsop-update-timeout-01.txt
 has been successfully submitted by Tom Pusateri and posted to the
 IETF repository.
 
 Name:  draft-pusateri-dnsop-update-timeout
 Revision:  01
 Title: DNS TIMEOUT Resource Record
 Document date: 2019-02-18
 Group: Individual Submission
 Pages: 13
 URL:
 https://www.ietf.org/internet-drafts/draft-pusateri-dnsop-update-timeout-01.txt
 Status: 
 https://datatracker.ietf.org/doc/draft-pusateri-dnsop-update-timeout/
 Htmlized:   
 https://tools.ietf.org/html/draft-pusateri-dnsop-update-timeout-01
 Htmlized:   
 https://datatracker.ietf.org/doc/html/draft-pusateri-dnsop-update-timeout
 Diff:   
 https://www.ietf.org/rfcdiff?url2=draft-pusateri-dnsop-update-timeout-01
 
 Abstract:
 This specification defines a new DNS TIMEOUT resource record (RR)
 that associates a lifetime with one or more zone resource records
 with the same owner name, type, and class.  It is intended to be used
 to transfer resource record lifetime state between a zone's primary
 and secondary servers and to store lifetime state during server
 software restarts.
 
 
 
 
 Please note that it may take a couple of minutes from the time of 
 submission
 until the htmlized version and diff are available at tools.ietf.org.
 
 The IETF Secretariat
 
>>> 
>>> ___
>>> DNSOP mailing list
>>> DNSOP@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dnsop
>> 
>> -- 
>> Mark Andrews, ISC
>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>> PHONE: +61 2 9871 4742  INTERNET: 

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

[Tom Pusateri]

Mark,

> Just closing the issue isn’t addressing it.

That’s not a fair point about closing issue #19.

Your main concern was that SHA-3 algorithms might not be easily available but, 
luckily, they shipped with TLS 1.3 in OpenSSL 1.1.1 and so I thought #19 was a 
solved issue.

Regardless, sooner or later, someone will be the first to use a SHA-3 algorithm 
that’s better than the SHA-2 algorithms DNS uses today. It’s only a matter of 
time. SHA-3 has been out since 2015. As soon as you support TLS 1.3, you’ll 
have all the SHA-3 algorithms with a simple API call and it should be available 
everywhere because TLS 1.3 will be needed everywhere.

I will reopen this issue for discussion but I don’t see yet how this is a 
problem.

Thanks,
Tom

> On Feb 18, 2019, at 7:27 PM, Mark Andrews  wrote:
> 
> I have yet to seen a justification for using SHAKE128 vs any of the existing
> hash algorithms used in DNS.  You really need to justify this choice on 
> security
> concerns.  DNS server implementers need to support multiple crypto backends 
> and
> adding yet another algorithm is not as easy as just calling OpenSSL.  It’s 
> writing /
> expanding a shim layer.  It’s checking for the existence on all the platforms
> the server is built on.  
> 
> https://github.com/pusateri/draft-pusateri-dnsop-update-timeout/issues/19
> 
>> On 19 Feb 2019, at 10:34 am, Tom Pusateri  wrote:
>> 
>> DNSOP,
>> 
>> We have updated the TIMEOUT resource record draft based on the great 
>> feedback from Mark Andrews, Joe Abley, Ted Lemon, and Paul Vixie. I think we 
>> have addressed all of the comments except for the Date format concern from 
>> Mark. That is still an outstanding issue. Please comment on it if you have 
>> an opinion or feel free to open other issues against the document or send 
>> comments to the list.
>> 
>> The TIMEOUT RR is just like any other resource record now with no special 
>> handling.
>> 
>> Issues are on Github:
>> https://github.com/pusateri/draft-pusateri-dnsop-update-timeout/issues
>> 
>> Thanks,
>> Tom & Tim
>> 
>> 
>>> Begin forwarded message:
>>> 
>>> From: internet-dra...@ietf.org
>>> Subject: New Version Notification for 
>>> draft-pusateri-dnsop-update-timeout-01.txt
>>> Date: February 18, 2019 at 6:26:35 PM EST
>>> To: "Tim Wattenberg" , "Tom Pusateri" 
>>> 
>>> 
>>> 
>>> A new version of I-D, draft-pusateri-dnsop-update-timeout-01.txt
>>> has been successfully submitted by Tom Pusateri and posted to the
>>> IETF repository.
>>> 
>>> Name:   draft-pusateri-dnsop-update-timeout
>>> Revision:   01
>>> Title:  DNS TIMEOUT Resource Record
>>> Document date:  2019-02-18
>>> Group:  Individual Submission
>>> Pages:  13
>>> URL:
>>> https://www.ietf.org/internet-drafts/draft-pusateri-dnsop-update-timeout-01.txt
>>> Status: 
>>> https://datatracker.ietf.org/doc/draft-pusateri-dnsop-update-timeout/
>>> Htmlized:   
>>> https://tools.ietf.org/html/draft-pusateri-dnsop-update-timeout-01
>>> Htmlized:   
>>> https://datatracker.ietf.org/doc/html/draft-pusateri-dnsop-update-timeout
>>> Diff:   
>>> https://www.ietf.org/rfcdiff?url2=draft-pusateri-dnsop-update-timeout-01
>>> 
>>> Abstract:
>>>  This specification defines a new DNS TIMEOUT resource record (RR)
>>>  that associates a lifetime with one or more zone resource records
>>>  with the same owner name, type, and class.  It is intended to be used
>>>  to transfer resource record lifetime state between a zone's primary
>>>  and secondary servers and to store lifetime state during server
>>>  software restarts.
>>> 
>>> 
>>> 
>>> 
>>> Please note that it may take a couple of minutes from the time of submission
>>> until the htmlized version and diff are available at tools.ietf.org.
>>> 
>>> The IETF Secretariat
>>> 
>> 
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
> 
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org
> 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Mark Andrews]

I have yet to seen a justification for using SHAKE128 vs any of the existing
hash algorithms used in DNS.  You really need to justify this choice on security
concerns.  DNS server implementers need to support multiple crypto backends and
adding yet another algorithm is not as easy as just calling OpenSSL.  It’s 
writing /
expanding a shim layer.  It’s checking for the existence on all the platforms
the server is built on.  Just closing the issue isn’t addressing it.

https://github.com/pusateri/draft-pusateri-dnsop-update-timeout/issues/19

> On 19 Feb 2019, at 10:34 am, Tom Pusateri  wrote:
> 
> DNSOP,
> 
> We have updated the TIMEOUT resource record draft based on the great feedback 
> from Mark Andrews, Joe Abley, Ted Lemon, and Paul Vixie. I think we have 
> addressed all of the comments except for the Date format concern from Mark. 
> That is still an outstanding issue. Please comment on it if you have an 
> opinion or feel free to open other issues against the document or send 
> comments to the list.
> 
> The TIMEOUT RR is just like any other resource record now with no special 
> handling.
> 
> Issues are on Github:
> https://github.com/pusateri/draft-pusateri-dnsop-update-timeout/issues
> 
> Thanks,
> Tom & Tim
> 
> 
>> Begin forwarded message:
>> 
>> From: internet-dra...@ietf.org
>> Subject: New Version Notification for 
>> draft-pusateri-dnsop-update-timeout-01.txt
>> Date: February 18, 2019 at 6:26:35 PM EST
>> To: "Tim Wattenberg" , "Tom Pusateri" 
>> 
>> 
>> 
>> A new version of I-D, draft-pusateri-dnsop-update-timeout-01.txt
>> has been successfully submitted by Tom Pusateri and posted to the
>> IETF repository.
>> 
>> Name:draft-pusateri-dnsop-update-timeout
>> Revision:01
>> Title:   DNS TIMEOUT Resource Record
>> Document date:   2019-02-18
>> Group:   Individual Submission
>> Pages:   13
>> URL:
>> https://www.ietf.org/internet-drafts/draft-pusateri-dnsop-update-timeout-01.txt
>> Status: 
>> https://datatracker.ietf.org/doc/draft-pusateri-dnsop-update-timeout/
>> Htmlized:   
>> https://tools.ietf.org/html/draft-pusateri-dnsop-update-timeout-01
>> Htmlized:   
>> https://datatracker.ietf.org/doc/html/draft-pusateri-dnsop-update-timeout
>> Diff:   
>> https://www.ietf.org/rfcdiff?url2=draft-pusateri-dnsop-update-timeout-01
>> 
>> Abstract:
>>   This specification defines a new DNS TIMEOUT resource record (RR)
>>   that associates a lifetime with one or more zone resource records
>>   with the same owner name, type, and class.  It is intended to be used
>>   to transfer resource record lifetime state between a zone's primary
>>   and secondary servers and to store lifetime state during server
>>   software restarts.
>> 
>> 
>> 
>> 
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>> 
>> The IETF Secretariat
>> 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Tom Pusateri]

DNSOP,

We have updated the TIMEOUT resource record draft based on the great feedback 
from Mark Andrews, Joe Abley, Ted Lemon, and Paul Vixie. I think we have 
addressed all of the comments except for the Date format concern from Mark. 
That is still an outstanding issue. Please comment on it if you have an opinion 
or feel free to open other issues against the document or send comments to the 
list.

The TIMEOUT RR is just like any other resource record now with no special 
handling.

Issues are on Github:
https://github.com/pusateri/draft-pusateri-dnsop-update-timeout/issues

Thanks,
Tom & Tim


> Begin forwarded message:
> 
> From: internet-dra...@ietf.org
> Subject: New Version Notification for 
> draft-pusateri-dnsop-update-timeout-01.txt
> Date: February 18, 2019 at 6:26:35 PM EST
> To: "Tim Wattenberg" , "Tom Pusateri" 
> 
> 
> 
> A new version of I-D, draft-pusateri-dnsop-update-timeout-01.txt
> has been successfully submitted by Tom Pusateri and posted to the
> IETF repository.
> 
> Name: draft-pusateri-dnsop-update-timeout
> Revision: 01
> Title:DNS TIMEOUT Resource Record
> Document date:2019-02-18
> Group:Individual Submission
> Pages:13
> URL:
> https://www.ietf.org/internet-drafts/draft-pusateri-dnsop-update-timeout-01.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-pusateri-dnsop-update-timeout/
> Htmlized:   
> https://tools.ietf.org/html/draft-pusateri-dnsop-update-timeout-01
> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-pusateri-dnsop-update-timeout
> Diff:   
> https://www.ietf.org/rfcdiff?url2=draft-pusateri-dnsop-update-timeout-01
> 
> Abstract:
>   This specification defines a new DNS TIMEOUT resource record (RR)
>   that associates a lifetime with one or more zone resource records
>   with the same owner name, type, and class.  It is intended to be used
>   to transfer resource record lifetime state between a zone's primary
>   and secondary servers and to store lifetime state during server
>   software restarts.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop