Slashdot Mirror

You missed a good one:

RFC 1480 section 1.2:

"Even though the original intention was that any educational institution anywhere in the world could be registered under the EDU domain, in practice, it has turned out with few exceptions, only those in the United States have registered under EDU, similarly with COM (for commercial)."

Sadly, your humble opinion is contradictory to the facts. The 3-letter TLDs are in fact US-specific, and always have been.

They were never intended to be.

RFC 1480 section 1.2:

"Even though the original intention was that any educational institution anywhere in the world could be registered under the EDU domain, in practice, it has turned out with few exceptions, only those in the United States have registered under EDU, similarly with COM (for commercial)."

No the .com domain belongs to the US. .com, .net, .gov, .mil, .edu, .and org are ALL US domains.

I refute this claim.

[.com .org .net .edu .int ] were classified as 'World Wide Generic Domains' while [ .gov .mil .us ] were US-only according to RFC 1591 [^1]

I highly recommend that you read the paper titled "WRONG TURN IN CYBERSPACE: USING ICANN TO ROUTE AROUND THE APA AND THE CONSTITUTION" by A Michael Froomkin. [^2]

In 1998, ICAAN was formed and given management rights of the [ .com .net .org ] TLD's by the USC. In 2000, ICAAN's rights were formally recognized by the DoC and separate (and conflicting) agreements were signed. U.S government retained control of [ .int .edu ] domains and set restrictive polices on both (against the RFC). Please note that ICAAN is required to comply to RFC 1034, 1035 and 1591 [^3][^4]

Today, we no longer have the 'World Wide Generic Domains'. These have been replaced with a different TLD system which specifies Generic Top Level Domains (gTLD) as domains that operate directly under policies established by ICANN processes for the global Internet community. [^5] [ .com .org .net ] are classified as gTLD's and thus are for the global Internet community. [^6]

http://www.ntia.doc.gov/legacy/ntiahome/domainname/agreements/summary-factsheet.htm

Nowhere in this factsheet does it say that [ .com ] etc belong to the US. This is simply regarding an agreement transferring management from the U.S government to ICAAN.

I'll see you're source and raise you 6

[^1] http://tools.ietf.org/html/rfc1591

[^2] http://personal.law.miami.edu/~froomkin/articles/icann.pdf

[^3] http://tools.ietf.org/html/rfc1034

[^4] http://tools.ietf.org/html/rfc1035

[^5] http://en.wikipedia.org/wiki/Top-level_domain

[^6] http://en.wikipedia.org/wiki/Generic_top-level_domain

No the .com domain belongs to the US. .com, .net, .gov, .mil, .edu, .and org are ALL US domains.

I refute this claim.

[.com .org .net .edu .int ] were classified as 'World Wide Generic Domains' while [ .gov .mil .us ] were US-only according to RFC 1591 [^1]

I highly recommend that you read the paper titled "WRONG TURN IN CYBERSPACE: USING ICANN TO ROUTE AROUND THE APA AND THE CONSTITUTION" by A Michael Froomkin. [^2]

In 1998, ICAAN was formed and given management rights of the [ .com .net .org ] TLD's by the USC. In 2000, ICAAN's rights were formally recognized by the DoC and separate (and conflicting) agreements were signed. U.S government retained control of [ .int .edu ] domains and set restrictive polices on both (against the RFC). Please note that ICAAN is required to comply to RFC 1034, 1035 and 1591 [^3][^4]

Today, we no longer have the 'World Wide Generic Domains'. These have been replaced with a different TLD system which specifies Generic Top Level Domains (gTLD) as domains that operate directly under policies established by ICANN processes for the global Internet community. [^5] [ .com .org .net ] are classified as gTLD's and thus are for the global Internet community. [^6]

http://www.ntia.doc.gov/legacy/ntiahome/domainname/agreements/summary-factsheet.htm

Nowhere in this factsheet does it say that [ .com ] etc belong to the US. This is simply regarding an agreement transferring management from the U.S government to ICAAN.

I'll see you're source and raise you 6

[^1] http://tools.ietf.org/html/rfc1591

[^2] http://personal.law.miami.edu/~froomkin/articles/icann.pdf

[^3] http://tools.ietf.org/html/rfc1034

[^4] http://tools.ietf.org/html/rfc1035

[^5] http://en.wikipedia.org/wiki/Top-level_domain

[^6] http://en.wikipedia.org/wiki/Generic_top-level_domain

