Subject: [DNSOP] Request for Adoption (draft-moura-dnsop-authoritative-recommendations)

From: Giovane Moura <[email-masked]>
Date: Wed, 28 Nov 2018 09:55:58 +0000

Folks,

We have a new draft and we'd like to ask the WG to adopt it:

   *
https://datatracker.ietf.org/doc/draft-moura-dnsop-authoritative-recommendations/

This is an informational draft that presents recommendations for
authoritative DNS operators, based on research works we have been
conducting over the last few years.

We are using Github to edit this draft as well:

https://github.com/gmmoura/draft-moura-dnsop-authoritative-recommendations

Thanks,

/giovane

---

From: "StJohns, Michael" <[email-masked]>
Date: Wed, 28 Nov 2018 11:48:02 -0500

Hi -

Do you have any authoritative server operators that have signed on to these
recommendations other than the authors?  if not, I’d suggest deferring this
as a WG document pending some buy in from a few ops that are using these
recommendations and can provide some real world context.  E.g. how does
research translate to reality here?

Just a thought - Mike

On Wed, Nov 28, 2018 at 04:56 Giovane Moura <[email-masked]> wrote:

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Paul Ebersman <[email-masked]>
Date: Wed, 28 Nov 2018 12:25:22 -0700

moura> We have a new draft and we'd like to ask the WG to adopt it:
     
moura> [[https://datatracker..ietf.org/doc/draft-moura-dnsop-authoritative-recommendations/]]
     
msj> Do you have any authoritative server operators that have signed on
msj> to these recommendations other than the authors?

I'll be going through it. $DAYJOB includes gTLD, ccTLD and second level
domains (Neustar).

---

From: Töma Gavrichenkov <[email-masked]>
Date: Wed, 28 Nov 2018 22:59:01 +0300

Hello Giovane,

> conducting over the last few years.

Thank you for sharing this!

A few suggestions:

> 5. R4 [..]
>  -  It can withdraw or pre-prepend its route to some or to all of its
>      neighbors, shrinking its catchment (the number of clients that BGP
>      maps to it), shifting both legitimate and attack traffic to other
>      anycast sites.  The other sites will hopefully have greater
>      capacity and be able to service the queries.

Not necessarily so.
First, one can (may?) use BGP communities to limit the route
announcement propagation, thus making the distribution between sites
more even.
Second, Flowspec/DOTS/selective BH/et cetera.

> 6. R5 [..]

Shouldn't we wait before the faith of draft-ietf-dnsop-serve-stale is
determined? The outcome of this one may be then heavily influenced.

Anyway, it's not quite clear what this section suggests. Should I set
the TTL to 10s? What are the consequences of that? How's that related
to my threat model?

> 2: R1 [..]
(yes, out of order)

Well, *one* (and there may be more) of the reasons to maintain
authoritative servers with uneven latency distribution may be to have
a) some fast servers you can afford to get brought down by a DDoS
attack, b) a "lightning rod" — a purposefully degraded absorber,
mentioned in (5).

> 2: R1 [..]
> But the distribution of queries tend to be skewed towards authoritatives with lower

There's a reason for that that you may want to mention, namely, smoothed RTT.

| Töma Gavrichenkov
| gpg: 2deb 97b1 0a3c 151d b67f 1ee5 00e7 94bc 4d08 9191
| mailto: [email-masked]
| fb: ximaera
| telegram: xima_era
| skype: xima_era
| tel. no: +7 916 515 49 58

---

From: Joe Abley <[email-masked]>
Date: Wed, 28 Nov 2018 15:13:57 -0500

Hey Giovane,

> conducting over the last few years.

I have read this document. This is not a detailed review, just a more general reaction to the adoption question.

This document reads a bit like it wants to give operational advice but in fact it seems much more like a literature review that has been culturally adapted to an IETF audience. This is not intended to be a negative comment; I think the references and the context are useful and I think it's a great idea to find a way to push pointers to operational research into the RFC series, but I think it would be as well to make it clear that the operational advice contained within is not comprehensive and in many cases is quite superficial. I can give examples if you want more detail.

I also think that the document is not clear on what problem it is solving; in particular, it doesn't define "performance". It's inferred that the performance metric that matters is round-trip query latency for some nominal client at an average distance; what if the operator's priority is availability? That makes R1 potentially bad advice; no doubt there are other motivations that would also not fit the recommendations convincingly.

Much of the document is specifically concerned with the implementation of anycast strategies for DNS, not with authoritative DNS in particular. The advice would hold for any stateless (or short-duration transaction, where short is relative to routing stability). One direction the authors might consider taking this is to update the advice in RFC 4786 with reference to the repeatable experiments that you cite. Ironically 4786 was criticised for being a document about DNS that was pretending to be more general; perhaps when welded to your document the result would be more pleasantly neutral :-)

Joe

---

From: "John Levine" <[email-masked]>
Date: 28 Nov 2018 17:33:02 -0500

In article <[email-masked]> you write:
>-=-=-=-=-=-
>recommendations other than the authors?

I run authoritative servers for about 500 small domains, but I suspect
I am not the operator you are looking for.

Perhaps a next step would be to clarify what kind of server operators
this advice is intended for, or perhaps different parts of it are
intended for different kinds of operators.  I doubt I will ever use
anycast, but the advice on latency and TTL might be useful to my
smallish setup.

R's,
John

---

From: Giovane Moura <[email-masked]>
Date: Thu, 29 Nov 2018 08:48:22 +0000

> I am not the operator you are looking for.

First, thanks everybody for reviewing the draft, lots of valuable
feedback in these comments.

Now, the first thing we need to do (as pointed by multiple reviewers) is
to define which kind of operator we have in mind. This is not clear in
the document at this stage; however, what we thought was: large,
TLD-like DNS operators.  These are the ones who can afford large scale
anycast deployments. Smaller operators still can benefit from one or two
recommendations, but not all of them.

We'll take this into account  and work on a new version, also addressing
 the other reviewers' comments.

Thanks very much,
/giovane