I remain puzzled at the entire technological motivation that CloudFlare
claims for this deliberate creation of interoperability problems.
In particular, what exactly is the programming difficulty that they
claim they're encountering in implementing QTYPE=*? Are they also having
trouble implementing NXDOMAIN, which from a programming perspective is a
very similar unification of data across all types?
The rest of this message identifies specific rules that CloudFlare's
threatened plan will violate in IETF's mandatory DNS standards.
David C Lawrence writes:
> RFC 1035 explicitly allows for a server to indicate that a kind of
> query is not implemented. Whether it is a good idea to respond to ANY
> this way is a separate argument that is worth having. You just won't
> win on the foundation that it is a violation of the standard.
Let's look at what the standards actually say.
RFC 1034 clearly defines QTYPE=* to match "all RR types", along with,
e.g., QTYPE=A to match "just that type". It explicitly says that "the
name server looks for matching RRs".
CloudFlare's stated plans will violate this rule. This "matching" for
QTYPE=* is precisely what CloudFlare claims is too hard to implement!
You claim that this violation of a rule in IETF's mandatory DNS
standards doesn't constitute a violation of the standards. Evidently
you believe that the standards contain some relevant exception to the
rule. What exactly do you claim that this exception is?
The foundation for your argument, apparently, is the fact that RFC 1035
defines a syntax for a NOTIMP response. But why do you think this is of
any relevance to the "matching RRs" rule? The rule doesn't say "the name
server looks for matching RRs, except for types that the server doesn't
want to bother implementing". Where exactly, and what exactly, is the
CloudFlare exception?
Do you believe that the availability of a NOTIMP syntax overrides all
other rules and frees the server to use this syntax for anything that it
doesn't want to implement? Here's a hypothetical example to consider:
* A very large cache operator is opposed to the usage of DNSSEC. (The
operator's reason for this isn't relevant to this example.)
* To deter usage of DNSSEC, the cache operator decides to create
large-scale DNSSEC interoperability problems, augmenting DNSSEC's
existing fragility.
* Specifically, the cache operator issues DNSSEC queries to servers;
and then, if a server response shows DNSSEC support, the cache
operator returns NOTIMP to clients for _all_ of the server's data.
* To avoid any sudden changes, the cache operator slowly ramps up
this behavior, turning on the DNSSEC queries with higher and higher
probability as time passes, but jumping immediately to probability
1 for servers that don't show DNSSEC support.
* To justify the use of NOTIMP, the cache operator claims that it
_wanted_ to implement actually returning DNSSEC records to clients
but found this too complicated given geoip blah blah blah, so it
had to return NOTIMP. It quotes your claim that RFC 1035
"explicitly allows" returning NOTIMP.
Would you call this cache behavior compliant with the mandatory DNS
standards? No? Why not? Why isn't the cache free to use NOTIMP whenever
it hasn't implemented something? Are you quite sure that you've thought
through what you're claiming?
Let's continue looking at the mandatory DNS standards. RFC 1034
explicitly allows not-implemented queries in _some_ cases, such as
inverse queries:
Implementation of this service is optional in a name server, but all
name servers must at least be able to understand an inverse query
message and return a not-implemented error response.
RFC 1035 is also quite clear about this:
Inverse queries are an optional part of the DNS. Name servers are
not required to support any form of inverse queries. If a name server
receives an inverse query that it does not support, it returns an
error response with the "Not Implemented" error set in the header.
While inverse query support is optional, all name servers must be at
least able to return the error response.
If the RFCs had meant to say that _all_ DNS features are optional
(leaving interoperability up to the whim of bullies, apparently what
you're endorsing), then why didn't the RFCs simply say that? Why did
they explicitly highlight particular features as being optional?
Furthermore, RFC 1123 explicitly requires DNS software to "support all
well-known, class-independent formats". This is another mandatory rule
that CloudFlare's plan clearly violates. What exactly do you think this
"support" requirement means, if servers are free to use NOTIMP whenever
they want, for example for QTYPE=*?
RFC 1034 explicitly says that a server "is free to refuse to perform
recursive services for any or all clients" (and also explicitly says
that an AXFR "may cause an error, such as refused") but explicitly says
that "All name servers must implement non-recursive queries". Do you
think a server is allowed to use NOTIMP for non-recursive queries? Do
you think that "implement" prohibits NOTIMP while "support" doesn't?
Frankly, your position looks _extremely_ difficult to defend.
---Dan
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