No the .com domain belongs to the US. .com, .net, .gov, .mil, .edu, .and org are ALL US domains.

I refute this claim.

[.com .org .net .edu .int ] were classified as 'World Wide Generic Domains' while [ .gov .mil .us ] were US-only according to RFC 1591 [^1]

I highly recommend that you read the paper titled "WRONG TURN IN CYBERSPACE: USING ICANN TO ROUTE AROUND THE APA AND THE CONSTITUTION" by A Michael Froomkin. [^2]

In 1998, ICAAN was formed and given management rights of the [ .com .net .org ] TLD's by the USC. In 2000, ICAAN's rights were formally recognized by the DoC and separate (and conflicting) agreements were signed. U.S government retained control of [ .int .edu ] domains and set restrictive polices on both (against the RFC). Please note that ICAAN is required to comply to RFC 1034, 1035 and 1591 [^3][^4]

Today, we no longer have the 'World Wide Generic Domains'. These have been replaced with a different TLD system which specifies Generic Top Level Domains (gTLD) as domains that operate directly under policies established by ICANN processes for the global Internet community. [^5] [ .com .org .net ] are classified as gTLD's and thus are for the global Internet community. [^6]

http://www.ntia.doc.gov/legacy/ntiahome/domainname/agreements/summary-factsheet.htm

Nowhere in this factsheet does it say that [ .com ] etc belong to the US. This is simply regarding an agreement transferring management from the U.S government to ICAAN.

I'll see you're source and raise you 6

[^1] http://tools.ietf.org/html/rfc1591

[^2] http://personal.law.miami.edu/~froomkin/articles/icann.pdf

[^3] http://tools.ietf.org/html/rfc1034

[^4] http://tools.ietf.org/html/rfc1035

[^5] http://en.wikipedia.org/wiki/Top-level_domain

[^6] http://en.wikipedia.org/wiki/Generic_top-level_domain

Slashdot stips the unicode trademark symbol. Shame on them!

Well of course they don't support the technology: It's only fourteen years old, after all. What did you think this was, some sort of cutting-edge technology news site?

a brick can fly if it has a big enough engine

"with sufficient thrust, pigs fly just fine."

No, your completely wrong. .com, .net, .org are, and always have been, US domains

RFC 1591:

Of these generic domains, five are international in nature, and two are restricted to use by entities in the United States.

Well, that's a 1994 RFC, and one that doesn't seem to be honored very well.

For instance, not just anyone can register an ORG domain - you have to meet certain requirements (typically non-commercial, but it's not very well enforced). Wikipedia does have some good info on it.

Or for instance, Groklaw does not meet the definition you provided; but it has a NET domain registered.

No, your completely wrong. .com, .net, .org are, and always have been, US domains

RFC 1591:

Of these generic domains, five are international in nature, and two are restricted to use by entities in the United States.

      World Wide Generic Domains:

      COM - This domain is intended for commercial entities, that is
                  companies. This domain has grown very large and there is
                  concern about the administrative load and system performance if
                  the current growth pattern is continued. Consideration is
                  being taken to subdivide the COM domain and only allow future
                  commercial registrations in the subdomains.

      NET - This domain is intended to hold only the computers of network
                  providers, that is the NIC and NOC computers, the
                  administrative computers, and the network node computers. The
                  customers of the network provider would have domain names of
                  their own (not in the NET TLD).

      ORG - This domain is intended as the miscellaneous TLD for
                  organizations that didn't fit anywhere else. Some non-
                  government organizations may fit here.

The politicians doesn't have a good understanding of internet and do not understand how to control it, thus they seek to take it away.

Word.

This is what the Internet is and how it works. If you want to change the Internet, you need to be publishing there. Anything less, is soapboxing for a completely different set of motivations (which I personally believe to be simply "fear").

His bit about "to, from and BCC" in this Boston article is completely bogus. Just see RFC 680 (from 1975) and notice that all of them were completely specified.

Hmm, pigeon hunters--say, weren't they also responsible for shooting-down RFC 1149?

Say, isn't this the same guy who "invented" RFC 1149?

Learn how to use a computer. Learn how to build your own network.

Sorry, I can't afford that many pigeons to implement RFC1149. And using smoke means more greenhouse gases.

Because when TPTB take the Internet and emasculate it, turning it into Encarta 2.0, you'll wonder why you spent stupid money on that thing that just became a very expensive doorstop.

the way we did it before service providers took over the tedious task of assigning IPs and charging obscene amounts of money for the privilege: point to point, over telephone lines.

Mate, I'm old enough to know how to setup and use a BBS (just haven't had enough time to join /. earlier).

