This is, unfortunately, one of those times where the sheer size of the US of A economy can, through the careful applications of trade sanctions, have dramatic effects on the economys of other countries.
Hence, it is not surprising that if trade sanctions are insinuated, countries may well roll over and go after entities that aren't abiding by US (copyright) law (but are abiding by that country's laws), or alter their (copyright) laws to be more closely conforming with US (copyright) law.
The limiting factor is the amount of time it takes to lock onto a given base station, combined with the size of each base station's coverage. If using your typical home base station with its relatively small coverage, you can (in some cases) run your laptop through the area before it can lock on.
Solution of course is to both up the coverage size per base station, and decrease the time to lock on, both of which are only slightly non-trivial to overcome.
> Implementing in the _root_ DNS servers, with no warning, no RFC, no discussion, and no debate is
> bonkers.
This sort of inaccuracy always gets my heckles up. The change was not made to the _root_ DNS _servers_, or the _root_ DNS _zone_. The _root_ DNS
server operators would collectively have a fit and refuse to serve the zone if they noticed such a change.
The change in question (wildcard label) was made to the Global Top Level Domain _zones_ of.com and.net. These are just two (but extremely popular) of the 15 gTLD
domains referenced in the standard _root_ domain.
Otherwise, you're quite correct; making the change
to two gTLD zones with no warning, no RFC, no discussion and no debate is completely bonkers. Complaining about a lack of warning, discussion or debate in the removal of such is also bonkers.
The premise that the roots operate on is that you want to be able to reply to most things in a single packet, otherwise you incur greter overhead in falling back to TCP. Since the roots only deal with delegations (NS lists), that imposes a limit on the number of nameservers for each TLD, in addition to the number of the root servers.
The next limiting factor is the maximum size of a UDP DNS packet. For various reasons, this is 512 bytes.
Then, you need to have space to repeat the query (up to 255 bytes) as per the DNS protocol. That cuts down on the amount of space available. Fortunately, there is compression used in the packet, such that you can get ~8 nameservers if they're in different domains, and ~13 in a single domain (ref 'root-servers.net' and 'gtld-servers.net'), and all the addresses are 4 bytes (IPv4).
I think that it is a kindness to djb to not use djbdns on any of the root servers. His ego is already large enough; it would simply explode if djbdns ran on a root server.
Seriously, djbdns, as supplied, is not usable on a root server due to security constraints involved in retrieving the root zones.
> The article states: "K will answer either using bind8 or nsd".
Actually, the full quote is:
: During the cut-over period, K will answer either using bind8 or nsd
( There is a load balancer in front of a number of
machines performing the K-root function )
To answer your other question, being:
> How does one go about identifying which software is in use at a DNS server?
There are three methods. One is the defacto which was introduced with BIND4.mumble, by which you could send a TXT query of 'version.bind' to the nameserver, and it may answer with the actual version (depending on how the local administrators set it up - ref BIND documentation
for further details).
Another method is currently going through the IETF process as draft-dnsop-serverid, and consists of sending a similar query for 'version.server'. (ref the draft for further specifics). NSD replies to this method since it is not BIND.
The third method is analysis of how the nameserver replies to queries. Even between BIND versions there are a variety of subtle differences in the packet that you get back.
But, we haven't answered the 'why'. One reason is
if you are tracking obscure protocol bugs from
servers not under your control. Another is purely
for local administration and tracking which
nameserver is doing what.
Slashdot Mirror
Putting Solar Panels on the moon.
Using the moon as our next source of energy (mining/solar/whatever) is most likely going to be impetus behind anyone going to the moon long-term.
But a far cheaper method of doing that is to send a few von-neumann machines up there to build it for us.
which are different from the courts in France.
Instead, try the IIPA, (which the RIAA is a member of), which has requested that the US govt place trade restrictions on certain countries due to copyright infringement issues.
This is, unfortunately, one of those times where the sheer size of the US of A economy can, through the careful applications of trade sanctions, have dramatic effects on the economys of other countries.
Hence, it is not surprising that if trade sanctions are insinuated, countries may well roll over and go after entities that aren't abiding by US (copyright) law (but are abiding by that country's laws), or alter their (copyright) laws to be more closely conforming with US (copyright) law.
Now if we could just stop the crazy tyrants from collecting more oil fields, we'd be happy.
Solution of course is to both up the coverage size per base station, and decrease the time to lock on, both of which are only slightly non-trivial to overcome.
But they'd make good pockets for playing galactic snooker, assuming you had a few thousand years to burn.
> Implementing in the _root_ DNS servers, with no warning, no RFC, no discussion, and no debate is
> bonkers.
This sort of inaccuracy always gets my heckles up. The change was not made to the _root_ DNS _servers_, or the _root_ DNS _zone_. The _root_ DNS server operators would collectively have a fit and refuse to serve the zone if they noticed such a change.
The change in question (wildcard label) was made to the Global Top Level Domain _zones_ of .com and .net. These are just two (but extremely popular) of the 15 gTLD
domains referenced in the standard _root_ domain.
Otherwise, you're quite correct; making the change to two gTLD zones with no warning, no RFC, no discussion and no debate is completely bonkers. Complaining about a lack of warning, discussion or debate in the removal of such is also bonkers.
The next limiting factor is the maximum size of a UDP DNS packet. For various reasons, this is 512 bytes.
Then, you need to have space to repeat the query (up to 255 bytes) as per the DNS protocol. That cuts down on the amount of space available. Fortunately, there is compression used in the packet, such that you can get ~8 nameservers if they're in different domains, and ~13 in a single domain (ref 'root-servers.net' and 'gtld-servers.net'), and all the addresses are 4 bytes (IPv4).
Seriously, djbdns, as supplied, is not usable on a root server due to security constraints involved in retrieving the root zones.
a) More machines is good (the query load is not insignificant).
and b) Limitation in the packet size; you can only fit in 13 names if they're all in the same zone (root-servers.net).
Now, the ideal placement of those 13 servers, thats a completely different story.
Actually, the full quote is:
: During the cut-over period, K will answer either using bind8 or nsd
( There is a load balancer in front of a number of machines performing the K-root function )
To answer your other question, being:
> How does one go about identifying which software is in use at a DNS server?
There are three methods. One is the defacto which was introduced with BIND4.mumble, by which you could send a TXT query of 'version.bind' to the nameserver, and it may answer with the actual version (depending on how the local administrators set it up - ref BIND documentation for further details).
Another method is currently going through the IETF process as draft-dnsop-serverid, and consists of sending a similar query for 'version.server'. (ref the draft for further specifics). NSD replies to this method since it is not BIND.
The third method is analysis of how the nameserver replies to queries. Even between BIND versions there are a variety of subtle differences in the packet that you get back.
But, we haven't answered the 'why'. One reason is if you are tracking obscure protocol bugs from servers not under your control. Another is purely for local administration and tracking which nameserver is doing what.