Re: [DNSOP] "flagday" again, was Re: Wrapping up draft-ietf-dnsop-dns-tcp-requirements

[Mark Andrews <[e-mail]>]

> On 3 Jul 2019, at 12:31 am, Paul Wouters <[e-mail]> wrote:
> 
> On Tue, 2 Jul 2019, Petr Špaček wrote:
> 
>> 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).
> 
> 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.

Defeating fragmentation attacks requires more than a BCP.

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

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

Awaiting last call

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

>> Changing default EDNS buffer size is, I believe, in competency of
>> individual implementations, so we as implementors will do a thing we
>> deem sensible.
> 
> 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”.

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.

>> Let's continue discussion about dns flag day 2020 at mailing list
>> [e-mail], 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
> 
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]              INTERNET: [e-mail]