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

From: Tom Pusateri <[email-masked]>
Date: Thu, 23 Aug 2018 20:53:51 -0400

This is a new draft for your review.

It is aimed at authoritative servers that handle DNS Update messages. It provides a way for the authoritative server to put a bounds on the lifetime of the added records and a way to share that lifetime with secondary servers.

If you run an Update server, we would love to have your feedback as to the usefulness of this new record type. If you maintain authoritative server software, we would love to have your feedback on whether this is something you would consider implementing or taking a pull request for.

Thanks,
Tom & Tim

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt
> Date: August 23, 2018 at 8:47:39 PM EDT
> To: "Tim Wattenberg" <[email-masked]>, "Tom Pusateri" <[email-masked]>
> 
> 
> A new version of I-D, draft-pusateri-dnsop-update-timeout-00.txt
> has been successfully submitted by Tom Pusateri and posted to the
> IETF repository.
> 
> Name:		draft-pusateri-dnsop-update-timeout
> Revision:	00
> Title:		DNS TIMEOUT Resource Record
> Document date:	2018-08-23
> Group:		Individual Submission
> Pages:		10
> URL:            https://www.ietf.org/internet-drafts/draft-pusateri-dnsop-update-timeout-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-pusateri-dnsop-update-timeout/
> Htmlized:       https://tools.ietf.org/html/draft-pusateri-dnsop-update-timeout-00
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-pusateri-dnsop-update-timeout
> 
> 
> 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 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: Paul Vixie <[email-masked]>
Date: Thu, 23 Aug 2018 18:23:19 -0700

tom, tim, thanks for this. i have two concerns, and three observations.

concern #1 is about this text:

>    3.  TIMEOUT resource records are not automatically sent in AXFR, IXFR
>        zone transfer requests.  Both primary and secondary servers
>        should be configured on a per zone basis to transfer TIMEOUT
>        resource records to ensure they are supported.

this is impractical given the high automation usually now involved in 
primary/secondary AXFR and IXFR relationships. i suggest negotiating for 
this with an OPT RR in the AXFR or IXFR request, indicating whether the 
initiator ("secondary" in this document) supports TIMEOUT or not.

concern #2:

you don't appear to have addressed TTL overrun here. it's necessary for 
a record which will expire to have a declining TTL as that expiry time 
nears. if it's always been 3600, then when you're within one hour of 
expiry time, returned TTL has to be reduced to whatever time remains.

observation #1:

none of the crypto seems nec'y. i would not quibble about it except that 
since it is crypto it will have to morph over time to become stronger 
against growing brute-force attacks and vuln research. this puts a 
maintainance burden on the community every time we encode crypto into a 
protocol. can you explain why the TIMEOUT RDATA isn't in clear text?

observation #2:

might you arrange for an _-related schema, so that each RRset having a 
TIMEOUT can have those records as a niece/nephew domain? for WWW.FSI.IO 
AAAA, the TIMEOUT would be at AAAA._TIMEOUT.FSI.IO, in this case.

observation #3:

this was all considered previously. most recently it was the subject of 
an apple patent (EP1759516) by cheshire and sekar. first and foremost it 
was proposed in the old DNSIND working group by myself, in 1996. you 
don't have to worry about the patent, due to my prior art. since the 
draft is expired, i've put a copy online here:

http://family.redbarn.org/~vixie/defupd.txt

the IETF DNSIND WG rejected this draft on the basis of its complexity. 
the idea of a zone having timers inside it, for self-modification, was 
just a bridge too far at that time. given what is now called "the camel" 
i think pendulum has swung _well_ away from that point of view, but is 
now in the process of swinging back. if i had hope, i would submit 
DEFUPD again, exactly as it was in 1996, because it still deftly threads 
the needle posed by UPDATE. your needs may differ.

"good luck storming the castle, boys!" (_The Princess Bride_)

vixie

re:

https://www.ietf.org/internet-drafts/draft-pusateri-dnsop-update-timeout-00.txt

---

From: Tom Pusateri <[email-masked]>
Date: Thu, 23 Aug 2018 23:44:57 -0400

Paul,

Thanks for the feedback!

An RRset isn’t granular enough because the components of the set could come from different clients with different timeout values.
Therefore, a unique identifier is needed for each record. The hash provides that unique identifier since it is calculated over the entire record including the unique RDATA.

The contents of the TIMEOUT RDATA field are not encrypted. The list of hashes are the list of unique identifiers. If each record had a unique identifier, we could use that instead but because they don’t, we create one with the hash.

The AAAA._TIMEOUT.FSI.IO idea is a neat one that we hadn’t thought of but it isn’t unique to a record with a potentially different timeout value from a different client and only works if all the members of the RRset have the same timeout.

We’ll take a look at your TTL concern and your previous draft.

Thanks!

Tom

> On Aug 23, 2018, at 9:23 PM, Paul Vixie <[email-masked]> wrote:
> 
> this is impractical given the high automation usually now involved in primary/secondary AXFR and IXFR relationships. i suggest negotiating for this with an OPT RR in the AXFR or IXFR request, indicating whether the initiator ("secondary" in this document) supports TIMEOUT or not.
> 
> concern #2:
> 
> you don't appear to have addressed TTL overrun here. it's necessary for a record which will expire to have a declining TTL as that expiry time nears. if it's always been 3600, then when you're within one hour of expiry time, returned TTL has to be reduced to whatever time remains.
> 
> observation #1:
> 
> none of the crypto seems nec'y. i would not quibble about it except that since it is crypto it will have to morph over time to become stronger against growing brute-force attacks and vuln research. this puts a maintainance burden on the community every time we encode crypto into a protocol. can you explain why the TIMEOUT RDATA isn't in clear text?
> 
> observation #2:
> 
> might you arrange for an _-related schema, so that each RRset having a TIMEOUT can have those records as a niece/nephew domain? for WWW.FSI.IO AAAA, the TIMEOUT would be at AAAA._TIMEOUT.FSI.IO, in this case.
> 
> observation #3:
> 
> this was all considered previously. most recently it was the subject of an apple patent (EP1759516) by cheshire and sekar. first and foremost it was proposed in the old DNSIND working group by myself, in 1996. you don't have to worry about the patent, due to my prior art. since the draft is expired, i've put a copy online here:
> 
> the IETF DNSIND WG rejected this draft on the basis of its complexity. the idea of a zone having timers inside it, for self-modification, was just a bridge too far at that time. given what is now called "the camel" i think pendulum has swung _well_ away from that point of view, but is now in the process of swinging back. if i had hope, i would submit DEFUPD again, exactly as it was in 1996, because it still deftly threads the needle posed by UPDATE. your needs may differ.
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Tom Pusateri <[email-masked]>
Date: Fri, 24 Aug 2018 00:03:23 -0400

I don’t think there is a TTL issue because, as we proposed it, the record is never returned in a query. The TTL could always be set to 0 for our purposes since it never leaves the authoritative servers.

Tom

> On Aug 23, 2018, at 11:44 PM, Tom Pusateri <[email-masked]> wrote:
> 
> Paul,
> 
> Thanks for the feedback!
>

---

From: Paul Vixie <[email-masked]>
Date: Fri, 24 Aug 2018 00:13:22 -0700

Tom Pusateri wrote:
> I don’t think there is a TTL issue because, as we proposed it, the
> record is never returned in a query. The TTL could always be set to 0
> for our purposes since it never leaves the authoritative servers.

