[Bug 1733] Enhance support for QoS (ToS) by supporting DSCP/CS and adding option

[bugzilla-daemon at bugzilla.mindrot.org]

https://bugzilla.mindrot.org/show_bug.cgi?id=1733

--- Comment #21 from Philip Prindeville <philipp at redfish-solutions.com> 2010-10-01 03:26:48 EST ---
Looking at this in a similar historical context...

I remember when DNS was first deployed. Prior to it, we had used HOSTS
files that we picked up via FTP from the NIC at USC.

A lot of programs even had the addresses of servers compiled into them.

When DNS came out, there were libraries you could link against, but not
all programs were released immediately using them.  Indeed, some
programs even used their own resolver libraries and had root name
servers coded into them.

After a while, the load on the root name servers became too high, and
these programs needed to be hunted down and replaced.  Such programs
also didn't leverage caching.

At no time, however, did the system-wide libraries (libresolv.a, etc)
allow the user to specify an alternate location for the resolver
configuration, or to override the name servers to query.

Which turned out to be fortuitous.

Not only can incorrect configuration of the resolver lead to heavy
loading on the root name servers, or poor performance due to a lack of
local caching... but:

* by diverting DNS queries to a highjacked server, I can intercept a
lot of your network traffic (email, for instance, by returning bogus MX
records);

* I can subvert your PKI by pointing you at bogus trusted certificate
authorities;

* I can cause a denial of service attack by pointing you at bogus NTP
servers and over time skewing your clock such that loses critical sync
with other server.

etc.

So generating a DNS query is not a privileged operation.  It's a rather
banal operation, and superficially affects only the process making the
query.  In this respect, it bears a good deal of parallel to the
discussion we're having about what's the big deal with setting QoS
bits.

Yet through a bit of misconfiguration by the user, it can overwhelm
critical network infrastructure (the root name servers), and can open
doors up to network attack.

Similarly, misconfiguration of QoS bits by the user can deprive other
critical network services of reserved bandwidth, etc.

Why don't we initially just commit it as is, and if someone comes
forward with a usage case that absolutely requires per-user
configuration of QoS settings, we'll change it then.

Because it's easier to add new configuration capability later once it's
proven it's needed, than to revoke it once software is deployed in the
field.

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.