NIC - why should they care about TCP access to port 53???
Christopher Davis
OH> == Ove Hansen <o...@zombie.neu.sgi.com>
OH> The NIC is refusing to register a new domain because they can't open
OH> a *TCP* connection to port 53 on the machines which are the primary
OH> and secondary nameservers.
Yet they won't clean up old domains that are broken (lame delegation on
one listed server, the other one is "behind a firewall" and won't respond
at all), they won't require you to have topologically diverse nameservers,
they don't check to see if you have UDP checksums on, etc. How useful of
them (NOT).
OH> I thought DNS TCP connections were mainly for zone transfers (and
OH> port 53 *is* open for TCP to the secondary!), while DNS queries
OH> should be done using UDP - is there something here I've
OH> misunderstood???
Well, RFC 1123 lists support of TCP as well as UDP as a "SHOULD":
DNS servers MUST be able to service UDP queries and SHOULD
be able to service TCP queries. A name server MAY limit the
resources it devotes to TCP queries, but it SHOULD NOT
refuse to service a TCP query just because it would have
succeeded with UDP.
OH> From a security point of view it probably doesn't make any major
OH> difference, if someone *really* wants the full DNS database they can
OH> get it by being a little persistent, however why open up ports which
OH> might as well stay closed?
You can shut off zone transfers in BIND without having to turn off TCP
access. This is probably a good idea if you're that concerned. There are
good reasons to use TCP for queries, it's just not often necessary.
Personally, I'd unblock the port and set up BIND to refuse zone transfers
from the Great Unwashed. It's not as if SATAN or similar scanners are
going to bother with your DNS data anyway; they'll just hit every IP
address in your network range.
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Processed by Mailcrypt 3.3, an Emacs/PGP interface
iQBVAwUBMJlEsHc8OGsDgp+JAQHN9gH8D1YOynWdeEOEcInfUnr4VJVj2P+E228i
hNZfw88Ie9zRWjfQLI8Xs2IzxHIUbHrhWws9FZXYwZLkAZMu6tlKhg==
=0GTB
-----END PGP SIGNATURE-----
--
Christopher Davis * <c...@kei.com> * <URL: http://www.kei.com/homepages/ckd/ >
- PGP 1024/66CB73DD - |"We're so glad that the network dog dances, we don't
46 8E FD F5 12 8E 13 4C | realize that it's rabid," Mr. Cheswick said of the
2C 8A 92 A3 B0 D5 2A 5E | programming quality of many software packages.
Ove Hansen
The NIC is refusing to register a new domain because they can't open
a *TCP* connection to port 53 on the machines which are the primary and
secondary nameservers. However *UDP* connections to port 53 can be made
from anywhere so the outside world should be able to do as many DNS
queries as they want to. I thought DNS TCP connections were mainly for
zone transfers (and port 53 *is* open for TCP to the secondary!),
while DNS queries should be done using UDP - is there something here
I've misunderstood???
(Right - ask the *NIC* why - we have - the b*****ds refuse to explain
and just say 'read rfc1035' which seems to support what we thought
although I have to admit it doesn't say DNS queries *have* to be UDP
packets, only "it's recommended"...!)
From a security point of view it probably doesn't make any major
difference, if someone *really* wants the full DNS database they can
get it by being a little persistent, however why open up ports which
might as well stay closed?
Thanks in advance for any feedback,
--
Ove Hansen - e-mail: o...@neu.sgi.com
Barry Margolin
Ove Hansen <o...@zombie.neu.sgi.com> wrote:
>I thought DNS TCP connections were mainly for
>zone transfers (and port 53 *is* open for TCP to the secondary!),
>while DNS queries should be done using UDP - is there something here
>I've misunderstood???
I think the InterNIC is being overly restrictive. Here is what RFC 1123
says:
DNS servers MUST be able to service UDP queries and SHOULD
be able to service TCP queries. A name server MAY limit the
resources it devotes to TCP queries, but it SHOULD NOT
refuse to service a TCP query just because it would have
succeeded with UDP.
Note that it says that you SHOULD handle TCP queries, not that you MUST.
The paragraph that precedes this says that DNS clients should use a TCP
query if the response to a UDP query is truncated.
--
Barry Margolin
BBN PlaNET Corporation, Cambridge, MA
bar...@bbnplanet.com
Phone (617) 873-3126 - Fax (617) 873-6351
Mark Andrews
>Hello,
>
>The NIC is refusing to register a new domain because they can't open
>a *TCP* connection to port 53 on the machines which are the primary and
>secondary nameservers.
Quite correct in my opinion.
>However *UDP* connections to port 53 can be made
>from anywhere so the outside world should be able to do as many DNS
>queries as they want to. I thought DNS TCP connections were mainly for
>zone transfers (and port 53 *is* open for TCP to the secondary!),
>while DNS queries should be done using UDP - is there something here
>I've misunderstood???
No TCP is there for dealing with large answers.
There are real life examples where you can't fit the answers
into a UDP packet let alone the authority and the additional
data sections.
>
>(Right - ask the *NIC* why - we have - the b*****ds refuse to explain
>and just say 'read rfc1035' which seems to support what we thought
>although I have to admit it doesn't say DNS queries *have* to be UDP
>packets, only "it's recommended"...!)
No it is recomended that you try UDP before TCP because UDP is a
light weight protocol that doesn't tie up resourse in the
server. TCP has state which needs to be maintained, a multi
packet exchange before and after the data is transfered.
TCP is NOT optional for a nameserver.
>
>From a security point of view it probably doesn't make any major
>difference, if someone *really* wants the full DNS database they can
>get it by being a little persistent, however why open up ports which
>might as well stay closed?
Modern nameservers can block just AXFR request you don't need to
block the tcp port.
>
>Thanks in advance for any feedback,
>--
>Ove Hansen - e-mail: o...@neu.sgi.com
Mark
Randal L. Schwartz
Barry> I think the InterNIC is being overly restrictive. Here is what RFC 1123
Barry> says:
Barry> DNS servers MUST be able to service UDP queries and SHOULD
Barry> be able to service TCP queries. A name server MAY limit the
Barry> resources it devotes to TCP queries, but it SHOULD NOT
Barry> refuse to service a TCP query just because it would have
Barry> succeeded with UDP.
Barry> Note that it says that you SHOULD handle TCP queries, not that you MUST.
Barry> The paragraph that precedes this says that DNS clients should use a TCP
Barry> query if the response to a UDP query is truncated.
But the second sentence seems to undo the first, at least for this
case. I can see how the NIC reads that second sentence as "hey, we
need to TCP-probe your host to verify RFC1123 compliance."
And geez guys, if you let UDP 53 through, why *not* let TCP 53 through?
Is there an attack I'm not aware of that could take advantage of this,
or are you being overly paranoid?
Just another DNS-kinda-guy,
--
Name: Randal L. Schwartz / Stonehenge Consulting Services (503)777-0095
Keywords: Perl training, UNIX[tm] consulting, video production, skiing, flying
Email: <mer...@stonehenge.com> Snail: (Call) PGP-Key: (finger mer...@ora.com)
Web: <A HREF="http://www.teleport.com/~merlyn/">My Home Page!</A>
Quote: "I'm telling you, if I could have five lines in my .sig, I would!" -- me
Richard P. Bainter
Randal L. Schwartz <mer...@stonehenge.com> wrote:
>And geez guys, if you let UDP 53 through, why *not* let TCP 53 through?
>Is there an attack I'm not aware of that could take advantage of this,
>or are you being overly paranoid?
Yes. Exactly what firewalls *should* be.
IMHO, there are 3 methods of firewalls.
1) None.
2) Deny these things.
3) Allow these things.
Why allow things you don't *have* to if you are in method 3?
Ciao,
--
Richard Bainter Mundanely | System Analyst - OMG/CSD
Pug Generally | Applied Research Labs - U.Texas
p...@arlut.utexas.edu | p...@eden.com | {any user}@pug.net
Note: The views may not reflect my employers, or even my own for that matter.
Brad Knowles
(Barry Margolin) wrote:
> Note that it says that you SHOULD handle TCP queries, not that you MUST.
> The paragraph that precedes this says that DNS clients should use a TCP
> query if the response to a UDP query is truncated.
I may be mistaken, but I believe that they're using zone-transfers to get
the data, then they check it off-line. Kind of like "doc".
In this case, blocking TCP access to port 53 is definitely going to keep
them from verifying the data. Besides, as we both know, blocking TCP
access to port 53 isn't the right way to do things anyway -- if you want
to restrict zone transfers, BIND has the tools to do that selectively, and
not just blindly block all TCP port 53 connections.
--
Brad Knowles, comp.mail.sendmail FAQ Maintainer br...@his.com
The comp.mail.sendmail FAQ is located at:
<ftp://rtfm.mit.edu/pub/usenet/news.answers/mail/sendmail-faq>
Brad Knowles
> Because between the range of things defined as "necessary to operate at
> all" and the range of things defined as "dangerous if permitted" lies a range
> of things which amounts to "not dangerous but damages performance if
> disabled." TCP connections to the DNS server are in this third range, and
> apparently the NIC has decided that as far as they're concerned they
belong in
> the first.
As I noted before, I believe they're using a domain checking program
similar to "doc" to verify the domain before registering it. Given this,
there are certain things you have to do to allow them to check your zone.
You can either allow them or not, but doing so directly affects your
ability to register your zone, and there's absolutely nothing in the RFCs
that says that a registration authority can't require you to implement a
"SHOULD", in order for them to be able to do their job.
Bill Fenner
Perhaps you should tell them to read RFC1123, specifically section 6.1.3.2.
It says that servers MUST support UDP and SHOULD support TCP. The NIC has
no right attempting to enforce a SHOULD.
Bill
Marten Terpstra
In article <DHGBB...@news.nsw.CSIRO.AU>,
Mark Andrews <ma...@syd.dms.CSIRO.AU> wrote:
> TCP is NOT optional for a nameserver.
Where does it say this?
RFC1123 says that a name server MUST support UDP and SHOULD support TCP.
If a nameserver is never going to send answers which UDP will truncate,
then why does it need to support TCP?
Bill
Zone transfers to secondaries? Also, when doing recursive lookups, how
can you make sure your nameserver never sends answers that UDP would
truncate? A nameserver does not only reply to information it is
authoritative for....
-Marten
--
--------------------------------------------------------------------------
Marten Terpstra mar...@BayNetworks.com
Bay Networks, Inc Engineering
Billerica, MA
--------------------------------------------------------------------------
Colin Campbell
: In article <47bhk8$n...@tools.bbnplanet.com>, bar...@tools.bbnplanet.com
: (Barry Margolin) wrote:
: > Note that it says that you SHOULD handle TCP queries, not that you MUST.
: > The paragraph that precedes this says that DNS clients should use a TCP
: > query if the response to a UDP query is truncated.
: I may be mistaken, but I believe that they're using zone-transfers to get
: the data, then they check it off-line. Kind of like "doc".
: In this case, blocking TCP access to port 53 is definitely going to keep
: them from verifying the data. Besides, as we both know, blocking TCP
: access to port 53 isn't the right way to do things anyway -- if you want
: to restrict zone transfers, BIND has the tools to do that selectively, and
: not just blindly block all TCP port 53 connections.
As stated here, Internic want acces only to verify the servers are setup
correctly. That is what happens here in Oz (actaully it is automated -
fill in the details on the web page and they come and check it automatically).
Why don't you open it up for them, get the systems checked out, get delegated
and then close it up again. That's the way I do it.
Colin
Richard P. Bainter
Marten Terpstra <mar...@BayNetworks.com> wrote:
>Zone transfers to secondaries?
In standard firewall configurations, you can allow it to go to the
secondaries, but not to everyone else. Next reason.
>Also, when doing recursive lookups, how
>can you make sure your nameserver never sends answers that UDP would
>truncate?
In general, I would prefer that my nameserver not be used by users outside
of my zone. Yes, I think answering things I am autoritative for is
necessary, but no one should be using me for their nameserver unless they
are at my site. Next.
Richard P. Bainter
William Herrin <her...@why.com> wrote:
> Because between the range of things defined as "necessary to operate at
>all" and the range of things defined as "dangerous if permitted" lies a range
>of things which amounts to "not dangerous but damages performance if
>disabled." TCP connections to the DNS server are in this third range, and
>apparently the NIC has decided that as far as they're concerned they belong in
>the first.
As I understand it, which might be incorrectly, that you only need TCP
connections for large answers and for zone transfers. Unless the NIC is
my secondary, they don't need zone transfers. As for large answers, if
I don't have any, I only need port 53 to be coming in and not going out.
'Cause I for one would prefer that my internal users use internal
nameservers, and external users use external nameservers.
Bill Fenner
Bill Fenner <fen...@parc.xerox.com> wrote:
>Perhaps you should tell them to read RFC1123, specifically section 6.1.3.2.
>It says that servers MUST support UDP and SHOULD support TCP. The NIC has
>no right attempting to enforce a SHOULD.
Let me expand a little on this, as I've gotten several emails from
people who didn't get my full meaning. (Most of them claimed to be
email copies of netnews posts, but I waited a couple of days and the
posts never showed up.)
The NIC has every right to make up their own rules. However, when they
enforce their own rules, they should say so, not just point at an RFC
that doesn't say anything about whether or not TCP is required. They
should say "Our policy is that a name server for a new domain must
accept TCP connections, because
a) we want to do a zone transfer
b) we want to make sure that you don't ever send any truncated answers
c) we don't really understand all the issues"; otherwise, people who
read and understand the RFC's might be tempted to block TCP connections
at the firewall.
Bill
Bill Fenner
>
>Zone transfers to secondaries? Also, when doing recursive lookups, how
>can you make sure your nameserver never sends answers that UDP would
>truncate?
The situation under discussion was a name server behind a firewall that
blocked TCP. Presumably, the secondaries would be explicitly listed
in the firewall access list.
>A nameserver does not only reply to information it is
>authoritative for....
Why would someone outside the firewall try to query the server inside
the firewall for information for which it is not authoritative?
Bill
Marten Terpstra
>A nameserver does not only reply to information it is
>authoritative for....
Why would someone outside the firewall try to query the server inside
the firewall for information for which it is not authoritative?
What I meant was that if someone inside your firewall asks this
nameserver a query for which the nameserver has to go to the outside
world to get an answer, you cannot guarentee that that answer will fit
in a UDP packet. Ie, that nameserver will receive truncated info with
no possibility to get the complete answer.
Geert Jan de Groot
>The NIC has every right to make up their own rules. However, when they
>enforce their own rules, they should say so, not just point at an RFC
>that doesn't say anything about whether or not TCP is required. They
>should say "Our policy is that a name server for a new domain must
>accept TCP connections, because
>a) we want to do a zone transfer
>b) we want to make sure that you don't ever send any truncated answers
>c) we don't really understand all the issues"; otherwise, people who
>read and understand the RFC's might be tempted to block TCP connections
>at the firewall.
As administrators of 193.in-addr.arpa and 194.in-addr.arpa it is our
experience that as much as 70% of the DNS change requests are defective:
secondaries not set up, unreachable, missing dots, et cetera.
I cannot imagine a reason why this would be any different
at the Inic.
While I can say 'what the heck' and register anyway, the reason
for people to register is to create a setup that works. We found
that people mostly like our checkup.
I think that the Inic checking zones is a good idea and should
be appreciated, not fight against. Many TLD admins have
similar requirements.
If you do DNS 'security' using packet filters, then you will
discover sooner or later that this 'security' does not work.
It has been warned against several times by various organisations
like CERT. If it doesn't give advantages, why do it?
If you're knowingly do not implement a 'should' then you may suffer.
As Bill Fenner knows, the mbone suffers because people people
are not running mrouted 3.5 or higher, while they 'should'.
Geert Jan
Bill Fenner
Marten Terpstra <mar...@BayNetworks.com> wrote:
>What I meant was that if someone inside your firewall asks this
>nameserver a query for which the nameserver has to go to the outside
>world to get an answer, you cannot guarentee that that answer will fit
>in a UDP packet.
But you can allow outgoing TCP connections to let your nameserver
make whatever TCP queries it needs, and still block incoming TCP.
Bill
Marten Terpstra
Bill
I realized this the moment I sent my message... I'll go back minding
my own business again ;-)