tom, (tim,) to be clear, the ttl which must decline is that of the 
expiring record (or its rrset, due to atomicity), and not that of the 
TIMEOUT RR itself. you cannot hand out an AAAA or PTR (or in the 
degenerate case, an A RR) with a TTL of 3600 if it is due to expire in 
600 seconds. that RR has to have its TTL adjusted during its final 
authority-TTL interval so that noone has it in cache beyond the time of 
its death by expiry.

in <http://family.redbarn.org/~vixie/defupd.txt> from 1996, this is 
described as follows:

> 3.4.1 - Initial TTL Limits
>
>    The TTL of all added or updated RRs in the Update Section will be
>    maximized silently to one half of the Expiry time.  This will cause
>    downstream caching name servers to purge RRsets containing this RR at
>    least once before expiry.
>
> 3.4.2 - TTL Half Life
>
>    Each time an RR's expiry reaches half of its previous value, that RR's
>    TTL will be reduced to half of its previous value, until the TTL reaches
>    a value less than or equal to sixty (60), i.e., one minute of real time,
>    at which time the TTL will not be automatically reduced further by the
>    primary master.  It should be noted that RRs held in a server's memory
>    need not be swept for half life processing, as long as the TTL changes
>    appear when the RR next becomes externally visible, and as long as the
>    ``zone has changed'' processing (see below) is done at the time of the
>    half life expiration.
>
>    Whenever the TTL is automatically reduced by this process, the zone will
>    be considered ``changed'' for the purpose of automatic SOA SERIAL
>    increment (see [UPDATE 3.6]) and real time zone slave notification (see
>    [NOTIFY]).

-- 
P Vixie

---

From: Mark Andrews <[email-masked]>
Date: Fri, 24 Aug 2018 17:26:25 +1000

> On 24 Aug 2018, at 5:13 pm, Paul Vixie <[email-masked]> wrote:
> 
> 
> 
> Tom Pusateri wrote:
> tom, (tim,) to be clear, the ttl which must decline is that of the expiring record (or its rrset, due to atomicity), and not that of the TIMEOUT RR itself. you cannot hand out an AAAA or PTR (or in the degenerate case, an A RR) with a TTL of 3600 if it is due to expire in 600 seconds. that RR has to have its TTL adjusted during its final authority-TTL interval so that noone has it in cache beyond the time of its death by expiry.

That’s one way of doing it.  Given the DNS is loosely coherent I really
would just leave it as the time the record is removed from the zone and
not play TTL games which require every server for the zone to support
the extension.  If you are worried about records being in the cache too
long use a smaller TTL from the start.

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

---

From: Paul Vixie <[email-masked]>
Date: Fri, 24 Aug 2018 00:38:51 -0700

Mark Andrews wrote:
>
>> On 24 Aug 2018, at 5:13 pm, Paul Vixie<[email-masked]>  wrote:
...
>> expiring record (or its rrset, due to atomicity), and not that of
>> the TIMEOUT RR itself. you cannot hand out an AAAA or PTR (or in
>> the degenerate case, an A RR) with a TTL of 3600 if it is due to
>> expire in 600 seconds. that RR has to have its TTL adjusted during
>> its final authority-TTL interval so that noone has it in cache
>> beyond the time of its death by expiry.
>
> That’s one way of doing it.  Given the DNS is loosely coherent I
> really would just leave it as the time the record is removed from the
> zone and not play TTL games which require every server for the zone
> to support the extension.  If you are worried about records being in
> the cache too long use a smaller TTL from the start.

that may be nec'y given that this is not a deferred update mechanism, 
which is what led in 1996 to the half-life auto-update for propagation.

however, every authority server MUST support the TIMEOUT RR as proposed 
-- that's why i proposed that the configuration for it be negotiated via 
OPT rather than statically configured as proposed. so, every such server 
can have tickdown logic to avoid the bad choice between too-short TTL 
and too-stale data.

-- 
P Vixie

---

From: Mark Andrews <[email-masked]>
Date: Fri, 24 Aug 2018 17:46:03 +1000

This is unnecessary.  All the rule does is limit the process to class IN zones.  UPDATE, IXFR and AXFR are class agnostic.

1.  TIMEOUT resource records are only defined for CLASS IN.

This seems overly restrictive.  I would allow TIMEOUT records that
match added records to be accepted.

5.  TIMEOUT resource records cannot be directly added, modified, or
       deleted through DNS Update.

Secondary servers that are TIMEOUT aware should ignore TIMEOUT records
beyond storing them in case the server get promoted to being the master.

Is the secondary going to be able regenerate the RRset as the records are
removed as well as generate and sign NSEC and NSEC3 records?

Sources of TIMEOUT Expiry Time

Add matching TIMEOUT records added via UPDATE.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 24 Aug 2018 09:11:28 -0400

> Therefore, a unique identifier is needed for each record. The hash provides that unique identifier since it is calculated over the entire record including the unique RDATA.

The hash stuff seems like a premature optimization.   I can think of two other ways to do this: either just send the contents of the RR, or use an index into the RRset and define a sorting order.   Bearing in mind that there's no reason for any server to store this data internally as anything other than an additional tuple in the RR itself, hashes may be the least efficient way to implement this.   Remember that for zone transfers, either you transfer the whole zone, or you transfer the differences, and in either case the zone contents for any zone serial number should always be the same.

Another question to ask here is, what is the application for this?   If it's just for DNSSD Registration, then it might be better to implement it in a less general way.  It would be worth scoping this before saying that it has to be done this way.   When Stuart and I talked about this, we had a much simpler model in mind; your model is certainly more general, but who's the customer?   I'm not saying your model is wrong, just that we ought to discuss it explicitly.

If a zone is signed, are the TIMEOUT records signed?

---

From: Ted Lemon <[email-masked]>
Date: Fri, 24 Aug 2018 09:22:11 -0400

On Aug 23, 2018, at 9:23 PM, Paul Vixie <[email-masked]> wrote:
> http://family.redbarn.org/~vixie/defupd.txt <http://family.redbarn.org/~vixie/defupd.txt>
> 

I think that defupd is the core of a good idea, but it's more complicated than it needs to be.   Another way to accomplish the same thing would be to have an RR that just contains an update and a time when the update is to be done, hanging off of the name to be updated.   This could be included in the DNS update that creates the record, or created automatically by the server based on the update lease EDNS(0) option.

IOW I don't think there's any need for a new DEFUPD opcode, but the idea otherwise ought to be considered alongside Tom's proposal to see which one we think is easier to specify and implement.

---

From: Tom Pusateri <[email-masked]>
Date: Fri, 24 Aug 2018 09:52:48 -0400

> On Aug 24, 2018, at 9:11 AM, Ted Lemon <[email-masked]> wrote:
> 

We thought about sorting and indexing but that seemed way more error prone and not as general. The hash is a general solution that works well for these immediate uses and for any future uses that we can’t anticipate. It also provides the basis of a unique identifier that could be used for other non-related DNS extensions that need a unique identifier, so this code could be re-used. With the current libraries available, it’s not particularly complicated or onerous. 

> Another question to ask here is, what is the application for this?   If it's just for DNSSD Registration, then it might be better to implement it in a less general way.  It would be worth scoping t…

Yes, it was intended to be more general than for service registration. It’s directly applicable to name registration for IP addresses. I can add a section on other uses if more motivation is desired. Mark Andrews had some uses as well that hopefully, he can share. If others have uses in mind that this solves I would love to hear about them.

> If a zone is signed, are the TIMEOUT records signed?

No. The draft says they are skipped.

Thanks,
Tom

---

From: Ted Lemon <[email-masked]>
Date: Fri, 24 Aug 2018 09:54:58 -0400

> Yes, it was intended to be more general than for service registration. It’s directly applicable to name registration for IP addresses. I can add a section on other uses if more motivation is desire…

