DNS and TCP
Bill Larson
There is a recent/current thread about TCP packets being used for DNS
communication, and this brought up a question for me.
Can anyone provide any examples of "reasonable" DNS queries that would
overflow a UDP packet and require retransmission using TCP? Specific,
non-contrived, examples would be appreciated.
I fully understand that if too much data is being provided in the DNS
response (>512 bytes) then TCP retransmission will be necessary. My
problem is that at work (which will remain nameless), someone managing
the network has blocked incoming TCP traffic on port 53. This means
that, in general, no one can obtain DNS information using TCP. This
was done under the belief that the only reason for DNS to use TCP is
for zone transfers, and that these must be blocked.
I would like to provide them an example of where their blocking DNS
services using TCP may cause problems. Specific possibilities that I
can imagine would include:
Large numbers of glue records (lots of NS records for the zone)
Large numbers of answers (multiple records, maybe MX records?)
Large answers (a large TXT record)
Contriving such a situation would be trivial, I have done this using
long TXT records, but can anyone provide an example that really is
being used out there?
Thanks,
Bill Larson (wll...@swcp.com)
David Botham
> -----Original Message-----
> From: bind-use...@isc.org [mailto:bind-use...@isc.org] On
> Behalf Of Bill Larson
> Sent: Wednesday, October 02, 2002 11:04 AM
> To: bind-...@isc.org
> Subject: DNS and TCP
>
>
> There is a recent/current thread about TCP packets being used for DNS
> communication, and this brought up a question for me.
>
> Can anyone provide any examples of "reasonable" DNS queries that would
> overflow a UDP packet and require retransmission using TCP? Specific,
> non-contrived, examples would be appreciated.
Zone Transfers Require TCP. Allow it through the FW....
Dave...
Sorkin, David (David)
I've seen large SRV records that require TCP. These are used somehow by W2K and help indicate what services are available on W2K servers. I've administratively disabled zone transfers using ACLs but disabling tcp/53 could give defense in depth. There are 13 root servers because that number of NS records fits in a single udp packet. As far as network security I think that udp presents more problems since it is connectionless and can also be used to probe networks via inbound udp leaks.
--
David Sorkin <dso...@lucent.com>
> -----Original Message-----
> From: Bill Larson [mailto:wll...@swcp.com]
> Sent: Wednesday, October 02, 2002 11:04 AM
> To: bind-...@isc.org
> Subject: DNS and TCP
>
>
>
> There is a recent/current thread about TCP packets being used for DNS
> communication, and this brought up a question for me.
>
> Can anyone provide any examples of "reasonable" DNS queries that would
> overflow a UDP packet and require retransmission using TCP? Specific,
> non-contrived, examples would be appreciated.
>
Angel
Also bear in mind that sendmail requires tcp/53 or at least the SUN
modified version of sendmail requires it.
Angel
sendmail utilises tcp/53 by default still I believe.
Simon Waters
Bill Larson wrote:
>
> I would like to provide them an example of where their blocking DNS
> services using TCP may cause problems. Specific possibilities that I
> can imagine would include:
>
> Large numbers of glue records (lots of NS records for the zone)
>
> Large numbers of answers (multiple records, maybe MX records?)
>
> Large answers (a large TXT record)
>
> Contriving such a situation would be trivial, I have done this using
> long TXT records, but can anyone provide an example that really is
> being used out there?
Few such domains exists, largely because people incorrectly
block TCP, so if it is the answer to a normal query the site
quickly figures out how to get it below 512 bytes, or vanishes.
In DNS troubleshooting you sometimes issues queries that aren't
typical, such as any "any" query rather than "A", "MX" or "PTR".
i.e.
"dig expedia.com any"
Although pragmatically expedia.com doesn't matter, as if you
query the servers directly they will truncate at 512 in the
middle of the additional section.
Also some sites hosting multiple websites on the same IP address
sometimes add all these domain names as PTR records for that IP
address, daft, but it happens. I don't have an example to hand,
I tried a few cases reported in this group before, but they have
all gone (probably says something about the prospects of hosting
companies who are technically clueless).
More to the point if you accidently make your zone return a
query over 512, and block TCP, you'll shoot yourself in the foot
big time, rather than just breaking DNS for those who
incorrectly block TCP themselves. One way makes you look stupid,
with the other at least you can blaim other peoples daft
settings for why their email didn't make it ;-) Similarly if
your companies best customer makes the same "mistake", you'd
still like to get email to them I suspect. So even if it doesn't
matter today, it is setting yourselves up for unnecessary
glitches in the future.
Obviously DNSSEC and IPv6 may eventually change the size of the
typical DNS queries.
Bill Manning
% I would like to provide them an example of where their blocking DNS
% services using TCP may cause problems. Specific possibilities that I
% can imagine would include:
%
% Large numbers of glue records (lots of NS records for the zone)
% Large numbers of answers (multiple records, maybe MX records?)
% Large answers (a large TXT record)
%
% Bill Larson (wll...@swcp.com)
signed zones.
some SRV & NAPTR replies.
things with CERTs.
More interestingly, folks w/ EDNS0 capable systems will
generate replies that trigger UDP fragmentation. The
claim is that things like PIX will drop fragemented UDP
datagrams. Is this true? Will other firewall/IDS systems
do the same?
--bill
Mark_A...@isc.org
PIX drops responses > 512 whether they are fragmented or not.
>
> --bill
>
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark.A...@isc.org