lame-servers: error (FORMERR) resolving [something]

Daniele d.imbrogino at gmail.com
Thu Jan 17 14:57:57 UTC 2013


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.imbrogino at 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:
> ;.                IN    NS
>
> ;; 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.                IN    NS
>
> ;; 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 <warren at kumari.net>
>
>>
>> On Jan 17, 2013, at 9:04 AM, Daniele <d.imbrogino at 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
>> > .            3600000    IN    NS    M.ROOT-SERVERS.NET.
>> > .            3600000    IN    NS    K.ROOT-SERVERS.NET.
>> > .            3600000    IN    NS    G.ROOT-SERVERS.NET.
>> > .            3600000    IN    NS    L.ROOT-SERVERS.NET.
>> > .            3600000    IN    NS    B.ROOT-SERVERS.NET.
>> > .            3600000    IN    NS    E.ROOT-SERVERS.NET.
>> > .            3600000    IN    NS    A.ROOT-SERVERS.NET.
>> > .            3600000    IN    NS    F.ROOT-SERVERS.NET.
>> > .            3600000    IN    NS    J.ROOT-SERVERS.NET.
>> > .            3600000    IN    NS    H.ROOT-SERVERS.NET.
>> > .            3600000    IN    NS    C.ROOT-SERVERS.NET.
>> > .            3600000    IN    NS    I.ROOT-SERVERS.NET.
>> > .            3600000    IN    NS    D.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 <cet1 at 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: cet1 at cam.ac.uk
>> >
>> > _______________________________________________
>> > Please visit https://lists.isc.org/mailman/listinfo/bind-users to
>> unsubscribe from this list
>> >
>> > bind-users mailing list
>> > bind-users at lists.isc.org
>> > https://lists.isc.org/mailman/listinfo/bind-users
>>
>> --
>> Militant Agnostic -- I don't know and you don't either...
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20130117/08828e94/attachment.html>


More information about the bind-users mailing list