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

From: Tom Pusateri <[email-masked]>
Date: Mon, 18 Feb 2019 18:34:13 -0500

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: [email-masked]
> 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" <[email-masked]>, "Tom Pusateri" <[email-masked]>
> 
> 
> 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
>

---

From: Mark Andrews <[email-masked]>
Date: Tue, 19 Feb 2019 11:27:44 +1100

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 <[email-masked]> wrote:
> 
> DNSOP,
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

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

---

From: Tom Pusateri <[email-masked]>
Date: Mon, 18 Feb 2019 19:47:39 -0500

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 <[email-masked]> wrote:
> 
> the server is built on.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 19 Feb 2019 12:28:08 +1100

> On 19 Feb 2019, at 11:47 am, Tom Pusateri <[email-masked]> wrote:
> 
> Mark,
> 

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

---

From: Tony Finch <[email-masked]>
Date: Tue, 19 Feb 2019 12:27:21 +0000

Tom Pusateri <[email-masked]> 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.finch  <[email-masked]>  http://dotat.at/
the widest possible distribution of wealth

---

From: Robert Story <[email-masked]>
Date: Tue, 19 Feb 2019 15:41:38 -0500

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 <http://www.isi.edu/~rstory>
USC Information Sciences Institute <http://www.isi.edu/>

---

From: Tim Wattenberg <[email-masked]>
Date: Tue, 19 Feb 2019 22:26:42 +0100

Tony,

> Am 19.02.2019 um 13:27 schrieb Tony Finch <[email-masked]>:
> 

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

---

From: Paul Wouters <[email-masked]>
Date: Tue, 19 Feb 2019 17:26:54 -0500 (EST)

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

---

From: Mark Andrews <[email-masked]>
Date: Wed, 20 Feb 2019 09:36:41 +1100

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 <[email-masked]> wrote:
> 
>

---

From: Dick Franks <[email-masked]>
Date: Wed, 20 Feb 2019 01:10:43 +0000

On Tue, 19 Feb 2019 at 21:27, Tim Wattenberg <[email-masked]> wrote:

> 8<

> 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

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.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 20 Feb 2019 00:35:09 -0500 (EST)

> yet-another-protocol to do it on top of specifying when records need to

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

---

From: Mark Andrews <[email-masked]>
Date: Wed, 20 Feb 2019 18:46:28 +1100

> On 20 Feb 2019, at 4:35 pm, Paul Wouters <[email-masked]> wrote:
> 
> 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.

> promotion of secondary to master either.

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

> 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.

---

From: Tony Finch <[email-masked]>
Date: Wed, 20 Feb 2019 12:35:49 +0000

> 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.finch  <[email-masked]>  http://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.

---

From: Tim Wattenberg <[email-masked]>
Date: Wed, 20 Feb 2019 13:44:34 +0100

Dick,

> On 20. Feb 2019, at 13:35, Tony Finch <[email-masked]> wrote:
> 

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

Tim

---

From: Joe Abley <[email-masked]>
Date: Wed, 20 Feb 2019 07:51:51 -0500

> 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

---

From: Ted Lemon <[email-masked]>
Date: Wed, 20 Feb 2019 06:44:00 -0800

> 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 UPDAT…

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 <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.

---

From: Dick Franks <[email-masked]>
Date: Wed, 20 Feb 2019 14:50:12 +0000

> 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.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 21 Feb 2019 06:15:52 +1100

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 AAAA 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 (AAAA) 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 AAAA 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 <[email-masked]> wrote:
>

---

From: Tony Finch <[email-masked]>
Date: Wed, 20 Feb 2019 19:30:17 +0000

Mark Andrews <[email-masked]> 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.finch  <[email-masked]>  http://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.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 20 Feb 2019 11:32:45 -0800

> 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

---

From: Mark Andrews <[email-masked]>
Date: Thu, 21 Feb 2019 08:09:49 +1100

> On 21 Feb 2019, at 6:30 am, Tony Finch <[email-masked]> wrote:
> 

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

---

From: Tony Finch <[email-masked]>
Date: Thu, 21 Feb 2019 12:24:55 +0000

Mark Andrews <[email-masked]> wrote:
> 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.finch  <[email-masked]>  http://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.

---

From: Dick Franks <[email-masked]>
Date: Thu, 21 Feb 2019 14:11:04 +0000

> 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

---