Actually old enough to remember that they used to charge obscene amount of money for the privilege of using telephone lines - otherwise why you reckon the first crackers needed to invent and master the phreaking art?
You reckon they would be so magnanimous to refrain in doing it again after they emasculate the internet?

Plus, P3P is faulty, it has a loophole which one can take advantage of. Much better to simply follow a properly designed spec for this sort of thing, like RFC 3514.

I know this has been rated Troll by the slashdot gods, but I just have to say how COOL bird-based satellite antennas would be. All that needs to be done is to figure out the mini-motor system to keep them pointed in the right direction.

This would certainly give RFC 2549 a boost.

Pigeon net - could work well in crowded city environments.

Yep. It's still a draft, but it's already supported by Chrome. Firefox is working on it but may be waiting for the draft to be finalized. Wikipedia reports that there's a Firefox add-on that does it already, but of course it's not all too useful until a majority of internet users have support for it (general support by mobile browsers will likely take a couple years.... Server Name Indication is still not quite supported well enough to really justify using it despite being several years old).

Well, actually, it's a little different from SNI because there are currently a good number of servers around with self-signed certs. Adding DNSSEC stapled certificates to those would not affect old browsers and get rid of the warnings in new browsers.

But I guess somebody's paycheck depends on reinventing the wheel?

http://tools.ietf.org/html/rfc3265

Its a tcp/ip connection, that's all.

Because the networks are so unreliable many sip clients send a packet back and forth, using CRLF-CRLF ping answered by a single CRLF pong, according to RFC5626.

So the load is WAY different than connection to the base station: Its WAY SMALLER, and WAY LESS FREQUENT.

https://tools.ietf.org/html/

This is called NAT64 and DNS64.

NAT64: http://tools.ietf.org/html/rfc6146
DNS64: http://tools.ietf.org/html/rfc6147

It is one of the worse transition methods in my opinion. DNS64 is stateless but is not compatible with DNSSEC. NAT64 is stateful and just another Large Scale Nat solution (ISP-NAT).

The better method is dual stack. When the ISP is no longer able to provide sufficient IPv4 addresses they should using DS-lite with A+P: http://tools.ietf.org/html/rfc6346

This is called NAT64 and DNS64.

NAT64: http://tools.ietf.org/html/rfc6146
DNS64: http://tools.ietf.org/html/rfc6147

It is one of the worse transition methods in my opinion. DNS64 is stateless but is not compatible with DNSSEC. NAT64 is stateful and just another Large Scale Nat solution (ISP-NAT).

The better method is dual stack. When the ISP is no longer able to provide sufficient IPv4 addresses they should using DS-lite with A+P: http://tools.ietf.org/html/rfc6346

This is called NAT64 and DNS64.

NAT64: http://tools.ietf.org/html/rfc6146
DNS64: http://tools.ietf.org/html/rfc6147

It is one of the worse transition methods in my opinion. DNS64 is stateless but is not compatible with DNSSEC. NAT64 is stateful and just another Large Scale Nat solution (ISP-NAT).

The better method is dual stack. When the ISP is no longer able to provide sufficient IPv4 addresses they should using DS-lite with A+P: http://tools.ietf.org/html/rfc6346

Yes, sorry. What I described is called DS-lite with A+P and was published at the same time as DS-lite.

DS-lite RFC 6333 (August 2011): http://tools.ietf.org/html/rfc6333
A+P extension RFC 6346 (August 2011): http://tools.ietf.org/html/rfc6346

Yes, sorry. What I described is called DS-lite with A+P and was published at the same time as DS-lite.

DS-lite RFC 6333 (August 2011): http://tools.ietf.org/html/rfc6333
A+P extension RFC 6346 (August 2011): http://tools.ietf.org/html/rfc6346

Disclaimer: my only experience with IPv6 was on a Linux client machine. For me, it meant horribly slow web browsing as many requests involved waiting for IPv6 to timeout before if would fall back and try IPv4. I opted for lazy and just disabled IPv6 rather than go looking for a solution.

Was this recent? As I recall, this was an issue a few years ago, but was addressed by the draft RFC "Happy Eyeballs", and I gather most systems have more or less implemented it. I haven't heard of anyone disabling IPv6 for that reason for a while.

