<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 01/11/13 03:05, Daniele wrote:<br>
</div>
<blockquote
cite="mid:CAL_2sc0Ey6fz5nfBOuuFNBPDTinu4dRhpeA=fNPNZmRNLUuCFQ@mail.gmail.com"
type="cite">
<div dir="ltr">Port 53 is open, I can also telnet it from another
box in the same network.<br>
Now I think the problem can be on the packets size, because I'm
trying every solution but nothing works.</div>
<div class="gmail_extra">
<br>
<br>
<div class="gmail_quote">2013/1/9 Lyle Giese <span dir="ltr"><<a
moz-do-not-send="true" href="mailto:lyle@lcrcomputer.net"
target="_blank">lyle@lcrcomputer.net</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>
<div class="h5">
<div>On 01/09/13 08:39, Daniele wrote:<br>
</div>
</div>
</div>
<blockquote type="cite">
<div>
<div class="h5">
<div dir="ltr">2013/1/9 Phil Mayers <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:p.mayers@imperial.ac.uk"
target="_blank">p.mayers@imperial.ac.uk</a>></span><br>
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px
#ccc solid;padding-left:1ex">
<div>On 09/01/13 13:53, Daniele wrote:<br>
<blockquote class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex"> This is the
scenario.<br>
<br>
I installed BIND9 via `apt-get` on a
newly installed UBUNTU 12.04,<br>
virtualized on VirtualBox.<br>
The network works properly because if
I indicate a different server from<br>
my own BIND9 (the first line of
'/etc/resolv.conf' is, for example,<br>
`nameserver 8.8.8.8`) the lookups and
any action on the Internet succeed.<br>
<br>
</blockquote>
<br>
</div>
No, this assumption is not valid.</blockquote>
<div><br>
</div>
<div>I meant that I can reach the Internet
and, vice versa, the Internet can reach my
terminal. </div>
</div>
</div>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
</div>
</div>
<div class="im">
<pre>_______________________________________________
Please visit <a moz-do-not-send="true" href="https://lists.isc.org/mailman/listinfo/bind-users" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a> to unsubscribe from this list
bind-users mailing list
<a moz-do-not-send="true" href="mailto:bind-users@lists.isc.org" target="_blank">bind-users@lists.isc.org</a>
<a moz-do-not-send="true" href="https://lists.isc.org/mailman/listinfo/bind-users" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a></pre>
</div>
</blockquote>
Recursive queries that named does for a client are
different than your machine as a dns client reaching out
to Google's recursive service.<br>
<br>
You need to have UDP & TCP port 53 open to your
recursive server(the one running named) first of all. And
if any network element within your network limits the size
of UDP packets, you will have problems with EDNS0 queries.<br>
<br>
On this box running named, try this:<br>
<br>
dig +trace <a moz-do-not-send="true"
href="http://www.msn.com" target="_blank">www.msn.com</a><br>
<br>
dig +trace <a moz-do-not-send="true"
href="http://imperial.ac.uk" target="_blank">imperial.ac.uk</a><br>
<br>
After dig gets a copy of the root servers from the local
named, it will do the same type of queries that a
recursive name server does.<span class="HOEnZb"><font
color="#888888"><br>
<br>
Lyle Giese<br>
LCR Computer Services, Inc.<br>
<br>
</font></span></div>
<br>
</blockquote>
</div>
</div>
</blockquote>
Saying port 53 is open because you can telnet to it from a local
computer is a very limited test.<br>
<br>
1) Telnet only use TCP, UDP is the primary/first communication
channel DNS uses.<br>
<br>
2) The router between this computer and the Internet is not at
fault? You have done no tests to prove that one way or the other.<br>
<br>
Do a couple of dig +trace runs and see what that shows. And try
some any queries to a dnssec enable domain.<br>
<br>
Lyle Giese<br>
LCR Computer Services, Inc.<br>
<br>
</body>
</html>