From: Ted Lemon <[email-masked]>
Date: Thu, 21 Feb 2019 07:12:43 -0800

> A more radical approach would be to have just one hash per item per record.

One way to make this document less complex yet just as useful would be to simply have a record that contains what is to be deleted, rather than a hash of what is to be deleted.   It’s not at all clear to me that there’s value in using the hash—to me it just seems to create uncertainty.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 22 Feb 2019 06:05:01 +1100

Hashes save space once the rdata is bigger than the hash.
-- 
Mark Andrews

> On 22 Feb 2019, at 02:12, Ted Lemon <[email-masked]> wrote:
>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 21 Feb 2019 11:11:01 -0800

> Hashes save space once the rdata is bigger than the hash.

Agreed, but why do we need to save space?  It would be possible to have the data structure that stores the delete RR point to the RR that’s to be deleted, so if on-disk or in-memory efficiency is really important, this would address that.   In practice, though, this option isn’t likely to be in use on servers, like large ISP caches, where space is at a premium.   So this seems like a false economy.

---

From: 神明達哉 <[email-masked]>
Date: Thu, 21 Feb 2019 11:21:50 -0800

At Wed, 20 Feb 2019 07:51:51 -0500,
Joe Abley <[email-masked]> 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

---

From: Mark Andrews <[email-masked]>
Date: Fri, 22 Feb 2019 06:24:43 +1100

Ted. It has to work post zone transfer.

Mark

-- 
Mark Andrews

> On 22 Feb 2019, at 06:11, Ted Lemon <[email-masked]> wrote:
>

---

From: Mark Andrews <[email-masked]>
Date: Fri, 22 Feb 2019 06:34:04 +1100

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, 神明達哉 <[email-masked]> wrote:
> 
> > 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.
> 
> proposal..  As Mark says not all DHCP servers behave politely; there

---

From: Paul Vixie <[email-masked]>
Date: Thu, 21 Feb 2019 12:05:35 -0800

Ted Lemon wrote on 2019-02-21 11:11:
> Agreed, but why do we need to save space?  It would be possible to
> have the data structure that stores the delete RR point to the RR
> that’s to be deleted, so if on-disk or in-memory efficiency is really
> important, this would address that.   In practice, though, this
> option isn’t likely to be in use on servers, like large ISP caches,
> where space is at a premium.   So this seems like a false economy.

+1. again, this is how DEFUPD worked in 1996, and for this reason.

-- 
P Vixie

---

From: Ted Lemon <[email-masked]>
Date: Thu, 21 Feb 2019 13:02:56 -0800

> Ted. It has to work post zone transfer.

That’s not a problem, since the representation would be more compact, but would not be lossy: the interchange through the zone transfer would be the same regardless of how the data is stored.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 22 Feb 2019 09:24:35 +1100

> On 22 Feb 2019, at 8:02 am, Ted Lemon <[email-masked]> wrote:
> 

Implementation details are beyond the scope of RFCs.

Also you mentioned caches which basically will never see these records unless they are queried for.

Yes, there is a minuscule probability of a hash collision.  The alternative is to define a type for rdlen + rdata in canonical DNSSEC form. The primary server can use/replace a hash when the rdata + length is longer than the hash, checking for collisions first.  If such a type is defined I would give it the value 1 and make the first actual hash 2.

Additionally in section 4.5 Cryptographic Hashes

"Any names contained in a resource record MUST be hashed in an uncompressed form."

needs to be replaced with

"The record MUST be in canonical DNSSEC form ([RFC4034] Section 6)."

The latter works with primary servers that don’t preserve case when transferring zones.
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Joe Abley <[email-masked]>
Date: Thu, 21 Feb 2019 17:52:50 -0500

> 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

---

From: Ted Lemon <[email-masked]>
Date: Thu, 21 Feb 2019 15:22:16 -0800

On Feb 21, 2019, at 2:52 PM, Joe Abley <[email-masked]> 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.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 22 Feb 2019 10:22:32 +1100

> On 22 Feb 2019, at 9:52 am, Joe Abley <[email-masked]> wrote:
> 
> 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 standardi…

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'…

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

---

From: Ted Lemon <[email-masked]>
Date: Thu, 21 Feb 2019 15:29:02 -0800

> Implementation details are beyond the scope of RFCs.

