[dns-at-ietf] Re: managing workload within and across DNS WGs

[Petr Špaček <[e-mail]>]

On 07. 11. 25 15:54, Petr Špaček wrote:
> Just from a quick glance this list problematic documents would include:
> 
> - RFC 7706: Decreasing Access Time to Root Servers by Running One on 
> Loopback (implemented differently)
> - RFC 7828: The edns-tcp-keepalive EDNS0 Option
> - RFC 7901: CHAIN Query Requests in DNS
> - RFC 8020 NXDOMAIN: There Really Is Nothing Underneath - cannot be 
> switched on
> - RFC 8094: DNS over Datagram Transport Layer Security (DTLS)
> - RFC 8145: Signaling Trust Anchor Knowledge in DNS Security Extensions 
> (DNSSEC) - implemented but data were so bad that it had to be replaced 
> with RFC 8509 shortly
> - RFC 8490: DNS Stateful Operations
> - RFC 8767: Serving Stale Data to Improve DNS Resiliency (implemented 
> differently)
> - RFC 8806: Running a Root Server Local to a Resolver (implemented 
> differently)
> - RFC 9102: TLS DNSSEC Chain Extension
> - RFC 9567: DNS Error Reporting
> 
> Obviously I did not go through list of all the RFCs every published.

This list really triggered some people and I got lots of complains, so 
lemme explain a bit:

In my view the whole purpose of RFC process is _interoperability_.

Imagine a new implementer shows up and starts _actually implementing_ 
what RFCs said. Today new entrants have a very, very bad day. Even such 
a basic protocol feature as NXDOMAIN is _still_ broken in the wild and 
whoever tried to implement RFC 8020 knows that is simply does not 
thinginteroperate on the current internet. Unbound has code for it, 
Cacheserve has it too, but both have disabled it by default because it 
does not work. (Unless you don't care about pockets of Akamai CDN, or 
Facebook, or ...). And it was way worse in November 2016 when the 
document was published.

The document admits there might be a problem but handwaves it away. Quote:
    Such name servers are definitely wrong and have always been.  Their
    behaviour is incompatible with DNSSEC.  Given the advantages of
    "NXDOMAIN cut", there is little reason to support this behavior.

Thanks IETF! That really helped me to write interoperable 
implementation! For that very reason the document fails very basic 
litmus test - "does it interoperate as described?" Hell no. The document 
is more of a political statement than standards document which actually 
interoperates.



RFC 7706/8806 story is a bit different. It does interoperate on paper, 
but no implementation bothered to actually follow what these two RFCs 
say and everyone I'm aware of implemented something else. Perhaps that 
might be taken as an indication the document should have said something 
else?


I guess we can generalize this:
When an implementer takes current work products of dnsop WG, they _need_ 
to know the oral history of the DNS to interpreted these documents 
correctly and create interoperable implementation. That is NOT how I 
would describe high quality standards documents.

Summary:
Requiring implementations before rubber stamping RFCs would improve 
quality of output. I believe at the same time it would cut down on 
amount of busy work the WG does for no tangible effect (= docs nobody 
implements).

I hope this clarifies what I'm trying to say.

-- 
Petr Špaček