Subject: Re: [DNSOP] Wrapping up draft-ietf-dnsop-dns-tcp-requirements

From: Petr Špaček <[email-masked]>
Date: Mon, 1 Jul 2019 14:42:46 +0200

Hello,

it is a good read.

I would only add reference to
https://datatracker.ietf.org/doc/draft-ietf-intarea-frag-fragile/
+ DNS Flag Day 2020, which is going to effectivelly kill UDP
fragmentation in DNS and thus require TCP for perfect operation.

Maybe we could add something along these lines around end of section-2.4:

Problems caused by IP fragmentation are described at length in document
https://tools.ietf.org/html/draft-ietf-intarea-frag-fragile .
One of possible approaches to workaround this problem is lowering EDNS
buffer size to values which do not cause IP fragmentation. In fact, such
coordinated change is planned for year 2020 [http://dnsflagday.net/2020/].

Petr Špaček  @  CZ.NIC

On 25. 06. 19 17:10, John Kristoff wrote:
> Friends,
> 
> Duane and I pushed out a recent update to this draft.  There are at
> least a couple of small TODO items we have to address (search text
> for TODO) before it can be published, but I think we've exhausted
> largely what we set out to do for this document and would like to see
> this wrapped up.
> 
> If you could give it perusal and provide and alert us to anything
> needing attention that would be lovely.  Thank you,
> 
>   <https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-tcp-requirements/>
> 
>    This document encourages the practice of permitting DNS messages to
>    be carried over TCP on the Internet.  It also considers the
>    consequences with this form of DNS communication and the potential
>    operational issues that can arise when this best common practice is
>    not upheld.
> 
> John
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Paul Wouters <[email-masked]>
Date: Mon, 1 Jul 2019 14:00:09 -0400 (EDT)

On Mon, 1 Jul 2019, Petr Špaček wrote:

[broken record on]

> fragmentation in DNS and thus require TCP for perfect operation.

The internet does not do "flag days". Please stop calling it flag days.
We recommend, via SHOULD's or MUST's what implementers should
implement. Obsolete things gradually fade out over time.

Please read these RFCs on how to obsolete things in protocols or
software without using "flag days":

- RFC 8624
- RFC 8247
- RFC 8221

These RFC's obsolete a number of things, gradually. It changes items for
implementors from MUST to SHOULD to SHOULD NOT to MUST NOT.

You can tell implementors MUST NOT. It's nice if you coordinate this with
a number of leading opensource implementers to release on a specific date,
but that's unrelated to the RFC being published.

Please stop the misleading phrase of "flag day". There is no flag day
for internet users nor internet implementors. That's not how any of
the internet works.

> coordinated change is planned for year 2020 [http://dnsflagday.net/2020/].

Definitely not include a url with "dnsflagday" in the name. (in general,
RFC's do not reference external URL's unless strictly needed, because
RFCs tend to outlive ephemeral websites, so even without 'flagday' I
would not recommend the URL for inclusion in the draft)

Paul

---

From: Joe Abley <[email-masked]>
Date: Mon, 1 Jul 2019 14:29:29 -0400

Hi Paul,

> On Jul 1, 2019, at 14:00, Paul Wouters <[email-masked]> wrote:
>

The IETF might or might not do flag days, but the Internet
demonstrably has done, at least in the instance of the transition from
NCP to TCP/IP which gave rise to the meaning of the very phrase that
we are discussing. (Maybe the MULTICS ASCII transition was first, but
NCP -> TCP/IP certainly used the phrase.)

Whether or not the last so-called DNS flag day or the next one are
flag days according to anybody's personal definition, I think the
point was well made (in Bangkok the other month and in DC more
recently) that the use of the phrase seems have given the respective
exercises a greater sense of operational urgency, which, if true,
seems useful, necessary even.

We are in the realms of marketing, here, not niche philology. If you
want to raise awareness of something, marketing is necessary.

I don't see the benefit to anybody in complaining about it unless you
think the end goal is undesirable.

Joe

---

From: Paul Vixie <[email-masked]>
Date: Mon, 01 Jul 2019 20:21:30 +0000

On Monday, 1 July 2019 18:00:09 UTC Paul Wouters wrote:
> > ...
> ...

"flag day" is a power word. the organizers of the 2019 event have tasted 
power, and evidently now intend to continue exercising that power.

noting, the 2020 event should limit itself to mandating tcp support, and not 
get involved with fragmentation at all. ideally tcp/853 (DOT) support.

-- 
Paul

---

From: Petr Špaček <[email-masked]>
Date: Tue, 2 Jul 2019 07:46:13 +0200

> get involved with fragmentation at all. ideally tcp/853 (DOT) support.

Let me clarify that we (as DNS flag day organizers) are not even
touching any RFC language because all the necessary pieces are already
standardized (madatory TCP support + mechanism to handle EDNS buffer size).

Some people claim that IETF cannot put requirements on operators, only
on implementations. We (as software and service vendors) are now saying
"if you want to interoperate, you as an operator have to follow
standards mandated for implementations", because in the end, what's
mandated for implementation does not matter if operators ignore these
requirements.

Of course it has to be explained to non-IETFers in many more words to
eliminate requirement to read all the RFCs, but that's it.

Changing default EDNS buffer size is, I believe, in competency of
individual implementations, so we as implementors will do a thing we
deem sensible.

Let's continue discussion about dns flag day 2020 at mailing list
[email-masked], please.

-- 
Petr Špaček  @  CZ.NIC

---

From: Paul Wouters <[email-masked]>
Date: Tue, 2 Jul 2019 10:31:52 -0400 (EDT)

> standardized (madatory TCP support + mechanism to handle EDNS buffer size).

If there is a security issue with fragmented DNS packets, perhaps that
warrants a new RFC document, possibly a BCP, that instructs implementers
what to do.

> mandated for implementation does not matter if operators ignore these

That is not different from the examples I gave earlier for those RFCs.
You can encourage/discourage or obsolete features. The good thing of
doing that in an RFC is that organizations and goverments and vendors
can point to it for compliance or policy and explain why it is done
a certain way.

> eliminate requirement to read all the RFCs, but that's it.

If you think that, you haven't properly informed implementers via
existing RFCs. A new one is apparently needed. I don't see why this
should not be done here. This is dnsops. If you find an operational
issue, you write a clarifying or correcting RFC.

> individual implementations, so we as implementors will do a thing we

No one is saying you are not sensible. My point was that none of this
is a flag day, and the promotion to reach a few implementations via
"flag days" is better directed at writing a new or updated RFC that
explains the issue and recommends implementors what (not) to do. That
also helps downstream with customers wanting RFC ABC compliance, which
is a much stronger signal than compliance to "dnsflagday.net/2020".

> [email-masked], please.

I'd rather not. Operational issues related to the DNS protocol
(mis)implementations or standard behaviour are well within the
charter of this group. DNS-OARC is a good venue to look at what
is happening, discuss why certain operational things are happening,
maybe brainstorm on how to fix it. Then coming to this group with
a proposal for a document to inform everyone and improve everything
is the right venue. It seems the problem and solution are already
well defined. It just needs to be written down in an RFC, and then
gradually software can implement the new behaviour. And again, if
for reasons vendors decide to implement it all on the same day to
ensure strict vendors are not unreasonably punished by being blamed
for failures, that's a reasonable goal. But seeing how upstream
vendors have no control over when downstream vendors pick up new
versions, the term "flag day" is just not the correct term to use,
and only brings up negative connotations in people being misled
into thinking IETF protocols needs flag days to continue running.

Paul

---

From: Mark Andrews <[email-masked]>
Date: Wed, 3 Jul 2019 12:18:32 +1000

> On 3 Jul 2019, at 12:31 am, Paul Wouters <[email-masked]> wrote:
> 

Defeating fragmentation attacks requires more than a BCP.

https://tools.ietf.org/html/draft-andrews-dnsop-defeat-frag-attack-00

> issue, you write a clarifying or correcting RFC.

Awaiting last call

https://tools.ietf.org/html/draft-ietf-dnsop-no-response-issue-13

> is a much stronger signal than compliance to "dnsflagday.net/2020”.

Winding back the default EDNS buffer size will break interoperability
with servers that now send TC=1 responses that otherwise didn’t happen
and do not accept TCP.

The key point of a flag day is that it is the day after which
interoperability fails, not the rate at which it is deploy which
you appear to be concentrating on.

The DNS 2019 not only had ON THE DAY changes (thanks to Google changing
their 8.8.8.8 service on the day) but introduce interoperability changes
between servers that where not compliant (failed to answer) and clients
that no longer worked around the non compliance.

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

---

From: Paul Wouters <[email-masked]>
Date: Wed, 3 Jul 2019 00:16:31 -0400 (EDT)

> https://tools.ietf.org/html/draft-andrews-dnsop-defeat-frag-attack-00

Sure, so you have an RFC already then. great. No need for a flag day
event reference, as you will have a proper RFC reference.

> you appear to be concentrating on.

But again,

We turn off old things on the internet all the time. It breaks
ancient stuff all the time too. We try to steer that process from the
IETF by gradually obsoleting/replacing code. But we don't do that in a
vaccum. We observe deployment statistics and try to push a little harder
to move the market when it is being slow.

And it is not a "flag day" because it depends on downstream release schedules

> their 8.8.8.8 service on the day)

So even pumping up the hype didn't actually help inform the people that
needed it the most. To me that is more an argument that flagdaying does
not do much good to begin with, and it is not woth the bad things it does
to the reputation of DNS by making the DNS appear worse than it is.

Paul

---

From: Töma Gavrichenkov <[email-masked]>
Date: Wed, 3 Jul 2019 07:27:39 +0300

Peace,

On Wed, Jul 3, 2019, 7:17 AM Paul Wouters <[email-masked]> wrote:

> needed it the most.

Err...
That's a strange conclusion.  I've personally seen dozens of server farms
being upgraded in less than a week in January, after another round of hype
hit the news.

Most of them could've done that a couple years ago.  Could as well have
stayed they way they were until right now.

--
Töma

---

From: Mark Andrews <[email-masked]>
Date: Wed, 3 Jul 2019 14:34:21 +1000

> On 3 Jul 2019, at 2:16 pm, Paul Wouters <[email-masked]> wrote:
> 

Observed misbehaviours over time https://ednscomp.isc.org/compliance/summary.html
You can drill down to specific failure modes.

> And it is not a "flag day" because it depends on downstream release schedules

Actually it is.  Nothing about “flag day” requires everything to be instantaneous.

> to the reputation of DNS by making the DNS appear worse than it is.

Actually we reached lots of people that needed to be reached.

Did we reach everybody? No but no one expected to reach everybody.

Did we measurably improve the situation? Yes.