Unless your computer supports Privacy extensions If it does your ipv6 address is not static but generated randomly.

Same AC as before here, I'll try this again I guess.

Sadly I wish it were so

1. AES is not a hash function. It can be used in some constructions to emulate a hash, but you wouldn't just call that AES-256 as you do, nor is it commonly used this way.

No but sadly it is used as one. Google results for SHA password storage: 143,000 results, results for AES password storage: 490,000 results. It is commonly used that way.

You are again misunderstanding the situation. AES is commonly used to store passwords by encrypting them, it shouldn't be but it is. This is done by people who either just don't know any better or think they need to be able to reverse them (for instance to send them to you when you forget). What is almost never done is using AES as a hash function which is what you're saying. Follow the search results you mentioned for AES password storage, they aren't doing what you're proposing. You can't even do this unless you implemented it yourself or used 3rd party crypto libraries: no standard crypto library I know of has an AES hash construction built in, they just aren't popular outside of very special circumstances. If you can name one application that does this I'd be very surprised.

2. "Because hash functions like AES256 only provide 2^256 possible unique outputs..." Only? This would put you at ~2^128 outputs before you could really hope to get a collision (and not a collision with a specific output, just any two outputs colliding). This is WAAAY beyond the resources of all of humanity.

We said the same things about DES/3DES, Moores law, the groth of bot nets, and all that has some interesting side effects

First of all, no we didn't, in fact IBM fought with the NSA to keep DES 64 bits because they felt 56 was not enough, and that was in the 70s. Second, as before, 3DES is not even remotely broken as of now. Third, I didn't say it would be beyond us forever, just now and for the foreseeable future. Your article makes it sound like any day now we're going to be finding collisions in AES hash outputs because there's "only" 2^256 of the same, which is:

a) wrong. The number attached to AES is the keysize, not the block size, AES no matter what key length has the same block size which is what would govern collisions. Again you are confusing ciphers and hashes where that number would actually tell you the output length.
b) ridiculous. If you truly had a random function that covered roughly 2^256 outputs you are not finding specific collisions in our lifetime, and yes I'm including Moores law, distributed attacks, and deep thought when it becomes available.

3. "Brute-forcing older algorithms is definitely possible now (DES and 3DES already fell to brute-force attacks several years ago)." Since when was 3DES brute-forced? I see no evidence that even 2TDEA has been brute-forced, let alone 3TDEA which is what people actually use. Citation greatly needed.

DES was cracked in 1998 on $250,000 or so of custom hardware, using an average of 4.5 days (so half the key space). In the last 13 years hardware has gotten SIGNIFICANTLY faster and cheaper, from a 2006 paper: http://www.ietf.org/rfc/rfc4772.txt, and those 10 gig/sec chips are CHEAP now. Putting a few tens of thousands onto custom boards wouldn't be that expensive (same price range as deep crack).

Yes, but I asked about 3DES, not DES. DES is long broken, we all know this. DES has 56 bits of key strength. 3TDEA 3DES has 112 bits, that is 56 bits harder for those doing the math. You are obviously not understanding the scale of that difference.

Put it this way, let's say those chips are a 1000x faster than they were then (they're aren't but let's be generous). You said tens of thousands on a board, but let's figure out a way to get a million on a board, and then just to make it fun let

Isn't it a little early for April 1 Patents.

Sadly I wish it were so

1. AES is not a hash function. It can be used in some constructions to emulate a hash, but you wouldn't just call that AES-256 as you do, nor is it commonly used this way.

No but sadly it is used as one. Google results for SHA password storage: 143,000 results, results for AES password storage: 490,000 results. It is commonly used that way.

2. "Because hash functions like AES256 only provide 2^256 possible unique outputs..." Only? This would put you at ~2^128 outputs before you could really hope to get a collision (and not a collision with a specific output, just any two outputs colliding). This is WAAAY beyond the resources of all of humanity.

We said the same things about DES/3DES, Moores law, the groth of bot nets, and all that has some interesting side effects

3. "Brute-forcing older algorithms is definitely possible now (DES and 3DES already fell to brute-force attacks several years ago)." Since when was 3DES brute-forced? I see no evidence that even 2TDEA has been brute-forced, let alone 3TDEA which is what people actually use. Citation greatly needed.

