What is the sense of telnet on 53 port?
Kankossa
Hello,
I'm installating a DNS server. Can I use telnet on port 53 from any
machine is considered as a test of DNS? Or it has no sense since DNS
is UDP protocole while
telnet is a TCP protocole? Then if I connected to to the server, what
this means?
More preciously my troubles are:
- Is "telnet IP_AD 53" where IP_AD is the IP addresse of my DNS
machine means that my DNS Works?
- Is "telnet FQDN 53" where FQDN my be any domaine on the net prove
that my DNS works fine?
PS: I know that nslookup exist and my be more appropriated, but I want
to know about the above questions.
Thank you
Bill Manning
%
%
% Hello,
%
% I'm installating a DNS server. Can I use telnet on port 53 from any
% machine is considered as a test of DNS? Or it has no sense since DNS
% is UDP protocole while
% telnet is a TCP protocole? Then if I connected to to the server, what
% this means?
% More preciously my troubles are:
% - Is "telnet IP_AD 53" where IP_AD is the IP addresse of my DNS
% machine means that my DNS Works?
% - Is "telnet FQDN 53" where FQDN my be any domaine on the net prove
% that my DNS works fine?
Telnet to port 53, looking for DNS make no sense.
DNS does not communicate with ASCII strings. DNS
uses both TCP and UDP.
% PS: I know that nslookup exist and my be more appropriated, but I want
% to know about the above questions.
Avoid NSLOOKUP if you can. Find and use a copy of DIG.
%
% Thank you
%
--
--bill
Brad Knowles
At 11:25 AM -0700 7/26/01, Kankossa wrote:
> I'm installating a DNS server. Can I use telnet on port 53 from any
> machine is considered as a test of DNS?
Nope.
> Or it has no sense since DNS
> is UDP protocole while telnet is a TCP protocole?
No, DNS packets can be transmitted over either TCP or UDP.
However, it is not a plaintext format, but a binary format.
Therefore, you cannot use a telnet plaintext application to
communicate directly on port 53. Instead, you need to use DNS query
and debugging utilities, like dig, doc, dnswalk, etc....
> Then if I connected
> to to the server, what this means?
It accepted a TCP connection, but then didn't know what to do
with a client that spoke a different protocol.
> More preciously my troubles are:
> - Is "telnet IP_AD 53" where IP_AD is the IP addresse of my DNS
> machine means that my DNS Works?
Nope.
> - Is "telnet FQDN 53" where FQDN my be any domaine on the net prove
> that my DNS works fine?
Nope.
> PS: I know that nslookup exist and my be more appropriated, but I want
> to know about the above questions.
IMO, nslookup is evil. It should be avoided unless you have
specific reason to know you want to use it. Use dig instead.
--
Brad Knowles, <brad.k...@skynet.be>
H4sICIFgXzsCA2RtYS1zaWcAPVHLbsMwDDvXX0H0kkvbfxiwVw8FCmzAzqqj1F4dy7CdBfn7
Kc6wmyGRFEnvvxiWQoCvqI7RSWTcfGXQNqCUAnfIU+AT8OZ/GCNjRVlH0bKpguJkxiITZqes
MxwpSucyDJzXxQEUe/ihgXqJXUXwD9ajB6NHonLmNrUSK9nacHQnH097szO74xFXqtlbT3il
wMsBz5cnfCR5cEmci0Rj9u/jqBbPeES1I4PeFBXPUIT1XDSOuutFXylzrQvGyboWstCoQZyP
dxX4dLx0eauFe1x9puhoi0Ao1omEJo+BZ6XLVNaVpWiKekxN0VK2VMpmAy+Bk7ZV4SO+p1L/
uErNRS/qH2iFU+iNOtbcmVt9N16lfF7tLv9FXNj8AiyNcOi1AQAA
Kevin Darcy
Brad Knowles wrote:
> At 11:25 AM -0700 7/26/01, Kankossa wrote:
> > PS: I know that nslookup exist and my be more appropriated, but I want
> > to know about the above questions.
>
> IMO, nslookup is evil. It should be avoided unless you have
> specific reason to know you want to use it.
Indeed. As a DNS troubleshooting tool, nslookup is only barely better than
telnetting to port 53 (Does that qualify as me finally saying something
positive about nslookup? :-)
- Kevin
Kankossa
ki...@my-deja.com (Kankossa) wrote in message news:<9jpra9$q...@pub3.rc.vix.com>...
Thank you all for replies.
Now I have the following questions:
- I know that telnet, ftp, smtp, http both must read /etc/resolv.conf.
So, if I do: telnet www.redhat.com 80 and I reach it, this implicitely
constituous a test that my DNS works (both gethostbyname() and
gethostbyaddr() have been performed).
- Can Bind be forced to use only TCP to communicates?
-In recent versions of Bind where DNSSEC and IXFR, DDNS, Notify,
EDNSO protocoles are included, is this means that TCP must be used
instead of UDP even for a simples request of addresses resolutions?
Thanks
Michael Kjorling
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Jul 27 2001 01:24 -0700, Kankossa wrote:
> Thank you all for replies.
>
> Now I have the following questions:
>
> - I know that telnet, ftp, smtp, http both must read /etc/resolv.conf.
Do they? smtp and http are _protocols_, not _applications_, and I
assume that you refer to the protocols telnet and ftp as well.
(Actually, in that case, we should be talking about FTP, SMTP and
HTTP.) There is nothing in the RFCs AFAIK saying that they have to
read a specific file or even know how name resolution works. Telnet
predates DNS, if I am not misinformed.
> So, if I do: telnet www.redhat.com 80 and I reach it, this implicitely
> constituous a test that my DNS works (both gethostbyname() and
> gethostbyaddr() have been performed).
No - it means that you can successfully look up the name
www.redhat.com and reach that one particular IP. It doesn't prove that
"your DNS works" - the way to check that your DNS works would be more
like `dig @localhost www.redhat.com. a +norec' and examining the
output of that.
And why would gethostbyaddr() be called? I am not too much into BSD
sockets programming, but that doesn't seem to make sense to me. Most
telnets say something like:
$ telnet myhost.corporation.com
Trying 123.45.67.89...
Connected to myhost.corporation.com
...
I don't recall ever seeing the "connected to" host and the one on the
command line (or at least what is being passed to telnet) differ, even
when the given address and the PTR record for the IP are different.
> - Can Bind be forced to use only TCP to communicates?
With open source software, anything is possible. However, if you
remove UDP support from the BIND code base, you will severly limit
your ability to talk to clients that still expect UDP to be there. The
reason UDP is used instead of TCP is because the latter has a
three-way handshake (SYN, SYN/ACK, ACK) as well as a long shutdown
process in addition to the actual communications - which in DNS is
often limited to one packet in either direction. UDP only sends the
actual data.
> -In recent versions of Bind where DNSSEC and IXFR, DDNS, Notify,
> EDNSO protocoles are included, is this means that TCP must be used
> instead of UDP even for a simples request of addresses resolutions?
No. TCP is used as a failover mechanism in case the answer is too long
to fit into the UDP packet (is it 512 bytes of payload?)
As long as the response can be compressed under 512 bytes, TCP is not
necessary. However, TCP is always used for zone transfers - at least
AXFR. I don't know about IXFR but I assume it is the same there.
Notify has, AFAIK, never been TCP-based. It is simply another type of
DNS query, just like SOA, NS, ANY, A, ... you get the point. DNSSEC is
merely a few more records in addition to that it specifies how those
should be created (by signing a zone), and verified to confirm
authenticity.
Unfortunately I don't have any pointers to the RFCs, but I assume that
RFC 1035 would be good reading in this case. It answers a lot of
questions.
Michael Kjörling
- --
Michael Kjörling - mic...@kjorling.com - PGP: 8A70E33E
Manager Wolf.COM -- Programmer -- Network Administrator
"We must be the change we wish to see" (Mahatma Gandhi)
^..^ Support the wolves in Norway -- go to ^..^
\/ http://home.no.net/ulvelist/protest_int.htm \/
***** Please only send me emails which concern me *****
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE7YYtnKqN7/Ypw4z4RAqWKAKDyn0BlrdOPLWmT3jGFJmz7ciF7OQCg9l6W
G2bnnp1ZkLN/haceDMF7WeA=
=5vp/
-----END PGP SIGNATURE-----
Brad Knowles
At 1:24 AM -0700 7/27/01, Kankossa wrote:
> - I know that telnet, ftp, smtp, http both must read /etc/resolv.conf.
Not really. They just use the resolver library, and the resolver
library reads this file.
> So, if I do: telnet www.redhat.com 80 and I reach it, this implicitely
> constituous a test that my DNS works (both gethostbyname() and
> gethostbyaddr() have been performed).
Again, not necessarily. The resolver library may have been
configured to look in a local /etc/hosts file first, and only proceed
to the DNS if the information can't be found there.
> - Can Bind be forced to use only TCP to communicates?
BIND itself? No. You can force dig to use TCP when doing
queries, as can anyone using the resolver routines, but you can't
force the nameserver to use only TCP.
> -In recent versions of Bind where DNSSEC and IXFR, DDNS, Notify,
> EDNSO protocoles are included, is this means that TCP must be used
> instead of UDP even for a simples request of addresses resolutions?
EDNS0 expands the UDP-based protocol to allow much longer
packets, but is not necessarily a requirement for supporting the
other features. Because of the additional data that would be in the
DNS, this means that you will probably frequently be using TCP to
perform DNS queries, but there is also a chance that some of this
information may fit into a standard 512-byte UDP packet.
Kevin Darcy
ki...@my-deja.com wrote: FQDN my be any domaine on the net prove
> -In recent versions of Bind where DNSSEC and IXFR, DDNS, Notify,
> EDNSO protocoles are included, is this means that TCP must be used
> instead of UDP even for a simples request of addresses resolutions?
DDNS packets aren't really "queries" in the normal sense. The client constructs the
update and sends it to the server. So the client will know ahead of time whether the
data will be too much to fit in a UDP packet or not, and use TCP if necessary.
DDNS responses are basically just confirmations or rejections, so they tend to be
rather small and are unlikely to require TCP.
IXFR is a way of doing zone transfers, and zone transfers traditionally use
TCP anyway, so IXFR can hardly be said to be forcing the use of TCP. If an
IXFR transfer will fit in a UDP packet, then in theory UDP can be used. That's a
choice you never had with AXFR.
NOTIFY packets are small. I can't imagine them ever needing to use TCP.
EDNS0 adds a little to the packet length, true. But EDNS0 also allows clients and
servers to use larger UDP packets too, so it more than "pays its way" as far as
reducing TCP retransmissions.
DNSSEC is the remaining protocol extension you mentioned, and yes, it can increase
packet size considerably. It is hoped that the buffer-size advertisement feature of
EDNS0 will help offset the impact of this somewhat by allowing larger UDP packets.
We'll see.
- Kevin