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]
On Jan 22, 2013, at 5:18 AM, Daniele d.imbrog...@gmail.com wrote: Ok! Thank you all! My router doesn't maintain a DNS cache, And what are you basing this upon? W 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.
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]
On Jan 18, 2013, at 9:44 AM, Daniele d.imbrog...@gmail.com wrote: These are the outputs. I also attach the file containing them. [ SNIP ] Weird…. Do things work well enough for: dig +short rs.dns-oarc.net txt ? Can you also do: the following queries starting with the slightly less plain DNS query dig ns org +norec +noedns @198.41.0.4 Now add in EDNS support dig ns org +norec +edns=0 @198.41.0.4 Now add in DNSEC support dig ns org +norec +dnssec @198.41.0.4 And then: dig ns org +norec +dnssec +tcp @198.41.0.4 The responses in your previous mail all looked sane, as Leonard mentioned a packet dump would be helpful, so can you do: sudo tcpdump -w queries.pcap -s -i eth0 port 53 and then your original query ( dig +trace +nodnssec www.isc.org ) and then kill the tcpdump and send us the queries.pcap file (or, capture in wireshark and do the same) W 2013/1/17 Mark Andrews ma...@isc.org What are the answers to the following queries starting with the very basic plain DNS query dig ns . +norec +noedns @198.41.0.4 Now add in EDNS support dig ns . +norec +edns @198.41.0.4 Now add in DNSEC support dig ns . +norec +dnssec @198.41.0.4 Please post the responses to all these queries -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org output.txt___ 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 --- Schizophrenia beats being alone. ___ 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]
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. 360 IN A 192.5.5.241 f.root-servers.net. 360 IN 2001:500:2f::f g.root-servers.net. 360 IN A 192.112.36.4 h.root-servers.net. 360 IN A 128.63.2.53 h.root-servers.net. 360 IN 2001:500:1::803f:235 i.root-servers.net. 360 IN A 192.36.148.17 i.root-servers.net. 360 IN 2001:7fe::53 ;; Query time: 182 msec ;; SERVER: 198.41.0.4#53(198.41.0.4) ;; WHEN: Sat Jan 19 08:06:22
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]
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]
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 are the answers to the following queries starting with the very basic plain DNS query dig ns . +norec +noedns @198.41.0.4 Now add in EDNS support dig ns . +norec +edns @198.41.0.4 Now add in DNSEC support dig ns . +norec +dnssec @198.41.0.4 Please post the responses to all these queries -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ 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]
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]
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]
Daniele, It may be a simple case of your firewall not allowing any DNS queries that do not request recursion. Difficult to know. You may want to try: dig +trace www.isc.org This will follow the referrals from the root, and you can verify that this works. The next step may be to try: dig +trace +dnssec www.isc.org This will ask for DNSSEC, which will mean enabling EDNS0 and getting bigger response packets, both of which can cause problems with broken middleboxes (although BIND 9 should work even in those cases). Cheers, -- Shane On Monday, 2013-01-14 10:44:44 +0100, Daniele d.imbrog...@gmail.com wrote: 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? ___ 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]
Packet dumps at your edge would likely be helpful to your diagnosis. At your firewall (or other edge appliance) you are seeing successful UDP from a high port on your system (DNS client) to port 53 on the server and a reply in the opposite direction. You are not seeing success from an external client high port to 53 to on your server. The two operations are absolutely disjoint when you deal with firewall tuples. Hope this helps, Len From: Daniele d.imbrog...@gmail.com To: bind-users@lists.isc.org Sent: Monday, January 14, 2013 1:44 AM Subject: 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?___ 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]
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 mailto:l...@lcrcomputer.net On 01/09/13 08:39, Daniele wrote: 2013/1/9 Phil Mayers p.may...@imperial.ac.uk mailto: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 visithttps://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org mailto:bind-users@lists.isc.org https://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 http://www.msn.com dig +trace imperial.ac.uk http://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
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: lame-servers: error (FORMERR) resolving [something]
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. A recursive resolver emits different queries, and different kinds of queries, to those a client sends *to* a recursive resolver. Most notably, EDNS is enabled and this large IP/UDP fragments can be expected, particularly if you are doing DNSSEC validation. Whether that's your problem I don't know. But you can't assume the network path is good just because you can query googles public recursive DNS. ___ 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
Re: lame-servers: error (FORMERR) resolving [something]
On 01/09/13 08:39, Daniele wrote: 2013/1/9 Phil Mayers p.may...@imperial.ac.uk mailto: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 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
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]
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
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
Re: lame-servers: error (FORMERR) resolving [something]
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-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