The reason I'm asking is not that I don't think there are theoretical use cases for what you are proposing.   I'm asking if there are actual use cases.   How would this be used in practice?   What can't someone do right now that they need to do and that this new technology enables?

---

From: Joe Abley <[email-masked]>
Date: Fri, 24 Aug 2018 10:11:34 -0400

Hi Tom,

> On Aug 24, 2018, at 09:52, Tom Pusateri <[email-masked]> wrote:
> 

New RRTypes are supposed to be handled by old software that pre-dates them because they can be treated as opaque types. That's not the case if new RRTypes are encumbered with requirements for special handling at query or signing time (as described in your section 2).

This seems like a significant architectural change that in effect updates 1034 and 1035 as well as 3597. This would be a much more straightforward and uncontroversial proposal if it was simply a specification for use of a new RRType that made no changes at all to the rest of the protocol.

I have not read your draft in detail but I think you probably would also need to spend more time considering the cases of old, non-TIMEOUT authority servers that wind up serving zones that contain TIMEOUT RRSets (e.g. third-party hosting services). Client handling of rogue RRSIGs, RCODE=NOERROR with ANSWER sections containing TIMEOUT RRSets, etc.

This all seems a bit messy, to be honest.

Joe

---

From: Tom Pusateri <[email-masked]>
Date: Fri, 24 Aug 2018 12:38:24 -0400

> On Aug 24, 2018, at 10:11 AM, Joe Abley <[email-masked]> wrote:
> 
> Hi Tom,
> 

Yes, the draft says the primary has to agree to send them to the secondary and the secondary has to agree to accept them (administratively). This prevents old authority servers from having to deal with them.

The position of not having them signed is a consequence of not having them returned in a query. If you can’t see them in a query, you can’t do NSEC/NSEC3/NSEC5 next record semantics so we skip them.

By simply making them returned in a query, we can avoid most of your objections. Mark Andrews suggested they not be returned in a query in a hallway discussion and I’m happy to change if that’s the preferred approach.

Thanks for the feedback!

Tom

---

From: Tom Pusateri <[email-masked]>
Date: Fri, 24 Aug 2018 12:50:32 -0400

> On Aug 24, 2018, at 9:54 AM, Ted Lemon <[email-masked]> wrote:
> 
> On Aug 24, 2018, at 9:52 AM, Tom Pusateri <[email-masked] <mailto:[email-masked]>> wrote:

Specifically, there are two applications mentioned in the draft.

1. When a DNS server receives a dynamic DNS Update from a client registering its name after having received an IP address from an DHCP lease, the length of the DHCP lease can be tied to the length that the DNS address/PTR records stay in the authoritative server.

2. When an RFC 6763 DNS-SD service is registered (including PTR, SRV, & TXT records), these records can timeout according to the lease lifetime contained in the update lease EDNS(0) option.

These are not theoretical. They solve practical problems that exist today. I think there are others associated with existing problems for sleeping devices and IoT devices that I need to research to more clearly answer your specific question but I think these two already fulfill that requirement.

Tom

---

From: Ted Lemon <[email-masked]>
Date: Fri, 24 Aug 2018 13:36:55 -0400

The DHCP case isn't actually a problem today.   DHCP servers automatically
remove these records.   The ISC server has been doing this for 20 years,
and I'm pretty sure all the other servers that compete with it do too.

On Fri, Aug 24, 2018 at 12:50 PM, Tom Pusateri <[email-masked]> wrote:

> Yes, it was intended to be more general than for service registration.
> It’s directly applicable to name registration for IP addresses. I can add a
> section on other uses if more motivation is desired. Mark Andrews had some
> uses as well that hopefully, he can share. If others have uses in mind that
> this solves I would love to hear about them.
>
>
> The reason I'm asking is not that I don't think there are theoretical use
> cases for what you are proposing.   I'm asking if there are actual use
> cases.   How would this be used in practice?   What can't someone do right
> now that they need to do and that this new technology enables?
>
>
> 1. When a DNS server receives a dynamic DNS Update from a client
> registering its name after having received an IP address from an DHCP
> lease, the length of the DHCP lease can be tied to the length that the DNS
> address/PTR records stay in the authoritative server.
>
> 2. When an RFC 6763 DNS-SD service is registered (including PTR, SRV, &
> TXT records), these records can timeout according to the lease lifetime
> contained in the update lease EDNS(0) option.
>
> These are not theoretical. They solve practical problems that exist today.
> I think there are others associated with existing problems for sleeping
> devices and IoT devices that I need to research to more clearly answer your
> specific question but I think these two already fulfill that requirement.
>
> Tom
>
>
>

---

From: Tom Pusateri <[email-masked]>
Date: Fri, 24 Aug 2018 13:56:11 -0400

Sure. It’s not the thoughtful, well-behaved implementations that we worry about. It’s the ones that aren’t. This is a protection mechanism. (Belt AND suspenders..)

Thanks,
Tom

> On Aug 24, 2018, at 1:36 PM, Ted Lemon <[email-masked]> wrote:
> 
> The DHCP case isn't actually a problem today.   DHCP servers automatically remove these records.   The ISC server has been doing this for 20 years, and I'm pretty sure all the other servers that compete with it do too.
> 
> On Fri, Aug 24, 2018 at 12:50 PM, Tom Pusateri <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>> On Aug 24, 2018, at 9:54 AM, Ted Lemon <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Ted Lemon <[email-masked]>
Date: Fri, 24 Aug 2018 14:04:26 -0400

Can you give us an example?

On Fri, Aug 24, 2018 at 1:56 PM Tom Pusateri <[email-masked]> wrote:

> Sure. It’s not the thoughtful, well-behaved implementations that we worry
> about. It’s the ones that aren’t. This is a protection mechanism. (Belt AND
> suspenders..)
>
> Thanks,
> Tom
>
>
>> These are not theoretical. They solve practical problems that exist
>> today. I think there are others associated with existing problems for
>> sleeping devices and IoT devices that I need to research to more clearly
>> answer your specific question but I think these two already fulfill that
>> requirement.
>>
>> Tom
>>
>>
>>

---

From: Tom Pusateri <[email-masked]>
Date: Fri, 24 Aug 2018 14:33:51 -0400

Sorry, I never surveyed the set of inconsiderate DCHP servers.

Thanks,
Tom

> On Aug 24, 2018, at 2:04 PM, Ted Lemon <[email-masked]> wrote:
>

---

From: Tom Pusateri <[email-masked]>
Date: Fri, 24 Aug 2018 14:43:00 -0400

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.

Thanks,
Tom

> On Aug 24, 2018, at 2:33 PM, Tom Pusateri <[email-masked]> wrote:
> 
> On Aug 24, 2018, at 2:04 PM, Ted Lemon <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> On Fri, Aug 24, 2018 at 1:56 PM Tom Pusateri <[email-masked] <mailto:[email-masked]>> wrote:
>>> On Aug 24, 2018, at 1:36 PM, Ted Lemon <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> [email-masked] <mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/dnsop <https://www.ietf.org/mailman/listinfo/dnsop>
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/dnsop <https://www.ietf.org/mailman/listinfo/dnsop>

---

From: Ted Lemon <[email-masked]>
Date: Fri, 24 Aug 2018 14:59:25 -0400

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

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.

---

From: Tom Pusateri <[email-masked]>
Date: Fri, 24 Aug 2018 15:02:50 -0400

> On Aug 24, 2018, at 2:59 PM, Ted Lemon <[email-masked]> wrote:
> 
> On Aug 24, 2018, at 2:43 PM, Tom Pusateri <[email-masked] <mailto:[email-masked]>> wrote:

Ok, great. Hopefully others have some use cases they can share. In the mean time, back to learning Rust…

Thanks,
Tom

---

From: Mark Andrews <[email-masked]>
Date: Sat, 25 Aug 2018 12:51:22 +1000

Registering slaac derived addresses in the DNS.  These are tied to prefix lifetimes. 

-- 
Mark Andrews

> On 25 Aug 2018, at 05:02, Tom Pusateri <[email-masked]> wrote:
> 
> 
>

---

From: Ted Lemon <[email-masked]>
Date: Fri, 24 Aug 2018 22:53:12 -0400

When would that happen?

On Fri, Aug 24, 2018 at 10:52 PM Mark Andrews <[email-masked]> 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.
>
>

---

From: Mark Andrews <[email-masked]>
Date: Sat, 25 Aug 2018 13:24:13 +1000

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 <[email-masked]> wrote:
> 
> When would that happen?
>

---

From: Tom Pusateri <[email-masked]>
Date: Fri, 24 Aug 2018 23:55:27 -0400

> On Aug 24, 2018, at 3:46 AM, Mark Andrews <[email-masked]> wrote:
> 

Ok, we will make them applicable to all classes.

>       deleted through DNS Update.

This restriction is another consequence of not being able to query TIMEOUT records. In order to allow UPDATE of TIMEOUT records, the client has to be able to retrieve the record and merge changes before UPDATING it. The server can’t do the merging or the record would change underneath the client that created it when another client added a record with the same owner name.

We haven’t been able to think of any significant downsides to allowing QUERY of TIMEOUT records and by doing so, it solves Joe’s issues so unless you can think of any, we’ll make that change in the next version and then be able to support UPDATE of TIMEOUT records.

> removed as well as generate and sign NSEC and NSEC3 records?

I would expect a secondary server to treat them the same as it does any other record type.

> Add matching TIMEOUT records added via UPDATE.

Ok.

Thanks!

Tom

---

From: Tom Pusateri <[email-masked]>
Date: Sat, 25 Aug 2018 00:18:08 -0400

Right, prefix delegation over DHCPv6 is a similar case that gets a prefix lifetime. I still use the WIDE dhcp6c client for PD and it has no means to update DNS. I haven’t found specific documentation from ISC DHCPv6 or KEA that describes creating DNS entries (PTR records) from delegated prefixes.

Tom

> On Aug 24, 2018, at 10:53 PM, Ted Lemon <[email-masked]> wrote:
> 
> When would that happen?
> 
> On Fri, Aug 24, 2018 at 10:52 PM Mark Andrews <[email-masked] <mailto:[email-masked]>> wrote:
> On 25 Aug 2018, at 05:02, Tom Pusateri <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> 
>> 
>>> On Aug 24, 2018, at 2:59 PM, Ted Lemon <[email-masked] <mailto:[email-masked]>> wrote:
>>>

---

From: Mark Andrews <[email-masked]>
Date: Sat, 25 Aug 2018 14:38:58 +1000

Named already has the ability to allow a machine within a /48 to insert/remove a
delegation at the /48 point using TCP to authenticate the update request.
I wrote the code to support this about the same time as Geoff Huston was looking
at setting up 6to4 reverse delegations.  He ended up going the HTTP to do it.
The code to do that works for any /48 for IPv6 connections.

https://tools.ietf.org/html/draft-andrews-dnsop-pd-reverse-02 is a fully fleshed
out example of how to do this but I couldn’t get even a request to adopt call 
from the DNSOP chairs when I presented it.  Can we stop leaving this in
limbo and move it forward?

Mark

> On 25 Aug 2018, at 2:18 pm, Tom Pusateri <[email-masked]> wrote:
>

---

From: Ted Lemon <[email-masked]>
Date: Sat, 25 Aug 2018 08:53:01 -0400

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

---

From: Mark Andrews <[email-masked]>
Date: Sun, 26 Aug 2018 00:30:29 +1000

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

---

From: Ted Lemon <[email-masked]>
Date: Sat, 25 Aug 2018 11:11:02 -0400

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

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

---

From: Paul Vixie <[email-masked]>
Date: Sat, 25 Aug 2018 17:57:17 +0000

> I'm not saying nobody does it.   I'm trying to understand how this helps.

in my own experience, nothing which needs a hostname (so, having an AAAA and 
PTR RR) doesn't have a static address. if an address is handed out by SLAAC or 
by DHCP, it initiates connections but does not respond to any. i realize that 
there are other modes of being, but that's mine.

furthermore i go to some length to de-automate PTR creation by ISP's. there 
are lists of auto-generated PTR base domains (d.c.b.a.in-addr.arpa pointing to 
host-a-b-c-d.isp.net) that i wish to treat as nonexistent for the purpose of 
choosing whether to receive high value connections (like to my SMTP server). 
it would be better for me if these automated PTR's did not work. no web server 
will ever reject PTR-less connections, so, outbound connections will mostly 
still work, just not for my SMTP server. i realize that there are other modes 
of being, but that's mine.

i have no objection to having other DHCP servers (not the ones i run) 
registering PTR's for its assignments. that's why i wrote DEFUPD in 1996. i 
just don't expect to use DEFUPD in my own servers. that's why DEFUPD solves a 
more general problem (asynchronous DNS updates in general, not just expiry.) 
that URL again for those historians who missed it:

-- 
Vixie

---

From: Tom Pusateri <[email-masked]>
Date: Sat, 25 Aug 2018 14:11:48 -0400

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 <[email-masked]> 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 <[email-masked] <mailto:[email-masked]>> wrote:
> On 25 Aug 2018, at 22:53, Ted Lemon <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> On Fri, Aug 24, 2018 at 11:24 PM Mark Andrews <[email-masked] <mailto:[email-masked]>> wrote:
>> On 25 Aug 2018, at 12:53, Ted Lemon <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>> When would that happen?
>>>

---

From: Ted Lemon <[email-masked]>
Date: Sat, 25 Aug 2018 14:13:43 -0400

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

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

---

From: Paul Vixie <[email-masked]>
Date: Sat, 25 Aug 2018 18:53:17 +0000

> better if the secondary would also have that information.

you seem to be proposing that the "secondary" servers, by which i mean those 
not the primary master, alter the zone contents in a way that's visible to 
query initiators, independently. if so, i oppose this, in the form proposed.

to have more than one source of DNS truth requires "multi-master", so that 
zone identity can be partitioned and healed, following partitions and healings 
of the connectivity of each responder and its cloud of reachable clients. one 
of the hard problems here is split horizon. another is incompatible deltas at 
heal time. the database world has grappled with this topic, having varying 
degrees of success, for as long as there have been computer networks.

i would like to see DNS add "multi-master". several proprietary vendor 
extensions do various parts of this -- though none of them that i know of can 
handle split horizon or incompatible deltas. and tellingly, none has been 
opened to the community in the form of a standardization effort.

if on the other hand you only intend to carry the timeout information as zone 
data transferred in AXFR/IXFR in case a sysop decides that the primary master 
will be offline indefinitely and wants to manually promote one of the 
"secondary" servers to the role of primary master, then i have no objection. 
that's why the TUU and TUD RR's of my 1996 "defupd" proposal are in-zone data 
rather than stored in some ancillary location reachable only by the primary 
master.

can you verify that you do not intend secondary servers to automatically 
expire records, independent of hearing IXFR/AXFR updates from the primary 
master, after the primary master applies its own copy of your TIMEOUT RR's?

-- 
Vixie

---

From: Tom Pusateri <[email-masked]>
Date: Sat, 25 Aug 2018 15:06:51 -0400

