Re: Can I forward DNS request using TCP?
Chris Buxton
you must...
There is no way to configure BIND to send all queries to a forwarder
over TCP instead of UDP. And the operator of that forwarder probably
wouldn't appreciate it if you could.
If the UDP packets aren't arriving, check all the firewalls in between
(and at both ends). Make sure you're sending the packets to a DNS
server. Verify with the server's operator that this is OK.
Or, alternatively, forward somewhere else. opendns.com's forwarders,
for example.
Chris Buxton
Professional Services
Men & Mice
On Jul 17, 2008, at 6:11 PM, igor wrote:
> I have configured a forward DNS server in Linux, unfortunately it
> seems that the UDP packets are being lost therefore my server is
> giving "service failure" to its clients.
>
> I haven't found a way to make the forward requests go via TCP over the
> forwarders.
>
> Can you please tell me if this is doable or not? Is there a parameter
> on named.conf or named.boot I need to change or do I need to get the
> named source and "hack it".
>
> Any information is greatly appreciated!
>
> IgoR
> Phoenix.
>
Kevin Darcy
> I have configured a forward DNS server in Linux, unfortunately it
> seems that the UDP packets are being lost therefore my server is
> giving "service failure" to its clients.
>
MANY packets? What's your drop percentage?
Are you sure UDP to port 53 isn't completely *blocked* (or possibly
throttled?) somewhere upstream? Are you able to make exactly *the*same*
queries successfully with TCP as fail with UDP?
What source port(s) are you using? If you're locking your source port to
53, then a) that source port may be blocked/throttled by your upstream
provider, and b) even if it isn't, it's really bad to be locked to a
given source port, given the nasty response-forgery exploit that's about
to be disclosed to the public (including the hackers).
It's possible that your upstream provider may be doing you a *favor* by
blocking UDP source port 53, thus forcing you to unlock it and making
you more secure.
Or, maybe they just don't want you hosting your own DNS server on your
"sub-enterprise-class" account with them, and this is their (lazy?
incompetent?) way of preventing you from doing that.
> I haven't found a way to make the forward requests go via TCP over the
> forwarders.
>
> Can you please tell me if this is doable or not? Is there a parameter
> on named.conf or named.boot I need to change
Not doable.
> or do I need to get the
> named source and "hack it".
>
>
I wouldn't recommend it. TCP is a hog, and if you're really getting
TERRIBLE drop rates for your packets, that drop rate is most likely
going to affect TCP as well as UDP, the only real difference being that
in the case of TCP, your network stack will be performing the retries;
with UDP, named itself does the retries. In fact, by forcing TCP you may
exacerbate the problem by putting even *more* traffic on the link (SYN,
SYN-ACK, ACK, FIN, FIN-ACK, etc.), thus possibly saturating it even more.
Question: why are you using forwarding at all? It doesn't usually
provide a benefit.
- Kevin
Dan Mahoney, System Admin
> I suspect forwarding is not the best solution for you, but if you feel
> you must...
>
> There is no way to configure BIND to send all queries to a forwarder
> over TCP instead of UDP. And the operator of that forwarder probably
> wouldn't appreciate it if you could.
>
> If the UDP packets aren't arriving, check all the firewalls in between
> (and at both ends). Make sure you're sending the packets to a DNS
> server. Verify with the server's operator that this is OK.
>
> Or, alternatively, forward somewhere else. opendns.com's forwarders,
> for example.
Chris,
This is off-topic, but related (if that makes sense).
I too have wondered about such a request. Often times, when traveling by
train (commuting to NYC a few years ago) and using a crappy GPRS
connection, I found web-surfing to be almost impossible unless I
prepopulated my hosts file and did some creative proxying. However, for
non-proxyable services, I would use the ip rather than the name for hosts
that I routinely logged into (via SSH, IMAP and AIM) where the actual data
side was low-volume.
I realized that if the OS's DNS was TCP based (with a 60 second connect
time out, and guaranteed retransmissions) it would solve these issues --
assume that I control my own DNS server and know I allow TCP.
However, since the "just use TCP" option's not available in any of the
OSes I've used (but really should be) I realized that a local, caching
bind (which supported a similar option) could also be useful, on some
level.
I.e. the host's FIRST attempt to resolve and connect would fail (since it
would still time out waiting for the OS talking UDP to its local BIND to
do the TCP connection) -- but subsequent ones would work, since BIND could
hand off a very low negative TTL and maintain cache. After that, once it
was in cache, all could be well.
I should note that this is one of the VERY FEW cases where I advocate
overriding TTL's...And also one of the very few cases where I see the
advantage in loading from a cache of pre-populated hosts.
This is very much against a lot of the DNS standards and protocols...but
then, cellular internet is hardly standard.
-Dan
--
"A single death is a tragedy. A million deaths is a statistic."
-Josef Stalin, As quoted on the cover to Savatage's "Dead Winter Dead"
--------Dan Mahoney--------
Techie, Sysadmin, WebGeek
Gushi on efnet/undernet IRC
ICQ: 13735144 AIM: LarpGM
Site: http://www.gushi.org
---------------------------