Indeed they are.  My point is that if you want to be careful of memory usage or disk usage, you can be—there is no need to use a hash.   In essence, requiring us to use a hash is specifying an implementation detail that needn’t be specified: you can in fact implement this using a hash, although I wouldn’t.   It would be nice if I were not required to implement it that way, since I think that’s not actually going to work reliably.

> Also you mentioned caches which basically will never see these records unless they are queried for.

I mentioned caches because they are by far the biggest consumers of resources—authoritative name servers have much smaller memory footprints.   I assume the reason you think using hashes is a good idea and not a premature optimization is because you’ve done a lot of work with caching name servers, and are seeing this discussion through that lens.   That’s the wrong lens to be seeing it through.   This is only relevant for authoritative name servers, and in that case, storing the whole RR-to-be-deleted is fine.

---

From: Tom Pusateri <[email-masked]>
Date: Thu, 21 Feb 2019 22:19:30 -1000

> On Feb 21, 2019, at 1:29 PM, Ted Lemon <[email-masked]> wrote:
> 
> On Feb 21, 2019, at 2:24 PM, Mark Andrews <[email-masked] <mailto:[email-masked]>> wrote:

I’ve been mostly listening and learning from this discussion which has been great. Thanks for all the input. Let me summarize what I’m hearing and we will open issues to adjust the document.

1. We need a motivational section to explain the purpose better

2. The HASH was my idea to simplify the records by making them all the same. It appears that simplicity in this form was not noticed or not appreciated. :)

3. The HASH algorithm selection was intended to work long term. It was my hope that there would only ever be one algorithm and there would never exist the case when one implementation supported an algorithm that another implementation did not. The HASH algorithm index was only intended to be used if a vulnerability was found in the ONE selected algorithm and it needed replaced. In this case, the old algorithm would be deprecated and everyone would switch to a new single algorithm. I am strongly opposed to having more than one HASH algorithm defined. Not being a security expert and not being able to find any papers proving that I could take an existing algorithm like SHA-256 that was 32 bytes and shorten it to 16 bytes using the first 16 bytes or the last 16 bytes or 16 bytes in the middle, I opted to select an algorithm that was already 16 bytes and proven to have terrific non-collision properties. Since some of the RDATA can be very short (A records), there are cases when there’s not a lot of data from which to base the hash value on. This was another reason to start with a hash like SHAKE128. But from the sounds of it, people prefer SHA-256 and so I will research this more to see about its applicability in this case (if a hash is even needed anymore).

4. We are open to using RDATA instead of a hash. Or we can define RDATA as an algorithm index as Mark suggested and define a hash as another algorithm (now or later if it ever becomes a problem). By adding the record type to the TIMEOUT instance, we have eliminated most uses of the hash already and only in rare cases will it be needed so including large RDATA in the TIMEOUT record should be rare.

5. Storing the TIMEOUT information as resource records seemed like a convenient way to use an existing database to store timeout information across restarts and to synchronize with secondaries. It can certainly be stored in a proprietary database by each authoritative server vendor but allowing them to interoperate seemed like a feature and when they each already have a database that holds resource records, why create another database type? But if the consensus is that the TIMEOUT info shouldn’t be stored in the existing resource record database but instead authoritative servers should create a new database for this info, then that is fine. This document itself can TIMEOUT. :)

Thanks,
Tom

---

From: Tom Pusateri <[email-masked]>
Date: Thu, 21 Feb 2019 22:53:03 -1000

> On Feb 21, 2019, at 10:19 PM, Tom Pusateri <[email-masked]> wrote:
> 
> 
> 
>> On Feb 21, 2019, at 1:29 PM, Ted Lemon <[email-masked] <mailto:[email-masked]>> wrote:
>> 

Forgot these:

6. As far as the time format, we were simply following the recommendations of RFC 3339 for presentation. But if DNS has it’s own format preferences and the IESG is ok with this, so are we. Following RFC 3339 is a SHOULD, therefore, there must be exceptions allowed but I’m not aware of the rules here.

7. As far as the timestamp as a 64-bit number, this is the current recommendation as well (and what is returned by gettimeofday()). So every authoritative server is having to modify the output and do more work to transform it into RFC 1982 serial number arithmetic now. But, again, we are flexible and as long as the IESG will approve it, we can do it the old way.

8. Mark said: "The record MUST be in canonical DNSSEC form ([RFC4034] Section 6)”. I will update Section 4.5 to reflect this.

Tom