DES was cracked in 1998 on $250,000 or so of custom hardware, using an average of 4.5 days (so half the key space). In the last 13 years hardware has gotten SIGNIFICANTLY faster and cheaper, from a 2006 paper: http://www.ietf.org/rfc/rfc4772.txt, and those 10 gig/sec chips are CHEAP now. Putting a few tens of thousands onto custom boards wouldn't be that expensive (same price range as deep crack).

Slight problem: ICMP runs on top of IP. See http://tools.ietf.org/html/rfc792

Voice-Family: Leo having a conversation with Sheldon in an episode of "The Big Bang Theory".

No, Unbound and NSD do not have HTTP servers. Come on. I was just trying to explain a complicated concept in a half sentence; it's called an analogy.

To make the pedants happy: A DNS server is, if you will, akin to an office suite. Yeah, what's really going on is that there is an "authoriative DNS server" that serves arbitrary name-to-data mappings so that programs called "recursive DNS servers" can give said mapping to a client program and there's also non-recursive forwarding DNS servers and blah blah blah. I think the audience is falling asleep at this point...

Now, when I said above that a DNS server is akin to an office suite, I wasn't saying that there is a spreadsheet and a word processor included with DNS servers. However, if someone were willing to sponsor it, I would be perfectly happy to make a version of MaraDNS that uses SINK RRs and dynamic updates to allow people to perform document collaboration via DNS.

Wow. Good question. Each of the modules has its own readme with info on how to implement it. Obviously, you no longer need to go through the build process if your using FreeBSD 9. I don't know of any new docs or a howto. Sorry. However, the info from each of the readme's on this post help. There should be more up to date readme files with FreeBSD 9 but I haven't checked.

You can fairly easily sign your zones using Bind: http://www.bind9.net/manual/bind/9.3.2/Bv9ARM.ch04.html#DNSSEC

This takes a few steps:
  * Generate keys - a zone-signing key (ZSK) and a key-signing-key (KSK) - usually a pair of keys for each zone
  * Sign your zones - well, the records inside them
  * Now use your zone.signed file as the zonefile that Bind serves up

Next, once you query your server and everything looks good, you need to ship either the DNSKEY record or DS (digest of the key) to your registrar *. They will ship that to the registry, which signs either your key or digest. Most gTLDs (.com/.org) require only DS records, while ccTLDs (.de/.eu) require DNSKEY records.

Then, as long as you're using a DNSSEC aware resolver, you can test the hierarchy of the signed zone:

dig @149.20.64.21 comcast.com any +dnssec

Look for the "ad" bit set in the Flags section. If you just want to see the keys in this example, simply limit dig to that RR type:

dig @149.20.64.21 comcast.com dnskey +multiline +dnssec

DNSKEY 257 is the key-signing-key, which was sent to the registry, while DNSKEY 256 is the zone-signing key. Dig +trace to see the DS records at the .com registry - they host two different digests for the same key tag/id (35356):

dig comcast.com dnskey +multiline +dnssec +trace

You'll often notice zones with multiple keys - you must support more than one key at a time to enable key rotation. E.g. You, as an authoritative server operator, may wish to rotate your zone-signing key fairly often, while you may wish to rotate the key-signing-key once per year. Each registry decides the expiration of the key or digest they are storing.

* = Not all registrars support DNSSEC; once you sign your domain you cannot transfer the domain to a non-DNSSEC enabled registrar. Either you have to un-sign it or transfer it somewhere else.

There is no certificate authority involved, as the DNS hierarchy contains the signature chain, from the root servers, to each TLD, to each domain. One proposed use of DNSSEC is to publish an SSL certificate public key -- then no Certificate Authorities are required! A browser can use the DNSSEC validated response to match the public key (or more likely, fingerprint) to the web server it is connecting with. You can already use DNS to publish SSH key fingerprints, now you can sign that record for even more trust.

Also, perhaps the reason that Linux does not support file-system compression on the fly is because it's a horrid idea, and should never actually be used?

Ah, the "Terrible idea" objection.

This is a common objection to implementing ideas on Linux - so common, in fact, that it's successfully held Linux back for at least ten years.

Multi-master LDAP replication? Terrible idea. Remained terrible for several years after literally every commercial LDAP server on the planet supported multi-master replication, only became non-harmful when OpenLDAP started to support it in version 2.4.

Active Directory support? Such a terrible idea that it's held Samba development back by at least five years. Even now, where Windows Vista deprecates NT4-style policies and 7 deprecates NT 4 domain support altogether (which is about all you get from Samba 3); Samba 4 is considered alpha software.

