pusateri / draft-pusateri-dnsop-update-timeout Goto Github PK

On Aug 24, 2018, at 3:46 AM, Mark Andrews [email protected] wrote:

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.

Via Mark Andrews, there is some more consideration needed for RDATA presentation format.

A analysis of relative vs. absolute expiry time needs to be done and a decision made.

Mark Andrews comments:

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.

If TIMEOUT RRs are treated like any other record (See #11) then they should be allowed to be added/removed via UPDATE. This is a little bit trickier because the timeout values have to be merged into one record. An UPDATE would require:

1. query for existing TIMEOUT record
2. take existing TIMEOUT and merge new info
3. submit UPDATE with prerequisite of existing record

(Feel free to edit this issue in order to extend/edit the table.)

Mark Andrews writes:

SHAKE128 does not meet these requirements. In OPENSSL it is only
available in pre-release code. It will be years before OPENSSL-1.1.1
is the OPENSSL release for most operating systems.

We (ISC) haven’t started working out what OPENSSL-1.1.1 breaks yet.
OPENSSL-1.1.0 broke lots of existing code. Lots of code required
re-writing to work with OPENSSL-1.1.0 as it broke backwards compatibility
with OPENSSL-1.0.x.

Please pick hash algorithms that are already USED by DNS. The results
can be truncated if you are worried about space.

In Resource Record Composition, the second to last paragraph doesn't fit with the more specific matching TIMEOUT record.

Comment from Stuart Cheshire @StuartCheshire:
One quick comment: On page 3, where you first mention, “PTR records for service discovery,” you should add a reference to RFC 6763. We shouldn’t assume that everyone is familiar with how that works.

We only define RDATA but if new methods are defined in the future like HASH, we should define how to handle it.

Ted Lemon @Abhayakara suggests the HASH is a premature optimization and that instead of a fixed length field to distinguish resource records, we should just include the full variable length RDATA.

2018-08-29 10:44 GMT+02:00 Mark Andrews [email protected]:

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.

Need to discuss case when NO METHOD records are to be removed in the presence of more specific RDATA TIMEOUT records.

The TTL isn't applicable since and should be set to 0 during a transfer.

Feedback from Joe Abley @ableyjoe:

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.

Tony Finch @fanf2 would like to see a different timestamp format.

Currently there is a 64-bit unix epoch timestamp in the TIMEOUT resource record. This is currently the recommended way to store timestamps and what is returned by gettimeofday() on all modern systems. However, this is not the customary way to store timestamps in the current DNS protocols which already have 4 different ways to represent time (RRSIG, SIG, TKEY, and TSIG).

One recommendation is to use a wrapping 32-bit timestamp as specified in [RFC4034] 3.1.5. Signature Expiration and Inception Fields

A third party could monitor TIMEOUT records and when expiry time occurs, delete the represented records as well as the TIMEOUT records if the authoritative doesn't know how to handle TIMEOUT resource records.

The current document mixes this terminology. Not sure which is better to use. DNS Update uses Master/Slave. Need to determine if there is a difference.

If there isn't an exact match to RDATA, matches could fall back to "no method, no count" TIMEOUT records. This would reduce the number of records if many expiry times are the same but some are different.

Paul Vixie comments:

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.

Also, Paul Vixie comments:

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.

If we add an option to specify that the chosen expiry time should be valid for all RRs under one owner, the RDATA hashing could be omitted in this case.

Choosing a Hash Algorithm Index and Hash Count of 0 might be a good fit for this behaviour?

Tony Finch @fanf2 paraphrased:
Does it (cleanup) need to be per-record? Why not GC the whole RRset?

Mark Andrews:
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.

The primary should expire the records and NOTIFY the secondaries to pull down a new version of the database.

Section 4.5 discusses names in RDATA should be uncompressed before hashing. Mark Andrews (ISC) suggests the following language instead: "The record MUST be in canonical DNSSEC form ([RFC4034] Section 6)."

In the current draft version of the draft (339ceed), there are multiple hash lists in one TIMEOUT RR, each associating RRs with an expiry time.

If we would have only one expiry time per RR and would suggest using multiple RRs instead (similar to MX RRs), deleting/updating the expiry time would be more easy, because this would just mean deleting the RR.

When an external source adds records via UPDATE, it could add the corresponding TIMEOUT records at the same time to communicate the lifetimes and not require the authoritative to create them. If the authoritative server supports TIMEOUT, it would then remove all the records at the appropriate time. If it doesn't a third party could remove them via UPDATE.

Mark Andrews comments:

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.

I'm not sure if I see a case where multiple/different hash algorithms would be used within the same TIMEOUT RR.

@pusateri Do you had a specific use case in mind?

This came to my mind in context of #11 (and #8).
I think the answer is no.
The TTL of a TIMEOUT RR should not matter, because there’s no reason for clients to query this RR and the server itself also doesn’t need to use it in any way.

Spelling out when a hash is needed and when it isn't was a useful exercise on the DNSOP mailing list. Putting some examples in the draft would clarify this for the reader.

We might end up with RRs being present in multiple instances, potentially with different expiry times and hash values.

I suggest to mention at least that if an expiry time is reached an no RR matching a given hash value is present, the server should just continue with the next hash value.

Additionally we might want to specify a server behavior to avoid this situation by performing checks upon receiving a message resulting in an TIMEOUT RR (even though the source of the message is out of scope of the draft).

If you agree, I will add some text.