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 > Daniele, > > On Tuesday, 2013-01-08 09:49:57 +0100, > Daniele 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: 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 > > 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 >> >>> 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<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<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: 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 > > 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-users<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<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]
2013/1/9 Phil Mayers > 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]
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 > On 01/09/13 08:39, Daniele wrote: > > 2013/1/9 Phil Mayers > >> 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]
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 > 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 > >> On 01/09/13 08:39, Daniele wrote: >> >> 2013/1/9 Phil Mayers >> >>> 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]
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 > 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 > > On Jan 17, 2013, at 9:04 AM, Daniele 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 > > 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 > 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 > >> >> On Jan 17, 2013, at 9:04 AM, Daniele 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'
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.ne
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 > > 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. > .
[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
Re: First usage of BIND9
There are no rules in iptables, and they accept everything by default. 2012/11/25 Phil Mayers > 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-users<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<https://lists.isc.org/mailman/listinfo/bind-users> > 2012/11/24 Daniele Imbrogino > 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
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 > 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: 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 > 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-users<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<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: 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 > > > 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 > > 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