Although I do not know what motivated the D-Link developers (to
implement their own DNS server) in this specific case, here is at least
one reason why this could have been implemented:
-wayne wrote:
It appears that the D-Link box implements its own DNS server
A very significant number of queries reaching the root servers are bogus
reverse lookups for RFC1918 addresses. Some of the root server operators
have actually dedicated hardware and resources to this issue. The DNS
infrastructure as a whole could live without that crap.
By having the router/firewall giving its own IP address in the DHCP
scope for the DNS server (instead of the addresses of the
configured/acquired DNS servers) and acting as a DNS proxy / using the
upstream's DNS servers as forwarders, there is a possibility to filter
these bogus RFC1918 reverse lookups going to the roots and answer a
canned PTR directly. Not only this would not send all this crud on the
network, but it also greatly improves traceroutes by not timing out on
the first hop.
that doesn't support TCP.
That kind of hardware sells for $40 without wireless and $100 with, new.
It does not take a rocket scientist to figure out that margins are very
low and that code developers for this kind of box are spread very thin,
no mystery they don't implement something that nobody asks for whether
or not it's in and RFC and has been there for decades.
On the same topic I made the point earlier that implementing only part
of a spec was possible. If you guys don't want to implement the XML part
in the MARID spec, it's your call; the consequences are to be dealt with
when the shit hits the fan if it ever does.
In the case of Wayne's D-Link, I don't think that the fact that D-Link
does not implement DNS over TCP is going to change much of D-Link's
business. Your mileage may vary, but the proof is still in the pudding.
Michel.