[dns-operations] dnsop-any-notimp violates the DNS standards

[Edward Lewis]

On 3/16/15, 11:05, "bert hubert" <bert.hubert at netherlabs.nl> wrote:

>Sorry? We solve implementation hardship by standards action now?

My thoughts in this thread (and I'm choosing to keep this in
dns-operations) keep circling because I've spent time at different
perspectives.

On one hand we like to say that the Internet has valued innovation at the
edges.  Innovation is generally doing something unconventional, or
"against the standard."  (Yes, it can also mean exploring the unexplored.)
 When doing something "against the standard" one of the results is
shifting more cost on to your neighbors.

If one values adherence to standards, innovation is shackled to some
extent.  I once made this comment inside a company where there had been
intense cost reducing efforts.  When asked "how should we innovate" my
answer was to fatten the budget and then illustrated that if you have a
well-tuned machine, any change is going to be burden somewhere else.
Sometimes, as you shift the burden around you can raise revenue to offset
it and sometimes you can shift the burden to where it "disappears."  But
during the shifts, innovation and standards often work against each other.

When writing the AXFR update/clarification RFC, one of the motivations was
to isolate AXFR from being an essential element of a DNS server.  There
are zones for which generating a roster is not practical, so it's not
good, if you will, to expect an AXFR to come form it.  Such zones may be
those with telephone numbers (ENUM) or even IPv6 reverse mappings.
Usually "practical" refers to the speed of updates as opposed to shear
size.

I can imagine an environment in which constructing a DNSSEC-signed
authoritative answer to an ANY query could be a real pain.  In
environments that tailor responses by query source, you'll find that A and
AAAA records are generally from a recipe while the others types are
static, in some cases the A and AAAA, or one or the other, don't exist.
Sometimes, if the A and AAAA records are null, you want the entire node to
own no records, whether or not ir exists for the NSEC/NSEC3 chain.  Think
this is "stupid DNS tricks?"  One might, but, this is something that gets
people to buy DNS hosting services.

When I studied wildcards for that update/clarifications RFC, it was
correctly pointed out to me (by DJB) that standard ways of doing something
need not be the only ways to accomplish something.  For wildcards, the
standards-defined method is compatible with AXFR.  Other means of
synthesizing an answer just wouldn't be - but if one could extend AXFR,
you could expand answer synthesis.  Or maybe this is all just stupid DNS
tricks and we shouldn't bother.

But, I do agree with the handwaving argument to date is insufficient and a
bit weak.  It is right to challenge the proposal as it stands (as I have
done too).  While I an inclined to agree to deprecate qtype=ANY as well as
other elements of the protocol I am also inclined to demand a better
rationale before accepting a document's proposal.

But yes, I do think standards actions in response to local problems can at
times be the right thing to do, if we value innovation.  I'll note that
Paul Vixie has talked about cost shifting in the past.  Saying one is
"innovating" isn't license to shift costs without good reason or warning
or acceptance or ...  innovation doesn't remove the need to say "I'm
sorry." ;)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4604 bytes
Desc: not available
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20150317/aa20dd50/attachment.bin>