> On Aug 25, 2018, at 2:53 PM, Paul Vixie <[email-masked]> wrote:
> 

I agree that the secondary servers should not expire records. In the case of promotion, I also agree that this sounds like a good strategy.

Thanks for pointing out this distinction.

Tom

---

From: Tom Pusateri <[email-masked]>
Date: Sat, 25 Aug 2018 15:09:14 -0400

I think I already agreed with you here.

My main point was that the primary needs a database and it already has one and probably doesn’t want another one. Because of the added benefit that Paul points out with promoting a secondary to primary after an extended outage, and the points that Joe makes about treating all records the same, it seems logical to store the lease lifetime information as actual resource records and transfer them to the secondary.

Thanks,
Tom

> On Aug 25, 2018, at 2:13 PM, Ted Lemon <[email-masked]> wrote:
> 
> 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 <[email-masked] <mailto:[email-masked]>> wrote:
>> On Aug 25, 2018, at 11:11 AM, Ted Lemon <[email-masked] <mailto:[email-masked]>> 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.
>> 
>>>>> https://www.ietf.org/mailman/listinfo/dnsop <https://www.ietf..org/mailman/listinfo/dnsop>
>

---

From: "John Levine" <[email-masked]>
Date: 25 Aug 2018 21:20:03 -0400

>there are other modes of being, but that's mine.

The existence of services like dyndns suggests that there is some
interest in assigning hostnames to dynamic IPs, but their lack of use
outside the hobby geek world also suggests that it doesn't matter.
They don't do PTRs.

I also know people who keep lists of regex'es to match generic rDNS
for uses similar to yours.  Generic rDNS isn't worth much.

---

From: Ted Lemon <[email-masked]>
Date: Sun, 26 Aug 2018 12:58:48 -0400

On Sat, Aug 25, 2018 at 3:09 PM Tom Pusateri <[email-masked]> wrote:

