Re: lame-servers: error (FORMERR) resolving [something]
Ok! Thank you all! My router doesn't maintain a DNS cache, so it must be my IPS's fault. The last questions, if it's possible: what happens when my 'named' starts an iterative query? Does it arrive to the real root-server (first of all), or is it processed by some other cache-server on the path? And why 'named' doesn't understand the responses from these cache-servers? 2013/1/18 Mark Andrews ma...@isc.org In message cal_2sc1szstumpmfceuqrf87nqwe+5n30qvguds7q-4g6va...@mail.gmail.com, Daniele writes: These are the outputs. I also attach the file containing them. ; DiG 9.8.1-P1 ns . +norec +noedns @198.41.0.4 ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 25625 ;; flags: qr ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 14 ;; QUESTION SECTION: ;.INNS ;; ANSWER SECTION: .243196INNSl.root-servers.net. .243196INNSg.root-servers.net. .243196INNSk.root-servers.net. .243196INNSa.root-servers.net. .243196INNSe.root-servers.net. .243196INNSd.root-servers.net. .243196INNSc.root-servers.net. .243196INNSi.root-servers.net. .243196INNSf.root-servers.net. .243196INNSh.root-servers.net. .243196INNSj.root-servers.net. .243196INNSb.root-servers.net. .243196INNSm.root-servers.net. ;; ADDITIONAL SECTION: a.root-servers.net.502389INA198.41.0.4 a.root-servers.net.508720IN2001:503:ba3e::2:30 b.root-servers.net.502640INA192.228.79.201 c.root-servers.net.502640INA192.33.4.12 d.root-servers.net.523851INA199.7.91.13 e.root-servers.net.502640INA192.203.230.10 f.root-servers.net.581030INA192.5.5.241 f.root-servers.net.236384IN2001:500:2f::f g.root-servers.net.502640INA192.112.36.4 i.root-servers.net.502640INA192.36.148.17 i.root-servers.net.555890IN2001:7fe::53 j.root-servers.net.537043INA192.58.128.30 j.root-servers.net.236384IN2001:503:c27::2:30 k.root-servers.net.502394INA193.0.14.129 ;; Query time: 62 msec ;; SERVER: 198.41.0.4#53(198.41.0.4) ;; WHEN: Fri Jan 18 15:38:42 2013 ;; MSG SIZE rcvd: 500 Below is what the answer should look like. The TTLs should be these values shown below (6 days and 1000 hours) and aa should be set in the flags and ra should NOT be set in the flags. You have a transparent DNS caching proxy between you and the Internet as a whole. Some routers try to be helpful by maintaining a DNS cache. You need to turn the feature off. Otherwise it is your ISP doing it and you need to get them to stop mucking with your DNS queries. Named issues non-recursive queries and sticking a normal recursive server in the path that pays attention to the setting of rd doesn't result in getting the required answers back. Mark ; DiG 9.10.0pre-alpha ns . +norec +noedns @198.41.0.4 ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 18118 ;; flags: qr aa; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 14 ;; QUESTION SECTION: ;. IN NS ;; ANSWER SECTION: . 518400 IN NS c.root-servers.net. . 518400 IN NS m.root-servers.net. . 518400 IN NS b.root-servers.net. . 518400 IN NS f.root-servers.net. . 518400 IN NS j.root-servers.net. . 518400 IN NS g.root-servers.net. . 518400 IN NS i.root-servers.net. . 518400 IN NS h.root-servers.net. . 518400 IN NS d.root-servers.net. . 518400 IN NS l.root-servers.net. . 518400 IN NS a.root-servers.net. . 518400 IN NS e.root-servers.net. . 518400 IN NS k.root-servers.net. ;; ADDITIONAL SECTION: a.root-servers.net. 360 IN A 198.41.0.4 a.root-servers.net. 360 IN 2001:503:ba3e::2:30 b.root-servers.net. 360 IN A 192.228.79.201 c.root-servers.net. 360 IN A 192.33.4.12 d.root-servers.net. 360 IN A 199.7.91.13 d.root-servers.net. 360 IN 2001:500:2d::d e.root-servers.net. 360 IN A 192.203.230.10 f.root-servers.net
Re: lame-servers: error (FORMERR) resolving [something]
These are the outputs. I also attach the file containing them. ; DiG 9.8.1-P1 ns . +norec +noedns @198.41.0.4 ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 25625 ;; flags: qr ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 14 ;; QUESTION SECTION: ;.INNS ;; ANSWER SECTION: .243196INNSl.root-servers.net. .243196INNSg.root-servers.net. .243196INNSk.root-servers.net. .243196INNSa.root-servers.net. .243196INNSe.root-servers.net. .243196INNSd.root-servers.net. .243196INNSc.root-servers.net. .243196INNSi.root-servers.net. .243196INNSf.root-servers.net. .243196INNSh.root-servers.net. .243196INNSj.root-servers.net. .243196INNSb.root-servers.net. .243196INNSm.root-servers.net. ;; ADDITIONAL SECTION: a.root-servers.net.502389INA198.41.0.4 a.root-servers.net.508720IN2001:503:ba3e::2:30 b.root-servers.net.502640INA192.228.79.201 c.root-servers.net.502640INA192.33.4.12 d.root-servers.net.523851INA199.7.91.13 e.root-servers.net.502640INA192.203.230.10 f.root-servers.net.581030INA192.5.5.241 f.root-servers.net.236384IN2001:500:2f::f g.root-servers.net.502640INA192.112.36.4 i.root-servers.net.502640INA192.36.148.17 i.root-servers.net.555890IN2001:7fe::53 j.root-servers.net.537043INA192.58.128.30 j.root-servers.net.236384IN2001:503:c27::2:30 k.root-servers.net.502394INA193.0.14.129 ;; Query time: 62 msec ;; SERVER: 198.41.0.4#53(198.41.0.4) ;; WHEN: Fri Jan 18 15:38:42 2013 ;; MSG SIZE rcvd: 500 / ; DiG 9.8.1-P1 ns . +norec +edns=0 @198.41.0.4 ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 41815 ;; flags: qr ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 19 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;.INNS ;; ANSWER SECTION: .243102INNSf.root-servers.net. .243102INNSh.root-servers.net. .243102INNSi.root-servers.net. .243102INNSd.root-servers.net. .243102INNSb.root-servers.net. .243102INNSl.root-servers.net. .243102INNSm.root-servers.net. .243102INNSe.root-servers.net. .243102INNSa.root-servers.net. .243102INNSc.root-servers.net. .243102INNSj.root-servers.net. .243102INNSk.root-servers.net. .243102INNSg.root-servers.net. ;; ADDITIONAL SECTION: a.root-servers.net.502295INA198.41.0.4 a.root-servers.net.508626IN2001:503:ba3e::2:30 b.root-servers.net.502546INA192.228.79.201 c.root-servers.net.502546INA192.33.4.12 d.root-servers.net.523757INA199.7.91.13 e.root-servers.net.502546INA192.203.230.10 f.root-servers.net.580936INA192.5.5.241 f.root-servers.net.236290IN2001:500:2f::f g.root-servers.net.502546INA192.112.36.4 i.root-servers.net.502546INA192.36.148.17 i.root-servers.net.555796IN2001:7fe::53 j.root-servers.net.536949INA192.58.128.30 j.root-servers.net.236290IN2001:503:c27::2:30 k.root-servers.net.502300INA193.0.14.129 k.root-servers.net.75429IN2001:7fd::1 l.root-servers.net.502546INA199.7.83.42 m.root-servers.net.502546INA202.12.27.33 m.root-servers.net.30760IN2001:dc3::35 ;; Query time: 274 msec ;; SERVER: 198.41.0.4#53(198.41.0.4) ;; WHEN: Fri Jan 18 15:40:15 2013 ;; MSG SIZE rcvd: 599 /// ; DiG 9.8.1-P1 ns . +norec +dnssec @198.41.0.4 ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 2272 ;; flags: qr ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 20 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;.INNS ;; ANSWER SECTION: .243053INNSd.root-servers.net. .243053INNSf.root-servers.net. .243053INNSh.root-servers.net. .243053INNSa.root-servers.net. .243053INNSb.root-servers.net. .243053INNS
Re: lame-servers: error (FORMERR) resolving [something]
I'm going crazy.
This is my named.conf
logging {
channel default_logfile {
file /var/cache/bind/logs/default.log;
severity info;
print-category yes;
print-severity yes;
print-time yes;
};
category default {
default_logfile;
};
category lame-servers {null;};
};
options {
directory /var/cache/bind;
dnssec-validation auto;
auth-nxdomain no;# conform to RFC1035
listen-on-v6 { any; };
};
and the default zones (not shown here).
This is the output of `dig +trace +nodnssec www.isc.org`
; DiG 9.8.1-P1 +trace +nodnssec www.isc.org
;; global options: +cmd
.360INNSM.ROOT-SERVERS.NET.
.360INNSK.ROOT-SERVERS.NET.
.360INNSG.ROOT-SERVERS.NET.
.360INNSL.ROOT-SERVERS.NET.
.360INNSB.ROOT-SERVERS.NET.
.360INNSE.ROOT-SERVERS.NET.
.360INNSA.ROOT-SERVERS.NET.
.360INNSF.ROOT-SERVERS.NET.
.360INNSJ.ROOT-SERVERS.NET.
.360INNSH.ROOT-SERVERS.NET.
.360INNSC.ROOT-SERVERS.NET.
.360INNSI.ROOT-SERVERS.NET.
.360INNSD.ROOT-SERVERS.NET.
dig: couldn't get address for 'M.ROOT-SERVERS.NET': not found
During `dig` operations, using Wireshark I can see outgoing packets to port
53 and incoming ones from port 53
The default policy of my firewall, configured via `iptables`, is to accept
everything (I'm on VirtualBox); the only rule is to MASQUERADE outgoing
packets for NAT reasons (this box is the gateway of my private network).
What's wrong?
2013/1/15 Chris Thompson c...@cam.ac.uk
On Jan 14 2013, Shane Kerr wrote:
[...]
You may want to try:
dig +trace www.isc.org
[...]
The next step may be to try:
dig +trace +dnssec www.isc.org
Beware that if you have a dig(1) from BIND 9.9.x, +dnssec has become the
default with +trace. In that case replace the first attempt with
dig +trace +nodnssec www.isc.org
--
Chris Thompson
Email: c...@cam.ac.uk
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: lame-servers: error (FORMERR) resolving [something]
Output for `dig NS .`
; DiG 9.8.1-P1 @127.0.0.1 NS .
; (1 server found)
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 37032
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;.INNS
;; Query time: 1474 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Jan 17 15:28:04 2013
;; MSG SIZE rcvd: 17
Output for `dig NS org.`
; DiG 9.8.1-P1 @127.0.0.1 NS org.
; (1 server found)
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 13835
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;org.INNS
;; Query time: 467 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Jan 17 15:29:47 2013
;; MSG SIZE rcvd: 21
Output for `dig +nodnssec +noedns NS .` is the same as the previous, as for
`dig +nodnssec NS .`
The return packets have size of 743 bytes and they all contains infos about
NS for root zone.
2013/1/17 Warren Kumari war...@kumari.net
On Jan 17, 2013, at 9:04 AM, Daniele d.imbrog...@gmail.com wrote:
I'm going crazy.
This is my named.conf
logging {
channel default_logfile {
file /var/cache/bind/logs/default.log;
severity info;
print-category yes;
print-severity yes;
print-time yes;
};
category default {
default_logfile;
};
category lame-servers {null;};
};
options {
directory /var/cache/bind;
dnssec-validation auto;
auth-nxdomain no;# conform to RFC1035
listen-on-v6 { any; };
};
and the default zones (not shown here).
This is the output of `dig +trace +nodnssec www.isc.org`
; DiG 9.8.1-P1 +trace +nodnssec www.isc.org
;; global options: +cmd
.360INNSM.ROOT-SERVERS.NET.
.360INNSK.ROOT-SERVERS.NET.
.360INNSG.ROOT-SERVERS.NET.
.360INNSL.ROOT-SERVERS.NET.
.360INNSB.ROOT-SERVERS.NET.
.360INNSE.ROOT-SERVERS.NET.
.360INNSA.ROOT-SERVERS.NET.
.360INNSF.ROOT-SERVERS.NET.
.360INNSJ.ROOT-SERVERS.NET.
.360INNSH.ROOT-SERVERS.NET.
.360INNSC.ROOT-SERVERS.NET.
.360INNSI.ROOT-SERVERS.NET.
.360INNSD.ROOT-SERVERS.NET.
dig: couldn't get address for 'M.ROOT-SERVERS.NET': not found
During `dig` operations, using Wireshark I can see outgoing packets to
port 53 and incoming ones from port 53
What size is the return packet? Do you have anything in the path that
might be helpfully trying to monkey with the replies?
What do you get for just 'dig NS .' and 'dig NS org.'?
Does anything change if you do 'dig +nodnssec +noedns NS .' versus 'dig
+nodnssec NS .'
Including the comment bit from digs output (;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Jan 17 09:18:57 2013
;; MSG SIZE rcvd: 512
would help.
W
The default policy of my firewall, configured via `iptables`, is to
accept everything (I'm on VirtualBox); the only rule is to MASQUERADE
outgoing packets for NAT reasons (this box is the gateway of my private
network).
What's wrong?
2013/1/15 Chris Thompson c...@cam.ac.uk
On Jan 14 2013, Shane Kerr wrote:
[...]
You may want to try:
dig +trace www.isc.org
[...]
The next step may be to try:
dig +trace +dnssec www.isc.org
Beware that if you have a dig(1) from BIND 9.9.x, +dnssec has become the
default with +trace. In that case replace the first attempt with
dig +trace +nodnssec www.isc.org
--
Chris Thompson
Email: c...@cam.ac.uk
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to
unsubscribe from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
--
Militant Agnostic -- I don't know and you don't either...
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: lame-servers: error (FORMERR) resolving [something]
For example, also a `dig a.root-servers.net` fails with SERVFAIL, but in
Wireshark I can see the packet with the correct response that arrives at my
network interface.
2013/1/17 Daniele d.imbrog...@gmail.com
Output for `dig NS .`
; DiG 9.8.1-P1 @127.0.0.1 NS .
; (1 server found)
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 37032
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;.INNS
;; Query time: 1474 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Jan 17 15:28:04 2013
;; MSG SIZE rcvd: 17
Output for `dig NS org.`
; DiG 9.8.1-P1 @127.0.0.1 NS org.
; (1 server found)
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 13835
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;org.INNS
;; Query time: 467 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Jan 17 15:29:47 2013
;; MSG SIZE rcvd: 21
Output for `dig +nodnssec +noedns NS .` is the same as the previous, as
for `dig +nodnssec NS .`
The return packets have size of 743 bytes and they all contains infos
about NS for root zone.
2013/1/17 Warren Kumari war...@kumari.net
On Jan 17, 2013, at 9:04 AM, Daniele d.imbrog...@gmail.com wrote:
I'm going crazy.
This is my named.conf
logging {
channel default_logfile {
file /var/cache/bind/logs/default.log;
severity info;
print-category yes;
print-severity yes;
print-time yes;
};
category default {
default_logfile;
};
category lame-servers {null;};
};
options {
directory /var/cache/bind;
dnssec-validation auto;
auth-nxdomain no;# conform to RFC1035
listen-on-v6 { any; };
};
and the default zones (not shown here).
This is the output of `dig +trace +nodnssec www.isc.org`
; DiG 9.8.1-P1 +trace +nodnssec www.isc.org
;; global options: +cmd
.360INNSM.ROOT-SERVERS.NET.
.360INNSK.ROOT-SERVERS.NET.
.360INNSG.ROOT-SERVERS.NET.
.360INNSL.ROOT-SERVERS.NET.
.360INNSB.ROOT-SERVERS.NET.
.360INNSE.ROOT-SERVERS.NET.
.360INNSA.ROOT-SERVERS.NET.
.360INNSF.ROOT-SERVERS.NET.
.360INNSJ.ROOT-SERVERS.NET.
.360INNSH.ROOT-SERVERS.NET.
.360INNSC.ROOT-SERVERS.NET.
.360INNSI.ROOT-SERVERS.NET.
.360INNSD.ROOT-SERVERS.NET.
dig: couldn't get address for 'M.ROOT-SERVERS.NET': not found
During `dig` operations, using Wireshark I can see outgoing packets to
port 53 and incoming ones from port 53
What size is the return packet? Do you have anything in the path that
might be helpfully trying to monkey with the replies?
What do you get for just 'dig NS .' and 'dig NS org.'?
Does anything change if you do 'dig +nodnssec +noedns NS .' versus 'dig
+nodnssec NS .'
Including the comment bit from digs output (;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Jan 17 09:18:57 2013
;; MSG SIZE rcvd: 512
would help.
W
The default policy of my firewall, configured via `iptables`, is to
accept everything (I'm on VirtualBox); the only rule is to MASQUERADE
outgoing packets for NAT reasons (this box is the gateway of my private
network).
What's wrong?
2013/1/15 Chris Thompson c...@cam.ac.uk
On Jan 14 2013, Shane Kerr wrote:
[...]
You may want to try:
dig +trace www.isc.org
[...]
The next step may be to try:
dig +trace +dnssec www.isc.org
Beware that if you have a dig(1) from BIND 9.9.x, +dnssec has become the
default with +trace. In that case replace the first attempt with
dig +trace +nodnssec www.isc.org
--
Chris Thompson
Email: c...@cam.ac.uk
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to
unsubscribe from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
--
Militant Agnostic -- I don't know and you don't either...
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: lame-servers: error (FORMERR) resolving [something]
What tests should I do? If I query directly an external name-server (one of the root ones or 8.8.8.8 for example) I receive the correct response. For this reason I'm inclined to think that the router doesn't block packets to/from port 53. Why should it block packets generated by BIND9? 2013/1/12 Lyle Giese l...@lcrcomputer.net On 01/11/13 03:05, Daniele wrote: Port 53 is open, I can also telnet it from another box in the same network. Now I think the problem can be on the packets size, because I'm trying every solution but nothing works. 2013/1/9 Lyle Giese l...@lcrcomputer.net On 01/09/13 08:39, Daniele wrote: 2013/1/9 Phil Mayers p.may...@imperial.ac.uk On 09/01/13 13:53, Daniele wrote: This is the scenario. I installed BIND9 via `apt-get` on a newly installed UBUNTU 12.04, virtualized on VirtualBox. The network works properly because if I indicate a different server from my own BIND9 (the first line of '/etc/resolv.conf' is, for example, `nameserver 8.8.8.8`) the lookups and any action on the Internet succeed. No, this assumption is not valid. I meant that I can reach the Internet and, vice versa, the Internet can reach my terminal. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing listbind-us...@lists.isc.orghttps://lists.isc.org/mailman/listinfo/bind-users Recursive queries that named does for a client are different than your machine as a dns client reaching out to Google's recursive service. 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. On this box running named, try this: dig +trace www.msn.com dig +trace imperial.ac.uk 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. Lyle Giese LCR Computer Services, Inc. Saying port 53 is open because you can telnet to it from a local computer is a very limited test. 1) Telnet only use TCP, UDP is the primary/first communication channel DNS uses. 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. Do a couple of dig +trace runs and see what that shows. And try some any queries to a dnssec enable domain. Lyle Giese LCR Computer Services, Inc. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: lame-servers: error (FORMERR) resolving [something]
Port 53 is open, I can also telnet it from another box in the same network. Now I think the problem can be on the packets size, because I'm trying every solution but nothing works. 2013/1/9 Lyle Giese l...@lcrcomputer.net On 01/09/13 08:39, Daniele wrote: 2013/1/9 Phil Mayers p.may...@imperial.ac.uk On 09/01/13 13:53, Daniele wrote: This is the scenario. I installed BIND9 via `apt-get` on a newly installed UBUNTU 12.04, virtualized on VirtualBox. The network works properly because if I indicate a different server from my own BIND9 (the first line of '/etc/resolv.conf' is, for example, `nameserver 8.8.8.8`) the lookups and any action on the Internet succeed. No, this assumption is not valid. I meant that I can reach the Internet and, vice versa, the Internet can reach my terminal. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing listbind-us...@lists.isc.orghttps://lists.isc.org/mailman/listinfo/bind-users Recursive queries that named does for a client are different than your machine as a dns client reaching out to Google's recursive service. 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. On this box running named, try this: dig +trace www.msn.com dig +trace imperial.ac.uk 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. Lyle Giese LCR Computer Services, Inc. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: lame-servers: error (FORMERR) resolving [something]
This is the scenario.
I installed BIND9 via `apt-get` on a newly installed UBUNTU 12.04,
virtualized on VirtualBox.
The network works properly because if I indicate a different server from my
own BIND9 (the first line of '/etc/resolv.conf' is, for example,
`nameserver 8.8.8.8`) the lookups and any action on the Internet succeed.
BIND9 configuration is the default one.
I deleted all local zones that I added (even if internal lookups worked
correctly). Now there are only default zones (root, localhost,
127.in-addr.arpa, 0.in-addr.arpa, 255.in-addr.arpa).
Options are the default ones
options {
directory /var/cache/bind;
dnssec-validation auto;
auth-nxdomain no;
listen-on-v6 {any;}
};
In this situation, if I dig anything the lookup fails, and the log is full
of lame server and FORMERR.
Why?
Perhaps the problem is due to the presence of “dnssec-validaton“ line?
2013/1/8 Matus UHLAR - fantomas uh...@fantomas.sk
Sometimes I can't resolve some addresses and, in the logs, I can find
the message in the title:
lame-servers: error (FORMERR) resolving [something]
(where `something` is the address I'm trying to resolve).
What does it means?
2013/1/8 Shane Kerr sh...@isc.org
When acting as a recursive resolver, BIND 9 follows the chain of
delegation from the root, contacting name servers identified for each
domain on the way.
In this case, one of those name servers returned a packet that BIND 9
did not like for some reason - a FORMat ERRor. The offending server is
marked as lame since it cannot answer queries for the domain in
question.
The message should also include the IP address of the server that it is
going to at the end of the line.
On 08.01.13 13:05, Daniele wrote:
So it's not my responsibility to resolve the problem, right?
The point is that, sometimes, I can't resolve an address because of this
lame servers, and dig (for example) fails.
Is it possible?
possible, yes. but I would not be sure, since there are many different
reasons for the lookups to fail.
and there are few web services that check proper DNS functionality. I
advise
check with more of them, since there's none I would completely trust.
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Spam = (S)tupid (P)eople's (A)dvertising (M)ethod
__**_
Please visit
https://lists.isc.org/mailman/**listinfo/bind-usershttps://lists.isc.org/mailman/listinfo/bind-usersto
unsubscribe from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/**listinfo/bind-usershttps://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Name resolution fails if not forwarding
This is the scenario.
I installed BIND9 via `apt-get` on a newly installed UBUNTU 12.04,
virtualized on VirtualBox.
The network works properly because if I indicate a different server from my
own BIND9 (the first line of '/etc/resolv.conf' is, for example,
`nameserver 8.8.8.8`) the lookups and any action on the Internet succeed.
BIND9 configuration is the default one.
I deleted all local zones that I added (even if internal lookups worked
correctly). Now there are only default zones (root, localhost,
127.in-addr.arpa, 0.in-addr.arpa, 255.in-addr.arpa).
Options are the default ones
options {
directory /var/cache/bind;
dnssec-validation auto;
auth-nxdomain no;
listen-on-v6 {any;}
};
In this situation, if I dig anything the lookup fails, and the log is full
of lame server and FORMERR.
Why?
Perhaps the problem is due to the presence of “dnssec-validaton“ line?
2013/1/8 Kevin Darcy k...@chrysler.com
On 1/8/2013 9:35 AM, Daniele wrote:
If I use BIND9 forwarding all the queries not belonging to my local
zones, it works.
But if I don't forward those queries, `dig` sometimes (and this is weird)
fails (with connection timed out; no servers could be reached) and the
logs are full of lame server, FORMERR.
Why?
My guess is that your nameserver is having so much trouble resolving
Internet names that it's thrashing and this is causing intermittent
slowdowns/failures resolving even names from local zones.
You might be able to confirm or deny this speculation by looking at how
many concurrent recursive clients you have (e.g. through rndc).
If confirmed, this leads to the bigger question of why you're having
trouble resolving Internet names. Lame server is almost certainly a
problem with the remote nameserver and/or the delegation to that
nameserver, rather than your nameserver or anything in between. FORMERR, on
the other hand, might be caused if some intermediate device is mangling
your packets. Personally, I'd do a packet capture at various points in the
path and analyze the results. Improper handling of EDNS0 frequently leads
to these types of symptoms.
- Kevin
__**_
Please visit
https://lists.isc.org/mailman/**listinfo/bind-usershttps://lists.isc.org/mailman/listinfo/bind-usersto
unsubscribe from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/**listinfo/bind-usershttps://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: lame-servers: error (FORMERR) resolving [something]
2013/1/9 Phil Mayers p.may...@imperial.ac.uk On 09/01/13 13:53, Daniele wrote: This is the scenario. I installed BIND9 via `apt-get` on a newly installed UBUNTU 12.04, virtualized on VirtualBox. The network works properly because if I indicate a different server from my own BIND9 (the first line of '/etc/resolv.conf' is, for example, `nameserver 8.8.8.8`) the lookups and any action on the Internet succeed. No, this assumption is not valid. I meant that I can reach the Internet and, vice versa, the Internet can reach my terminal. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
lame-servers: error (FORMERR) resolving [something]
Hi all. Sometimes I can't resolve some addresses and, in the logs, I can find the message in the title: lame-servers: error (FORMERR) resolving [something] (where `something` is the address I'm trying to resolve). What does it means? And how can I resolve this problem? Thank you! ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: lame-servers: error (FORMERR) resolving [something]
Thank you.
So it's not my responsibility to resolve the problem, right?
The point is that, sometimes, I can't resolve an address because of this
lame servers, and dig (for example) fails.
Is it possible?
2013/1/8 Shane Kerr sh...@isc.org
Daniele,
On Tuesday, 2013-01-08 09:49:57 +0100,
Daniele d.imbrog...@gmail.com wrote:
Hi all.
Sometimes I can't resolve some addresses and, in the logs, I can find
the message in the title:
lame-servers: error (FORMERR) resolving [something]
(where `something` is the address I'm trying to resolve).
What does it means?
When acting as a recursive resolver, BIND 9 follows the chain of
delegation from the root, contacting name servers identified for each
domain on the way.
In this case, one of those name servers returned a packet that BIND 9
did not like for some reason - a FORMat ERRor. The offending server is
marked as lame since it cannot answer queries for the domain in
question.
The message should also include the IP address of the server that it is
going to at the end of the line.
And how can I resolve this problem?
In theory, you could try contacting the administrator of the server at
that IP address, and letting her know that there is some technical
problem so she can resolve it.
In practice, this is a worthless message and you should disable it in
named.conf:
logging {
category lame-servers { null; };
};
A couple of questions to everyone on the list...
1. Should ISC change the default logging for lame servers to disabled?
2. Are there other usually worthless default log messages we should
disable?
Cheers,
--
Shane
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Name resolution fails if not forwarding
If I use BIND9 forwarding all the queries not belonging to my local zones, it works. But if I don't forward those queries, `dig` sometimes (and this is weird) fails (with connection timed out; no servers could be reached) and the logs are full of lame server, FORMERR. Why? ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Can't find named_dump.db
No, I don't. Just for this reason I can't have a cache dump. Now, in /var, it works! 2012/12/6 Matus UHLAR - fantomas uh...@fantomas.sk I hope you did not allow BIND writing to /etc... (/etc should be writable by admins, not daemons, that's why we use /var) ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Querying directly a nameserver works, while forwarding not
I'm testing new configuration on VirtualBox following the advice of not
forwarding.
Furthermore, I exclude any reference to DNSSEC.
So, in these conditions and assuming an empty cache, if I query for a
remote domain name, my server should query a root-server and then iterate,
right?
Well, Wireshark shows me outcoming queries and incoming responses to/from
root-servers, but dig www.apple.com (for example) fails with a timeout.
syslog has a lot of DNS format error ... non-improving referral and
error (FORMERR) resolving entries.
This is my very vary basic named.conf file
options {
directory /var/cache/bind;
}
zone . {
type hint;
file /etc/bind/db.root;
};
zone localhost {
type master;
file /etc/bind/db.local;
};
zone 127.in-addr.arpa {
type master;
file /etc/bind/db.127;
};
I've also updated db.root from ftp.internic.net/domain/db.cache
2012/12/5 Sten Carlsen st...@s-carlsen.dk
On 05/12/12 18:29, Hauke Lampe wrote:
On 05.12.2012 14:59, Daniele Imbrogino wrote:
resolv.conf contains only 127.0.0.1 as nameserver.
The syslog contains a lot of errors as insecurity proof failed, no
valid
RRSIG, got insecure response that I don't understand.
Your forwarder probably doesn't handle DNSSEC responses well. Therefore
your BIND cannot validate the answers and returns a failure code.
Either update the forwarder/enable DNSSEC (older versions of BIND 9
require dnssec-enable yes; in the options clause), or disable DNSSEC
validation in your local BIND (set dnssec-validation no;).
Or consider not doing forwarding, that usually gives fewer problems if
possible.
Hauke
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to
unsubscribe from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
--
Best regards
Sten Carlsen
No improvements come from shouting:
MALE BOVINE MANURE!!!
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to
unsubscribe from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Querying directly a nameserver works, while forwarding not
resolv.conf contains only 127.0.0.1 as nameserver. The syslog contains a lot of errors as insecurity proof failed, no valid RRSIG, got insecure response that I don't understand. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Can't find named_dump.db
Finally I solved it! The problem was in the write permission of /etc, while in /var/cache/bind it works perfectly! Thank you for the assistance! 2012/12/5 Matus UHLAR - fantomas uh...@fantomas.sk On 03.12.12 21:32, Daniele Imbrogino wrote: I edited the working directory to /etc/bind because this is the directory where I have all the zone data files. If I use the default /var/cache/bind do I have to move also the zone data files no, you will just have to provide full path in zones' filename statements (or, at least, create an alias)? you can make symlinks from /vat/cache/bind pointing to /etc/bind if you need I'm saying this because even if the default configuration has /var/cache/bind as default working directory, all the files are in /etc/bind by default. it's done this way just to have dumps and core files in /var/cache/bind where named usually can write, instead of /etc where it usually can't (and shouldn't). -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Silvester Stallone: Father of the RISC concept. __**_ Please visit https://lists.isc.org/mailman/**listinfo/bind-usershttps://lists.isc.org/mailman/listinfo/bind-usersto unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/**listinfo/bind-usershttps://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Can't find named_dump.db
Using BIND 9.8.1 on Ubuntu 12.04, I try to save the server cache using the command sudo rndc dumpdb -cache (without quotes, obviously), but then I can't find the file /etc/bind/named_dump.db being /etc/bind/ the working directory of the server. Why? ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Can't find named_dump.db
I edited the working directory to /etc/bind because this is the directory where I have all the zone data files. If I use the default /var/cache/bind do I have to move also the zone data files (or, at least, create an alias)? I'm saying this because even if the default configuration has /var/cache/bind as default working directory, all the files are in /etc/bind by default. 2012/12/3 Chris Buxton chris.p.bux...@gmail.com On Dec 3, 2012, at 7:41 AM, Daniele Imbrogino wrote: Using BIND 9.8.1 on Ubuntu 12.04, I try to save the server cache using the command sudo rndc dumpdb -cache (without quotes, obviously), but then I can't find the file /etc/bind/named_dump.db being /etc/bind/ the working directory of the server. Look in /var/cache/bind. That's the working directory for the bind9 package default configuration. (To see this, use 'grep directory /etc/bind/named.conf.options'.) Chris Buxton BlueCat Networks ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: First usage of BIND9
There are no rules in iptables, and they accept everything by default. 2012/11/25 Phil Mayers p.may...@imperial.ac.uk On 11/25/2012 04:12 PM, Daniele Imbrogino wrote: Using Wireshark I can see that there are queries from my IP to a root-server and replies in the reverse way, but then dig always fails with a SERVFAIL. Why? iptables? __**_ Please visit https://lists.isc.org/mailman/**listinfo/bind-usershttps://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/**listinfo/bind-usershttps://lists.isc.org/mailman/listinfo/bind-users 2012/11/24 Daniele Imbrogino d.imbrog...@gmail.com I'd like to use BIND9 in the simplest way possible: I just want to install it and use it for name resolution of Internet hosts. So, on Ubuntu 12.04, I run sudo apt-get install bind9 bind9utils bind9-doc and then dig @127.0.0.1 www.amazon.com (for example), but I ALWAYS obtain a SERVFAIL. Why? Is it necessary a configuration for this minimal use, too? ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
[no subject]
I'd like to install on Ubuntu 12.04 a DNS server using BIND9.
As a first step, I'd just like to configure it as a forwarder for my box
only.
This is what I do:
1. I deactivate `dnsmasq` editing
`/etc/NetworkManager/NetworkManager.conf` by commenting the `dns=dnsmasq`
line.
Before, the `/etc/resolv.conf` file contained a `nameserver 127.0.0.1`
line, and now there is a `nameserver 10.0.2.3` line (my actual DNS server
working in a VirtualBox environment). I think it's right, and name
resolution (using `dig`) still works.
2. I download BIND9 and the suggested packages with `sudo apt-get install
bind9 bind9utils bind9-doc`
3. In `/etc/bind/named.conf.options` I edit the
// forwarders {
// 0.0.0.0;
// };
block with the
forwarders {
10.0.2.3;
};
block.
4. In `/etc/dhcp/dhclient.conf` I de-comment the `#prepend
domain-name-servers 127.0.0.1;` line; using DHCP for my network interface,
this allows to have `nameserver 127.0.0.1` as first line on
`/etc/resolv.conf`; if I had a static configuration, I would just add a
`dns-nameservers 127.0.0.1` line in `/etc/network/interfaces`.
5. Now I restart all services (resolvconf, dhclient, bind9).
Well, from this point nothing works.
Using Wireshark I can see a lot of DNS queries to/from 10.0.2.3 and also
to/from root-servers, but `dig` continues to fail with `status: SERVFAIL`.
Why?
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
