> Mark Andrews <mailto:ma...@isc.org>
> Thursday, January 22, 2015 6:29 PM
> In message <32707.1421975...@dash.isi.edu>, John Heidemann writes:
>> ...
>> I'm confused. I thought we agreed the installed base doesn't do TCP
>> pipelining basically ever.
>
> The installed base has supported pipelining forever. BIND 4.8
> supported it.
both statements above are partly correct.
the installed initiator base does not use pipelining, ever. bind
responders, since 4.8, has accepted pipelining, but with ordered
responses until a currently unreleased patch was put in recently. bind
responders through bind 8 did not read the next (potentially pipelined)
request out of the tcp socket until after it had sent its response to
the previous request, so, there was no parallelism of any resulting
cache miss activities.
>
> What the installed base didn't do was out of order reponses /
> parallel processing. That said doing this is permitted by RFC
> 103[45]. A client that pipelined queries needed to check the txid
> of responses.
while that's common sense (if you have more than one request outstanding
on a tcp session, you should check txid on each response), the fact that
all responders in the installed base up to this present day answered in
order meant that a pipelining initiator could lack this txid check and
not have had any problems -- for 25 years or so. that's not a concern to
be dismissed as "not our fault, let's move on."
>
> [Pipelining] itself is supported by the protcol whereas SMTP didn't
> support pipelining as it is a lock step protocol.
pipelining wasn't specified, but it did usually work, which is why
spammers abused it, which is why a common check for "am i talking to a
spammer" today is to deny pipelining and then if the initiator pipelines
anyway, reset the connection. so, "supported by the protocol" isn't a
perfectly clear standard guiding discussion.
===
we've been "rebuilding the airplane in-flight", as suz put it, not just
with dnssec, but with dns itself. i wrote about this ("DNS Complexity")
and included this text:
> From this overview, it is possible to conclude that DNS is a poorly
> specified protocol, but that would be unfair and untrue. DNS was
> specified loosely, on purpose. This protocol design is a fine example
> of what M.A. Padlipsky meant by "descriptive rather than prescriptive"
> in his 1984 thriller, The Elements of Networking Style (Prentice
> Hall). Functional interoperability and ease of implementation were the
> goals of the DNS protocol specification, and from the relative ease
> with which DNS has grown from its petri dish into a world-devouring
> monster, it's clear to me that those goals were met. A stronger
> document set would have eliminated some of the "gotchas" that DNS
> implementers face, but the essential and intentional looseness of the
> specification has to be seen as a strength rather than a weakness.
>
> That having been said, a stronger document set written today would not
> be able to put all of the DNS genies back into their bottles. Too many
> implementations have guessed differently when presented with a loose
> specification, and interoperability today is a moving, organic target.
> When I periodically itch to rewrite the specification from scratch, I
> know there are too many things that must be said that also cannot be
> said. It's as though, in a discussion of the meaning of some bit
> pattern, a modern description of the protocol---written with full
> perspective on all that has been done in the DNS field---would have to
> say, "It could mean x but some implementations will think it means y
> so you must be cautious."
>
> If the objective meaning of a set of potential states and conditions
> and patterns has a complexity index that is a function, somehow, of
> the combinations and permutations of those states, conditions, and
> patterns, as well as the multiple interpretations and deliberate
> uncertainties, then DNS is a very complex system, even though its
> rules are simple and few, and even though a new DNS protocol agent can
> be constructed using only a few thousand lines of software code.
>
> (at <http://queue.acm.org/detail.cfm?id=1242499>)
so:
sometimes the installed based can be simply and completely damned, as i
did with BIND when microsoft noticed that we only accepted AXFR with
ANCOUNT=1, which was drastically wasteful of network capacity, as well
as damned inconvenient for other implementors. in that case we fixed all
responders instantly, and gave initiators the option to use the old
(one-answer) or "new" (many-answer) format, first defaulting to the old
way, and then defaulting to the new way. stuff broke, and got fixed, and
we moved on. notably, that was in 1995 or so, and BIND was the only
widely installed DNS server, and there were only 30,000 or so
installations world wide. now that we have dozens of DNS implementations
many of which are inside security appliances and many of which are not
open-source, and there are 30,000,000 installations (that we know of), i
think we have to weigh the burden of any change we want to make that
could violate older implementations' reasonable-at-the-time assumptions,
against the burden of choosing a non-interfering signal pattern, like a
new port number, or a new protocol verb.
--
Paul Vixie
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
