In message <54c40d28.7050...@redbarn.org>, Paul Vixie writes:
> > 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."
It is clearly the clients fault. Add to that there are extremely
few pipelining clients that I'm willing to bet that despite adding
a acl to force in order reponses for broken clients it will never
need to be set other than for testing.
This is a bit like improving the case preservation in responses by
using case sensitive compression when constructing responses. There
is one set top manufacture that does case sensitive matching of the
answer section against the original query and a broken nagios test.
There is a acl to disable case sensitive compression but it is
enabled by default and almost all clients did not care.
> > [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.
Pipeling over UDP has been standard practice between nameservers
for 25 years. Why are we even worrying about whether it should be
permitted over TCP? If the socket is open when you need to send
another query just use it.
> ===
>
> 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.
We should also stop thinking of the installed base as something
that cannot be changed. This is particularly true of authoritative
servers. We can identify broken servers. We can inform their
operators that they are broken. RFC 1033 even detailed how to do
this.
COMPLAINTS
These are the suggested steps you should take if you are having
problems that you believe are caused by someone else's name server:
1. Complain privately to the responsible person for the domain. You
can find their mailing address in the SOA record for the domain.
2. Complain publicly to the responsible person for the domain.
3. Ask the NIC for the administrative person responsible for the
domain. Complain. You can also find domain contacts on the NIC in
the file NETINFO:DOMAIN-CONTACTS.TXT
4. Complain to the parent domain authorities.
5. Ask the parent authorities to excommunicate the domain.
We can audit authoritative servers very easily.
If you want to see which tld servers fail to follow the EDNS protocol
there is a list here: http://users.isc.org/~marka/tld-report.html
This is a lot better than it was originally and no I have not yet
contacted the operators over most of the issues here. Some I have.
Echoing of EDNS flags went away (there is one today who is yet to
be contacted).
http://users.isc.org/~marka/ts/tld.flagsfail.html
BADVERS on unknown EDNS version went away.
http://users.isc.org/~marka/ts/tld.optfail.html
Just returning the EDNS(0) response with the rcode set to BADVERS
has just about gone away.
http://users.isc.org/~marka/ts/tld.opt1fail.html
Failure to return a OPT record in a truncated response went away.
http://users.isc.org/~marka/ts/tld.512fail.html
Mark
> --
> Paul Vixie
>
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