Some sort of centralised work-together system that integrates email, address book, calendars, task-list? Terrible idea. So much so that Exchange (despite being way too complicated for its own good) is still an extremely popular email solution and the closest you can get to a viable F/OSS alternative either requires your users to completely re-think how they collaborate (yuck) or buy the commercial version simply because the free version lacks vital features.

Free clue to all naysayers who work on F/OSS projects: If you spent as long trying to think of ways to make something work as you do thinking of objections to existing implementations and explaining how you're right and everyone else is wrong, you wouldn't be ten years behind the times.

The most recognized standards are those you need to pay for.

Except for the ones that aren't those you need to pay for and the ones that used to be those you need to pay for, but aren't any more.

I'd recommend RFC1149. It's slow and a lot less reliable than what we're used to, but less susceptible to having cables cut, ISPs shut down or routers powered off.

DynDNS, they have maintained their lead only via a proprietary interface and a market lead.

Dyn has submitted their HTTP update API as an IETF draft:

http://tools.ietf.org/id/draft-jennings-app-dns-update-02.txt

So it's not proprietary (limited to or owned by them). You might call it non-standard, but if that draft was accepted it would be on the IETF standards track.

Also, Dyn *does* offer DNS UPDATE support, but only for paying customers:

http://dyn.com/support/clients/dynamic-dns-updates-via-tsig/

RFC 1591 states.

Each of the generic TLDs was created for a general category of
      organizations. The country code domains (for example, FR, NL, KR,
      US) are each organized by an administrator for that country. These
      administrators may further delegate the management of portions of the
      naming tree. These administrators are performing a public service on
      behalf of the Internet community. Descriptions of the generic
      domains and the US country domain follow.

      Of these generic domains, five are international in nature, and two
      are restricted to use by entities in the United States.

      World Wide Generic Domains:

      COM - This domain is intended for commercial entities, that is
                  companies. This domain has grown very large and there is
                  concern about the administrative load and system performance if
                  the current growth pattern is continued. Consideration is
                  being taken to subdivide the COM domain and only allow future
                  commercial registrations in the subdomains.

I won't post the entire text here but here's a link: http://tools.ietf.org/html/rfc1591

.com is not the domain you are looking for. .com means commercial, the US domain is .us. (Central registrar might be in the US right now, but .com TLD does by no means belong to USA).

You keep saying this, but that doesn't make it true. RFC1480

For that http://tools.ietf.org/html/rfc970 : Not every /.'er has things like that to their credit/name as you do, hence my subject-line.

(For my part here, it sounds like those buffers need a form of tunable/parameterizable aging system to do more than a FIFO queue/buffer is doing currently).

* Lastly: I recall seeing you mentioned on this before here in the past, & iirc, I said the same thing pretty much in response!

APK

P.S.=> Anyhow/anyways: I try to give credit where it's due, & thus, I have to give folks like yourself some respect, in that your "type" actually gets out there & does things that help "improve the human condition" (yes, even in telecommunications)...

... apk

RFC 1591:

Each of the generic TLDs was created for a general category of
organizations. The country code domains (for example, FR, NL, KR,
US) are each organized by an administrator for that country. These
administrators may further delegate the management of portions of the
naming tree. These administrators are performing a public service on
behalf of the Internet community. Descriptions of the generic
domains and the US country domain follow.

Of these generic domains, five are international in nature, and two
are restricted to use by entities in the United States.

World Wide Generic Domains:

COM - This domain is intended for commercial entities, that is
companies. This domain has grown very large and there is
concern about the administrative load and system performance if
the current growth pattern is continued. Consideration is
being taken to subdivide the COM domain and only allow future
commercial registrations in the subdomains.

EDU - This domain was originally intended for all educational
institutions. Many Universities, colleges, schools,
educational service organizations, and educational consortia
have registered here. More recently a decision has been taken
to limit further registrations to 4 year colleges and
universities. Schools and 2-year colleges will be registered
in the country domains (see US Domain, especially K12 and CC,
below).

NET - This domain is intended to hold only the computers of network
providers, that is the NIC and NOC computers, the
administrative computers, and the network node computers. The
customers of the network provider would have domain names of
their own (not in the NET TLD).

ORG - This domain is intended as the miscellaneous TLD for
organizations that didn't fit anywhere else. Some non-
government organizations may fit here.