> My main point was that the primary needs a database and it already has one
> and probably doesn’t want another one. Because of the added benefit that
> Paul points out with promoting a secondary to primary after an extended
> outage, and the points that Joe makes about treating all records the same,
> it seems logical to store the lease lifetime information as actual resource
> records and transfer them to the secondary.
>
> FWIW, I think the database storage argument is actually the best argument
for this proposal: we need a way to represent  the data structure on disk,
and what we know how to store are RRs.
That said, I think that it's worth asking the question of what the right
format is, and not just assuming that it's a hash.  Why, for example, is a
hash better than just a copy of the data (when it's in flight)?   Suppose
that I store it in memory as just a timeout on the RR: in that case, what's
the easiest way for me to transfer the information?

---

From: Tom Pusateri <[email-masked]>
Date: Sun, 26 Aug 2018 13:47:43 -0400

> On Aug 26, 2018, at 12:58 PM, Ted Lemon <[email-masked]> wrote:
> 
> On Sat, Aug 25, 2018 at 3:09 PM Tom Pusateri <[email-masked] <mailto:[email-masked]>> wrote:
> FWIW, I think the database storage argument is actually the best argument for this proposal: we need a way to represent  the data structure on disk, and what we know how to store are RRs.
> That said, I think that it's worth asking the question of what the right format is, and not just assuming that it's a hash.

Nice properties of the hash:

1. the length of the output value is consistent across varying input lengths of any RR type (128 bits in the case of the algorithm specified in the draft) making it easy to sequence through.
2. it’s independently verifiable between servers and across time on the same server
3. it’s independent of position of the RR it covers
4. it works the same for all existing RR’s as well as RR’s yet to be defined

Other methods may share some of these properties but I’m just listing all of the ones I can think of.

Thanks,
Tom

---

From: Tom Pusateri <[email-masked]>
Date: Sun, 26 Aug 2018 13:58:22 -0400

> On Aug 26, 2018, at 1:47 PM, Tom Pusateri <[email-masked]> wrote:
> 
> 
> 
>> On Aug 26, 2018, at 12:58 PM, Ted Lemon <[email-masked] <mailto:[email-masked]>> wrote:
>> 

Also, remember the hash is only needed if there are multiple records types with the same owner name / class having different timeouts (including no timeout).

So in the case of a unique name being added for a delegated address, the NO HASH value can be used and no hash needs to be calculated. In the case of both an IPv4 and IPv6 address being delegated and subsequently sending an UPDATE with the same owner name, as long as the lease time is the same, again, there is no need for the hash.

If, however, an RRSIG is dynamically generated for the owner name, then the hash will be needed. (You won’t want to timeout RRSIGs but instead timeout the A/AAAA and then recalculate the RRSIG/NSEC/NSEC3/NSEC5 records.)

Tom

---

From: Ted Lemon <[email-masked]>
Date: Sun, 26 Aug 2018 15:42:15 -0400

You haven't specified how the hash is done, so I can't confirm the truth of
your assertion that it's straightforward. :)

The "only if there are multiple record types" bit doesn't actually help,
because I can't actually think of a case where it doesn't apply.   That is,
every RR will require a hash, as far as I can tell, in practice.

128 bits is 16 bytes—the size of an IPv6 address.   It's probably true that
that's shorter than the record in most cases, but I doubt it's enough
shorter to make a difference.   And we already know how to compare
records—we need that for update.

On Sun, Aug 26, 2018 at 1:58 PM Tom Pusateri <[email-masked]> wrote:

>> My main point was that the primary needs a database and it already has
>> one and probably doesn’t want another one. Because of the added benefit
>> that Paul points out with promoting a secondary to primary after an
>> extended outage, and the points that Joe makes about treating all records
>> the same, it seems logical to store the lease lifetime information as
>> actual resource records and transfer them to the secondary.
>>
> format is, and not just assuming that it's a hash.
>
>
> 1. the length of the output value is consistent across varying input
> lengths of any RR type (128 bits in the case of the algorithm specified in
> the draft) making it easy to sequence through.
> Also, remember the hash is only needed if there are multiple records types
> with the same owner name / class having different timeouts (including no
> timeout).
>
> So in the case of a unique name being added for a delegated address, the
> NO HASH value can be used and no hash needs to be calculated. In the case
> of both an IPv4 and IPv6 address being delegated and subsequently sending
> an UPDATE with the same owner name, as long as the lease time is the same,
> again, there is no need for the hash.
>
> If, however, an RRSIG is dynamically generated for the owner name, then
> the hash will be needed. (You won’t want to timeout RRSIGs but instead
> timeout the A/AAAA and then recalculate the RRSIG/NSEC/NSEC3/NSEC5 records.)
>
> Tom
>
>
>

---

From: Ted Lemon <[email-masked]>
Date: Sun, 26 Aug 2018 15:43:26 -0400

BTW, another way to address this in terms of storage (which wouldn't help
with zone transfers) would be to simply extend the zone format to allow a
way to specify a timeout per RR.

On Sun, Aug 26, 2018 at 3:42 PM Ted Lemon <[email-masked]> wrote:

> You haven't specified how the hash is done, so I can't confirm the truth
> of your assertion that it's straightforward. :)
>
> 128 bits is 16 bytes—the size of an IPv6 address.   It's probably true
> that that's shorter than the record in most cases, but I doubt it's enough
>>> FWIW, I think the database storage argument is actually the best
>> argument for this proposal: we need a way to represent  the data structure
>> on disk, and what we know how to store are RRs.
>> Also, remember the hash is only needed if there are multiple records
>> types with the same owner name / class having different timeouts (including
>> no timeout).
>>

---

From: Paul Vixie <[email-masked]>
Date: Sun, 26 Aug 2018 19:59:39 +0000

On Sunday, August 26, 2018 5:47:43 PM UTC Tom Pusateri wrote:
> 1. the length of the output value is consistent across varying input lengths
> of any RR type (128 bits in the case of the algorithm specified in the
> draft) making it easy to sequence through. 2. it’s independently verifiable
> between servers and across time on the same server 3. it’s independent of
> position of the RR it covers 

as i wrote about a hash that was proposed in part of zone catalog work, there 
are two things that are really bad about these. 

1. the resulting design is not collision-resilient

2. the hash will have to change some day, invoking rollover complexity cost

while DHT is a better example of "use a hash because it's magic and makes it 
look like our coherency problems have gone away", in fact all non-security-
related hash uses should be suspected of the same. you won't want to use a 
hash in a distributed system (where hash values have to be portable) unless 
every alternative has a vastly higher cost.

-- 
Vixie

---

From: Tom Pusateri <[email-masked]>
Date: Sun, 26 Aug 2018 17:42:50 -0400

I actually think the hash won’t be needed as much as you think. If the timeout is the same, even though the record types are different, you still don’t need the hash.

Is this straightforward?

//
//  main.c
//  requires OpenSSL 1.1.1 or later
//
//  Created by Tom Pusateri on 8/26/18.
//  Copyright © 2018 !j.
//
//  MIT LICENSE as specified here: https://opensource.org/licenses/MIT
//

#include <stdio.h>
#include <string.h>
#include <openssl/evp.h>

int main(int argc, const char * argv[]) {
    EVP_MD_CTX *mdctx;
    const EVP_MD *md;
    char msg[] = "This is a test";
    unsigned char md_value[EVP_MAX_MD_SIZE];
    u_int md_len, i;
    
    md = EVP_shake128();
    if (md == NULL) {
        printf("Unknown message digest %s\n", argv[1]);
        exit(1);
    }
    
    mdctx = EVP_MD_CTX_new();
    EVP_DigestInit_ex(mdctx, md, NULL);
    EVP_DigestUpdate(mdctx, msg, strlen(msg));
    EVP_DigestFinal_ex(mdctx, md_value, &md_len);
    EVP_MD_CTX_free(mdctx);
    
    printf("Digest is: ");
    for (i = 0; i < md_len; i++)
        printf("%02x", md_value[i]);
    printf("\n");
    
    exit(0);
}

> On Aug 26, 2018, at 3:42 PM, Ted Lemon <[email-masked]> wrote:
> 
> You haven't specified how the hash is done, so I can't confirm the truth of your assertion that it's straightforward. :)
> 
> The "only if there are multiple record types" bit doesn't actually help, because I can't actually think of a case where it doesn't apply.   That is, every RR will require a hash, as far as I can tell, in practice.
> 
> 128 bits is 16 bytes—the size of an IPv6 address.   It's probably true that that's shorter than the record in most cases, but I doubt it's enough shorter to make a difference.   And we already know how to compare records—we need that for update.
> 
> On Sun, Aug 26, 2018 at 1:58 PM Tom Pusateri <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>> On Aug 26, 2018, at 1:47 PM, Tom Pusateri <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>>

---

From: Tom Pusateri <[email-masked]>
Date: Sun, 26 Aug 2018 17:53:20 -0400

> On Aug 26, 2018, at 3:59 PM, Paul Vixie <[email-masked]> wrote:
> 

SHAKE128 as well as other SHA-3 algorithms have been found to be quite collision resistant.

Tom

---

From: Paul Vixie <[email-masked]>
Date: Sun, 26 Aug 2018 15:54:53 -0700

Tom Pusateri wrote:
...
> SHAKE128 as well as other SHA-3 algorithms have been found to be
> quitecollision resistant.

right. they all are, at first. we're building for our grandkids though.

-- 
P Vixie

---

From: Tom Pusateri <[email-masked]>
Date: Sun, 26 Aug 2018 19:03:23 -0400

> On Aug 26, 2018, at 6:54 PM, Paul Vixie <[email-masked]> wrote:
> 
> 
> 
> Tom Pusateri wrote:
> ...

There’s no attack vector here. And a collision would have to be another valid RR already in the database with the same owner name and class. This is literally impossible. Probably not even with md5!

Tom

---

From: Paul Vixie <[email-masked]>
Date: Sun, 26 Aug 2018 16:07:51 -0700

Tom Pusateri wrote:
>
> There’s no attack vector here. And a collision would have to be
> another valid RR already in the database with the same owner name and
> class. This is literally impossible. Probably not even with md5!

as i wrote when the discussion of catalog zone hashing got to this 
point, "if collisions are impossible even with md5, then please use md5, 
and include a security considerations paragraph or two as to how this is 
not a problem. for that matter, if md4 or md3 will work, use those. 
unnec'y hash complexity is a form of security theater."

-- 
P Vixie

---

From: Tom Pusateri <[email-masked]>
Date: Sun, 26 Aug 2018 19:31:20 -0400

> On Aug 26, 2018, at 7:07 PM, Paul Vixie <[email-masked]> wrote:
> 
> Tom Pusateri wrote:
>> 
> as i wrote when the discussion of catalog zone hashing got to this point, "if collisions are impossible even with md5, then please use md5, and include a security considerations paragraph or two as to how this is not a problem. for that matter, if md4 or md3 will work, use those. unnec'y hash complexity is a form of security theater."
> 
> -- 
> P Vixie

You may be ok with that but no one from the security area will be. That’s just a fact of the times. The code in OpenSSL is identical no matter which hash you pick except for the hash name so it’s no more complex to implement. 

My approach was to pick the best hash available with a small output length.

Thanks,
Tom

---

From: Ted Lemon <[email-masked]>
Date: Sun, 26 Aug 2018 20:12:45 -0400

The timeout *isn't* the same for DNSSD Registration Protocol.

On Sun, Aug 26, 2018 at 5:42 PM Tom Pusateri <[email-masked]> wrote:

> I actually think the hash won’t be needed as much as you think. If the
> timeout is the same, even though the record types are different, you still
> don’t need the hash.
>
> Is this straightforward?
>
> //
> //  main.c

---

From: Tom Pusateri <[email-masked]>
Date: Sun, 26 Aug 2018 22:22:23 -0400

> On Aug 26, 2018, at 8:12 PM, Ted Lemon <[email-masked]> wrote:
> 
> The timeout isn't the same for DNSSD Registration Protocol.

Ok, this is a little detailed but let's take what the current draft says and be explicit about your particular SRP case. I think I am representing SRP correctly but if not, please correct me.

<srp>
[1. One thing that’s not clear about SRP is if the same host registers more than one service, does your particular form of UPDATE (which isn’t standard UPDATE) have to contain the same A and/or AAAA records in both registrations and if so, what is the server to do about different lifetimes?]
[2. Also, does SRP recommend including PTR records for name registrations of A & AAAA names? It doesn’t appear to but should it?]
[3. I think you’re going to run into trouble having non-standard UPDATE rules.]
(These are separate discussions about SRP for another forum and if you want to follow up on these, we should follow up on the dns-sd list.)
</srp>

At the end, I’ll do the more simple case of just A & AAAA records.

Let’s assume 3 clients, all with the same service type (different service types will have different owner names). We will use _ipp._tcp.example.com as an example.

Client A sends a registration at time Ta with lease life L1a for PTR, SRV, A, AAAA, TXT records, lease life L2a for KEY record.
Client B sends a registration at time Tb with lease life L1b for PTR, SRV, A, TXT records (no AAAA), lease life L2b for KEY record.
Client C sends two different instances of the same service (different instance names) at time Tc with lease life L1c for PTR, SRV, A, AAAA, TXT records, lease life L2c for KEY record.

Client A’s UPDATE contains:

_ipp._tcp.example.com PTR p1._ipp._tcp.example.com
p1._ipp._tcp.example.com SRV 0 0 631 p1.example.com
p1._ipp._tcp.example.com TXT paper=A4
p1.example.com  A  192.0.2.1
p1.example.com  AAAA  2001:db8::1
p1.example.com  KEY “key material here"

Client B's UPDATE contains:

_ipp._tcp.example.com PTR p2._ipp._tcp.example.com
p2._ipp._tcp.example.com SRV 0 0 631 p2.example.com
p2._ipp._tcp.example.com TXT paper=A4
p2.example.com  A  192.0.2.2
p2.example.com  KEY “key material here”
2.2.0.192.in-addr.arpa.                       PTR   p2.example.com.
2.0.0.0.0.0.0.0.0.0.0.0.b8.0d.01.20.ip6.arpa. PTR   p2.example.com. (using bytes instead of nibbles for compactness)

Client C's UPDATE contains two services at the same time with the same lease lifes:

_ipp._tcp.example.com PTR p3._ipp._tcp.example.com
p3._ipp._tcp.example.com SRV 0 0 631 p3.example.com
p3._ipp._tcp.example.com TXT paper=A4
p3.example.com  A  192.0.2.3
p3.example.com  AAAA  2001:db8::3
p3.example.com  KEY “key material here”

_ipp._tcp.example.com PTR p4._ipp._tcp.example.com
p4._ipp._tcp.example.com SRV 0 0 631 p4.example.com
p4._ipp._tcp.example.com TXT paper=A4
p4.example.com  A  192.0.2.4
p4.example.com  AAAA  2001:db8::4
p4.example.com  KEY “key material here”

The TIMEOUT records on the server would look like the following:
(owner_name TIMEOUT count algorithm expire hash_list, count algorithm expire hash_list, etc.)

_ipp.tcp.example.com TIMEOUT 1 1 Ta+L1a (#hash for p1._ipp._tcp.example.com PTR record)
                             1 1 Tb+L1b (#hash for p2._ipp._tcp.example.com PTR record)
                             2 1 Tc+L1c (#hash for p3._ipp._tcp.example.com PTR record) (#hash for p4._ipp._tcp.example.com PTR record)

p1._ipp._tcp.example.com TIMEOUT 0 0 Ta+L1a

p2._ipp._tcp.example.com TIMEOUT 0 0 Tb+L1b

p3._ipp._tcp.example.com TIMEOUT 0 0 Tc+L1c

p4._ipp._tcp.example.com TIMEOUT 0 0 Tc+L1c

p1.example.com  TIMEOUT  2 1 Ta+L1a (#hash for 192.0.2.1 A record) (#hash for 2001:db8::1 AAAA record)
                         1 1 Ta+L2a (#hash for p1.example.com KEY record)

p2.example.com  TIMEOUT  1 1 Tb+L1b (#hash for 192.0.2.2 A record)
                         1 1 Tb+L2b (#hash for p2.example.com KEY record)

p3.example.com  TIMEOUT  2 1 Tc+L1c (#hash for 192.0.2.3 A record) (#hash for 2001:db8::3 AAAA record)
                         1 1 Tc+L2c (#hash for p3.example.com KEY record)

p4.example.com  TIMEOUT  2 1 Tc+L1c (#hash for 192.0.2.4 A record) (#hash for 2001:db8::4 AAAA record)
                         1 1 Tc+L2c (#hash for p4.example.com KEY record)

2.2.0.192.in-addr.arpa.                       TIMEOUT 0 0 Tb+L1b
2.0.0.0.0.0.0.0.0.0.0.0.b8.0d.01.20.ip6.arpa. TIMEOUT 0 0 Tb+L1b (using bytes instead of nibbles for compactness)

So, in general, for any one service registration without PTR records for addresses, you will create:
3 TIMEOUT records, 2 with a hash and 1 without a hash

or with PTR records for names included, you will create:
5 TIMEOUT records, 2 with a hash and 3 without a hash.

For the simpler case, a host sending a name registration at time Tn for A & AAAA records with lease lifetime Ln would have an UPDATE that contains:

name_n.example.com                            A     192.0.2.5
name_n.example.com                            AAAA  2001:db8::5
5.2.0.192.in-addr.arpa.                       PTR   name_n.example.com.
5.0.0.0.0.0.0.0.0.0.0.0.b8.0d.01.20.ip6.arpa. PTR   name_n.example.com. (using bytes instead of nibbles for compactness)

None of the 3 TIMEOUT records on the server would contain a hash:

name_n.example.com                            TIMEOUT 0 0 Tn+Ln
5.2.0.192.in-addr.arpa.                       TIMEOUT 0 0 Tn+Ln
5.0.0.0.0.0.0.0.0.0.0.0.b8.0d.01.20.ip6.arpa. TIMEOUT 0 0 Tn+Ln (using bytes instead of nibbles for compactness)

Hope this makes things more clear.

Tom

---

From: Tom Pusateri <[email-masked]>
Date: Sun, 26 Aug 2018 22:39:02 -0400

By the way, the SRP case looks messy because SRP chooses to have different lease lifetimes for KEY records. If the lease lifetimes were all the same, as I would expect for most UPDATES, everything would be simpler.

Tom

> On Aug 26, 2018, at 10:22 PM, Tom Pusateri <[email-masked]> wrote:
> 
>

---

From: Ted Lemon <[email-masked]>
Date: Sun, 26 Aug 2018 22:48:03 -0400

SRP has to work.   We updated the DNS update lease spec to account for the different lease times; there may be further work to do there.   But the lease on the name and service instance name KEY records has to be able to be different than the lease on the other data—we want that data to expire quickly, but for the KEY to stick around for a while so that the name can't be claimed by a rogue service just because e.g. the printer is powered off right now.

---

From: Mark Andrews <[email-masked]>
Date: Mon, 27 Aug 2018 12:51:17 +1000

I would add a covered type field to TIMEOUT (c.f. RRSIG).  I also wouldn’t have more than
a single timeout per record.  I’m tempted to say a single hash as well.  If there is multiple
timeouts per record then the blocks need to be sorted in timeout order.

Covered is there to reduce the number of RR’s that need to be hashed to remove a record.
It will also reduce the size of IXFR’s as you don’t need to re-construct a new TIMEOUT
record that covers every timeout at a name on each change.

For all records at a name is often more expensive that for all records of type covered.
Name servers are optimised for looking up <name,type,class> tuples rather than <name,class>
tuples.

Sorting of timeout blocks is so that you can look at the first timeout when working out
which TIMEOUT needs to be processed first in a zone.

---

From: Ted Lemon <[email-masked]>
Date: Sun, 26 Aug 2018 23:20:30 -0400

If we do that, why do we need a hash at all?

On Sun, Aug 26, 2018 at 10:51 PM Mark Andrews <[email-masked]> wrote:

> <https://maps.google.com/?q=1+Seymour+St.,+Dundas+Valley,+NSW+2117,+Australia&entry=gmail&source=g>

---

From: Mark Andrews <[email-masked]>
Date: Mon, 27 Aug 2018 13:33:16 +1000

A hash is still better than copying the RDATA to the end of the timeout record and
avoids protocol RR size limit issues.

You still have to handle multiple TIMEOUT RRs at the same name to cope with a TIMEOUT
records that would exceed 64K, the limit of what can passed in a single RR in a AXFR.
As these are never returned in a answer you don’t have to cope with the RRset exceeding
64k at the protocol level but a implementation might.

e.g. 4000 A records at a single name (~64k RRset) with individual timeouts would have a
TIMEOUT RRset much greater than 64k.

Mark

> On 27 Aug 2018, at 1:20 pm, Ted Lemon <[email-masked]> wrote:
>

---

From: Tom Pusateri <[email-masked]>
Date: Mon, 27 Aug 2018 14:12:49 -0400

I’m not sure I understand your comment.

I believe I just showed you how SRP does work in the existing draft. If I’ve somehow mis-understood how SRP works, please let me know.

Tom

> On Aug 26, 2018, at 10:48 PM, Ted Lemon <[email-masked]> wrote:
>

---

From: Tom Pusateri <[email-masked]>
Date: Mon, 27 Aug 2018 14:25:55 -0400

> On Aug 26, 2018, at 10:51 PM, Mark Andrews <[email-masked]> wrote:
> 

We didn’t anticipate multiple lifetimes per record (although the current draft doesn’t prevent this). Things get tricky with multiple lifetimes on a record because if you keep the most future date only and then that record disappears, you may need to restore a less future date but if you didn’t keep it, you can’t. So keeping all the lifetimes is the only way to ensure you handle changes correctly.

Sorting the timeouts is a good idea.

Adding TYPE would increase the number of blocks but reduce the number of hashes needed. This might simplify SRP complexity. Some analysis is required to determine if this is a net benefit.

Thanks,
Tom

---

From: Tom Pusateri <[email-masked]>
Date: Mon, 27 Aug 2018 14:28:41 -0400

Because even if you add TYPE, you have multiple PTR records (instance names) with the same owner name, class, and type that can timeout differently.

Tom

> On Aug 26, 2018, at 11:20 PM, Ted Lemon <[email-masked]> wrote:
> 
> On Sun, Aug 26, 2018 at 10:51 PM Mark Andrews <[email-masked] <mailto:[email-masked]>> wrote:
> 1 Seymour St., Dundas Valley, NSW 2117, Australia <https://maps.google.com/?q=1+Seymour+St.,+Dundas+Valley,+NSW+2117,+Australia&entry=gmail&source=g>
> PHONE: +61 2 9871 4742              INTERNET: [email-masked] <mailto:[email-masked]>
>

---

From: Tom Pusateri <[email-masked]>
Date: Mon, 27 Aug 2018 14:31:53 -0400

> On Aug 27, 2018, at 2:25 PM, Tom Pusateri <[email-masked]> wrote:
> 
> 

Well, maybe sorting timeouts is a good idea. Depending on how they are represented internally, it makes no difference. I would like to hear from implementors whether this even matters.

Thanks,
Tom

---

From: Ted Lemon <[email-masked]>
Date: Mon, 27 Aug 2018 15:27:25 -0400

For service instance names, there is only one service. So there shouldn’t
be a problem.

On Mon, Aug 27, 2018 at 2:28 PM Tom Pusateri <[email-masked]> wrote:

> Because even if you add TYPE, you have multiple PTR records (instance
> names) with the same owner name, class, and type that can timeout
> differently.
>
> Tom
>

---

From: Tom Pusateri <[email-masked]>
Date: Mon, 27 Aug 2018 15:34:22 -0400

Not true. You have PTR records with the same service name from multiple clients each with different RDATA and unique timeouts as I demonstrated yesterday in the example.

Tom

> On Aug 27, 2018, at 3:27 PM, Ted Lemon <[email-masked]> wrote:
> 
> For service instance names, there is only one service. So there shouldn’t be a problem. 
> 
> On Mon, Aug 27, 2018 at 2:28 PM Tom Pusateri <[email-masked] <mailto:[email-masked]>> wrote:
>> On Aug 26, 2018, at 11:20 PM, Ted Lemon <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Ted Lemon <[email-masked]>
Date: Mon, 27 Aug 2018 18:34:05 -0400

Sorry, I realized that I accidentally hit "reply" instead of "reply all."

The issue that I raised with Tom is that for the DNSSD SRP use case, the only names that receive updates from multiple services are service names (IOW, not service instance names).   In the case of SRP, PTR RRs in service names always point to service instance names, which are per-service, and hence can be counted on to expire on a single schedule.   So for the use case of SRP, the easiest way to handle deleting service name PTR RRs is to take advantage of the semantics of DNSSD: when a service instance SRV record expires, also delete the PTR RR on the service name that points to it.

The reason I bring this up is that it's the most complicated use case I know of.   Is there some other use case where we expect more than one DNS Update client to be updating RRs of the same type on the same name?   How would this even work without SRP semantics?   If this is not expected, then any complexity in the timeout RR that's present only to support that use case is unnecessary.

This is what has been motivating my questions about use cases.   I'm sorry I didn't make that clear earlier.

> On Aug 27, 2018, at 3:34 PM, Tom Pusateri <[email-masked]> wrote:
> 
>> On Aug 27, 2018, at 3:27 PM, Ted Lemon <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Mark Andrews <[email-masked]>
Date: Tue, 28 Aug 2018 10:02:47 +1000

Active directory has each domain controller updating its own SRV record
on the same <qname,qtype,qclass> tuple.  These updates happen at different
times and need to expire if a domain controller becomes unreachable.

A different case is when you have multiple prefixes from different
providers with different lifetimes.  You then end up with multiple AAAA
records that need to expire at different times.

Mark

> On 28 Aug 2018, at 8:34 am, Ted Lemon <[email-masked]> wrote:
>

---

From: Ted Lemon <[email-masked]>
Date: Mon, 27 Aug 2018 20:04:29 -0400

How do they handle that?

On Mon, Aug 27, 2018 at 8:02 PM Mark Andrews <[email-masked]> wrote:

> > The issue that I raised with Tom is that for the DNSSD SRP use case, the
> only names that receive updates from multiple services are service names
> (IOW, not service instance names).   In the case of SRP, PTR RRs in service
> names always point to service instance names, which are per-service, and
> hence can be counted on to expire on a single schedule.   So for the use
> case of SRP, the easiest way to handle deleting service name PTR RRs is to
> take advantage of the semantics of DNSSD: when a service instance SRV
> record expires, also delete the PTR RR on the service name that points to
> it.
> >
> > The reason I bring this up is that it's the most complicated use case I
> know of.   Is there some other use case where we expect more than one DNS
> Update client to be updating RRs of the same type on the same name?   How
> would this even work without SRP semantics?   If this is not expected, then
> any complexity in the timeout RR that's present only to support that use
> case is unnecessary.
> >

---

From: Mark Andrews <[email-masked]>
Date: Tue, 28 Aug 2018 11:05:04 +1000

MS does something in the LDAP backend. It does however show that there is
a need for the functionality.

> On 28 Aug 2018, at 10:04 am, Ted Lemon <[email-masked]> wrote:
> 
> How do they handle that?
>

---

From: Mark Andrews <[email-masked]>
Date: Wed, 29 Aug 2018 18:44:52 +1000

Expiry Time:  Internet Date/Time Format from [RFC3339] Section 5.6
              profile of ISO 8601

Please don’t add yet another time format that it way too generic.
See RRSIG for how to present the time.  Name servers already have
code to parse this.

e.g.
YYYYMMDDHHMMSS in seconds since Jan 1, 1970 UTC ignoring leap seconds.

Also the field doesn’t need to be 64 bits.  32 would be fine.  We
really don’t need to support garbage collection +68 years in the
future.  You can just reference the RRSIG which uses 32 bit time
stamps.  Name servers do serial number arithmetic.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 29 Aug 2018 19:21:08 +1000

The record is not self describing for converting from wire to
presentation.  It requires knowledge of the size of the hash
which is algorithm dependent and not specified in the record.