[regext] AD Evaluation: draft-ietf-regext-epp-ttl-14

[Orie Steele <[e-mail]>]

# Orie Steele, ART AD, comments for draft-ietf-regext-epp-ttl-14
CC @OR13

https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-regext-epp-ttl-14.txt&submitcheck=True

Thanks to Anthony Somerset for the DNSDir early review.
Thanks to Andy Newton for the shepherd writeup.
Thanks to Gavin and the working group for this document.

As you read my comments, please keep in mind that I am not a DNS expert.

## Comments

I found the document easy to read, and most of my comments are minor.
I do have a concern regarding the choice of enabling 2 modes "Default" and
"Policy".
Especially after reading SAC-025, I wonder why the "Default" mode is
offered to implementations.
If it is possible to make Policy Mode the only option, it seems like that
might improve the ability to surface and address the security issues
associated with short and long lived TTLs.

### Recommended default TTL?

```
204   4.  "default", which MUST NOT be present in command frames but MAY be
205       present in response frames (see Section 2.1.1), and which is used
206       by the server to indicate the default value;
```

```
224   2.  empty, in which case the server's default TTL for the given
225       record type is to be applied.
```

Is there a recommended default TTL when EPP is used?

See security considerations for why this might be a good idea.

### DELEG as example

```
298   <ttl:ttl
299     for="custom"
300     custom="DELEG">3600<ttl:ttl>
```

Consider a record that is already registered with IANA, TLSA for example.

### Are 2 modes really needed?

```
308   It has a single OPTIONAL policy attribute, which takes a boolean
309   value with a default value of false.
```

Should this be interpreted as Default Mode is mandatory to support and
Policy Mode is optional?

### Examples for Section 2.2.1 and 2.2.2

Examples in Section 2.2.1 and 2.2.2 both only include the Default Mode.

Is Policy Mode supported by `<create>` and `<update>` ?

I assume the answer is yes, but explicit examples might make this clearer.

```
685   If an EPP server receives a <create> command containing a TTL value
686   that is outside the server's permitted range, it MUST reject the
687   command with a 2306 "Parameter value policy error" response.
```

```
745   If an EPP server receives an <update> command containing a TTL value
746   that is outside the server's permitted range, it MUST reject the
747   command with a 2306 "Parameter value policy error" response.
```

Consider providing a complete response for these rejected commands.

### Servers MAY have policies?

```
753   Servers MAY restrict the supported DNS record types in accordance
754   with their own policy.  For example, a server MAY allow clients to
755   specify TTL values for DS records only.
```

Can this be strengthened to a SHOULD or MUST?

### Range and Record Type Errors

```
757   A server which receives a <create> or <update> command which includes
758   a restricted record type MUST respond with a 2306 "Parameter value
759   policy" error.
```

Is it correct to reply with 2306 for both out of range and restricted
record type errors?

### Servers can ignore clients?

```
767   EPP servers which implement this extension SHOULD use the values
768   provided by EPP clients for the TTL values records published in the
769   DNS for domain and (if supported) host objects.
```

This feels like a throwaway sentence, why not MUST?

When can this SHOULD be ignored?

### When can servers ignore the host attribute?

```
771   EPP servers that use the "host attribute" model SHOULD use any A and/
772   or AAAA TTL values specified for the domain object when publishing
773   NS, A and AAAA records derived from host attributes.
```

When can this SHOULD be ignored? Why not MUST?

###  Operational considerations

```
796   Historically, registry operators have used a global TTL value for all
797   delegations within their zones, which could then be tuned to an
798   optimum value.
```

Is this a recommendation? Can it be turned into one or removed?

```
800   Registry operators SHOULD implement limits on the maximum and minimum
801   accepted TTL values that are narrower than the values permitted in
802   the XML schema in the Formal syntax (which were chosen to allow any
803   TTL permitted in DNS records), in order to prevent scenarios where an
804   excessively high or low TTL causes operational issues on either side
805   of the zone cut.
```

This feels like it is in conflict with the Default Mode, which is mandatory
to support?

### Should ensure user understands

```
814   A common operational mistake is changing of DNS record TTLs during or
815   after the planned change to the records themselves.  This arises due
816   to a misunderstanding about how TTLs work.

818   Implementations of this specification SHOULD ensure that the user
819   understands that changes to a TTL are only effective in shortening
820   transition periods if implemented a period of time — at least equal
821   to the current TTL — _before_ the planned change.  The latency
822   between receipt of the <update> command and the actual publication of
823   the changes in the DNS should also be taken into consideration in
824   this calculation.
```

I think this could be rephrased to use BCP14 language in a more intuitive
way:

```
It is RECOMMENDED that guidance be provided to users so that they are aware
that ...
```

### fast flux DNS

```
828   Some malicious actors use a technique called "fast flux DNS"
829   ([SAC-025]) to rapidly change the DNS configuration for a zone in
830   order to evade takedown and law enforcement activity.

832   Registry operators should take this into consideration when setting
833   the lower limit on TTL values, since a short TTL on delegations may
834   enhance the effectiveness of fast flux techniques on evasion.
```

Consider shortening the first part to "in order to evade identification".

Please revise the second part to provide mitigation advice, based on the
reference:

```
Mitigations methods that are practiced today, but not uniformly, include:
• Authenticate contacts before permitting changes to name server
configurations.
• Implement measures to prevent automated (scripted) changes to name server
configurations.
• Set a minimum allowed TTL (e.g., 30 minutes) that is long enough to
thwart the
double flux element of fast flux hosting.
• Implement or expand abuse monitoring systems to report excessive DNS
configuration changes.
• Publish and enforce a Universal Terms of Service agreement that prohibits
the use
of a registered domain and hosting services (DNS, web, mail) to abet
illegal or
objectionable activities (as enumerated in the agreement).

....

• Rate-limit or (limit by number per hour/day/week) changes to name servers
associated with a registered domain name. Registries and registrars already
apply rate-limiting techniques on query-based WHOIS services to discourage
abuse. Determine a rate of change that (a) accommodates legitimate
applications
of short TTLs for NS records in TLD zone files, (b) provides investigators
with a
window of opportunity to track down the origin of updates and identify
bots, and
(c) makes short TTLs less useful to fast flux attackers.

• Separate "short TTL updates" from normal registration change processing.
Treat requests to set TTLs below a certain limit as special requests that
require
some form of verification.
```

Some of these are not directly related to TTL / EPP... some are.

### additional security considerations for ttl

Consider commenting on the impact of TTL on DDoS.
Consider commenting on the impact of TTL on DNS Spoofing.
Consider commenting on the impact of TTL on DNS Cache Poisoning.