INT - This domain is for organizations established by international
treaties, or international databases.

United States Only Generic Domains:

GOV - This domain was originally intended for any kind of government
office or agency. More recently a decision was taken to
register only agencies of the US Federal government in this

That's a pretty simplified way of putting it, but basically correct. Major equipment vendors have been slow to adopt more advanced queuing strategies (Stochastic Fair Queuing integrated with some of the more advanced flavors of early discard.)

Right. The problem is not big buffers, per se. It's big dumb FIFO queues. There's nothing wrong with one big flow, like a file transfer, having a long latency, provided that other flows with less data in flight aren't stuck behind it. That's what "fair queuing" is all about. Each flow has its own queue, and the queues are serviced in a round-robin fashion. (With stochastic fair queuing, some hashing is done to eliminate some of the bookkeeping on flows, but the effect is roughly the same.)

I figured this out in the early 1980s (see RFC 970) and by the late 1990s, it was an established technology. We shouldn't be having this problem at this late date.

I wonder how much of the trouble comes from devices that are doing TCP-level processing in the middle of the network. Stateful firewalls and ISP ad-insertion engines can introduce substantial latency.

If you want to test for bad behavior, try running two flows, one that never has more than one packet outstanding, and one that just does a big file-transfer like operation like a download. If the latency of the low-traffic flow goes up to the same as that of the bulk flow, there's a big dumb buffer in the middle. If the packet loss rate of the low-traffic flow goes up, there's a small dumb buffer in the middle.

cracker
A cracker is an individual who attempts to access computer systems without authorization. These individuals are often malicious, as opposed to hackers, and have many means at their disposal for breaking into a system...

hacker
A person who delights in having an intimate understanding of the internal workings of a system, computers and computer networks in particular. The term is often misused in a pejorative context, where "cracker" would be the correct term.

The high precision timestamps in Rsyslog, specified in RFC5424 are not epoch seconds. They look like 2011-12-02T04:31:39.171878-08:00 and yes that's microseconds. High precision is essential for multi-source, high volume collection and analysis. It allows you to see the actual order of events when they're coming in from multiple hosts like a large pool of webservers. But hey, if near enough is good enough for you...

Building on top of DNSSEC leaves you maximally as secure as DNSSEC itself. The IETF document you reference in your paper, "Threat Analysis of the Domain Name System", lists among several weaknesses:

Like DNS itself, DNSSEC's trust model is almost totally hierarchical. While DNSSEC does allow resolvers to have special additional knowledge of public keys beyond those for the root, in the general case the root key is the one that matters. Thus any compromise in any of the zones between the root and a particular target name can damage DNSSEC's ability to protect the integrity of data owned by that target name. This is not a change, since insecure DNS has the same model.

In any SSL+DNSSEC paradigm you are trusting:

• the root (ICANN)
• the TLDs (e.g. Verisign)
• the registratrs

Which is very concerning, is it not?

What about ICANN's not-legally-authorized seizure of domains? What about Verisign's domain slamming or DNS hijacking (breaking NXDOMAIN) or their own domain seizures? What about how registrars are often as sketchy as CAs and not as vetted?

Please can we move away from DNSSEC or any other overly centralized and rigid (i.e. choiceless) system as a foundation for our security?

That's still a lot faster than a pigeon!

Using a .xxx TLD makes it that much easier to identify and filter porn if you don't want to see it.

RFC 3675 disagrees with you.

Of course, that RFC is just somebody's opinion on the matter. It's hardly the last word.

And really, the title is ".sex Considered Dangerous" -- not "A mandatory *.sex (or *.xxx) domain will not make it that much easier to identify and filter porn if you don't want to see it".

If all porn was forced to be on *.xxx domains by law and was not directly reachable via any other DNS tlds, then it certainly would make it that much easier to identify (though there's the risk of false positives) and filter porn if you didn't want to see it. This doesn't mean it's a good idea, but it *would* make this filtering easier.

(Of course, there's some big ifs in there too, I realize that.)

Using a .xxx TLD makes it that much easier to identify and filter porn if you don't want to see it.

RFC 3675 disagrees with you.

What is your source for your statement?

According to wikipedia http://en.wikipedia.org/wiki/.com, .com is intended for "Commercial entities (worldwide)".

RFC 920 make no reference to .com beeing used by us entities. Instead a domain .us is intend for that:
http://tools.ietf.org/html/rfc920#page-2