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
