Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

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

8,490 views
Skip to first unread message

Daniele

unread,
Jan 8, 2013, 3:49:57 AM1/8/13
to bind-...@lists.isc.org
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!

Shane Kerr

unread,
Jan 8, 2013, 4:38:36 AM1/8/13
to Daniele, bind-...@lists.isc.org
Daniele,

On Tuesday, 2013-01-08 09:49:57 +0100,
Daniele <d.imb...@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

Daniele

unread,
Jan 8, 2013, 7:05:06 AM1/8/13
to bind-...@lists.isc.org
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>

Matus UHLAR - fantomas

unread,
Jan 8, 2013, 3:30:14 PM1/8/13
to bind-...@lists.isc.org
>> > 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

Daniele

unread,
Jan 9, 2013, 8:53:58 AM1/9/13
to bind-...@lists.isc.org
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>
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
bind-...@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Phil Mayers

unread,
Jan 9, 2013, 9:21:29 AM1/9/13
to bind-...@lists.isc.org
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.

Daniele

unread,
Jan 9, 2013, 9:39:58 AM1/9/13
to bind-...@lists.isc.org
2013/1/9 Phil Mayers <p.ma...@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. 

Lyle Giese

unread,
Jan 9, 2013, 4:33:42 PM1/9/13
to bind-...@lists.isc.org
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
bind-...@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.

Daniele

unread,
Jan 11, 2013, 4:05:16 AM1/11/13
to bind-...@lists.isc.org
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 <ly...@lcrcomputer.net>

Lyle Giese

unread,
Jan 11, 2013, 11:08:58 PM1/11/13
to bind-...@lists.isc.org
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.

Daniele

unread,
Jan 14, 2013, 4:44:44 AM1/14/13
to bind-...@lists.isc.org
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 <ly...@lcrcomputer.net>

Shane Kerr

unread,
Jan 14, 2013, 6:05:01 AM1/14/13
to Daniele, bind-...@lists.isc.org
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,

Leonard Mills

unread,
Jan 14, 2013, 1:59:37 PM1/14/13
to Daniele, bind-...@lists.isc.org
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.imb...@gmail.com>
To: bind-...@lists.isc.org
Sent: Monday, January 14, 2013 1:44 AM
Subject: Re: lame-servers: error (FORMERR) resolving [something]

Chris Thompson

unread,
Jan 15, 2013, 7:28:40 AM1/15/13
to Bind Users Mailing List
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: ce...@cam.ac.uk

Daniele

unread,
Jan 17, 2013, 9:04:43 AM1/17/13
to Bind Users Mailing List
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

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 <ce...@cam.ac.uk>

Warren Kumari

unread,
Jan 17, 2013, 9:21:16 AM1/17/13
to Daniele, Bind Users Mailing List
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 <ce...@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: ce...@cam.ac.uk
>
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>
> bind-users mailing list
> bind-...@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

--
Militant Agnostic -- I don't know and you don't either...



Daniele

unread,
Jan 17, 2013, 9:36:21 AM1/17/13
to Bind Users Mailing List
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 <war...@kumari.net>

Daniele

unread,
Jan 17, 2013, 9:57:57 AM1/17/13
to Bind Users Mailing List
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.imb...@gmail.com>

Mark Andrews

unread,
Jan 17, 2013, 5:27:18 PM1/17/13
to Daniele, Bind Users Mailing List

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

Daniele

unread,
Jan 18, 2013, 9:44:33 AM1/18/13
to Bind Users Mailing List
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:
;.                IN    NS

;; ANSWER SECTION:
.            243196    IN    NS    l.root-servers.net.
.            243196    IN    NS    g.root-servers.net.
.            243196    IN    NS    k.root-servers.net.
.            243196    IN    NS    a.root-servers.net.
.            243196    IN    NS    e.root-servers.net.
.            243196    IN    NS    d.root-servers.net.
.            243196    IN    NS    c.root-servers.net.
.            243196    IN    NS    i.root-servers.net.
.            243196    IN    NS    f.root-servers.net.
.            243196    IN    NS    h.root-servers.net.
.            243196    IN    NS    j.root-servers.net.
.            243196    IN    NS    b.root-servers.net.
.            243196    IN    NS    m.root-servers.net.

;; ADDITIONAL SECTION:
a.root-servers.net.    502389    IN    A    198.41.0.4
a.root-servers.net.    508720    IN    AAAA    2001:503:ba3e::2:30
b.root-servers.net.    502640    IN    A    192.228.79.201
c.root-servers.net.    502640    IN    A    192.33.4.12
d.root-servers.net.    523851    IN    A    199.7.91.13
e.root-servers.net.    502640    IN    A    192.203.230.10
f.root-servers.net.    581030    IN    A    192.5.5.241
f.root-servers.net.    236384    IN    AAAA    2001:500:2f::f
g.root-servers.net.    502640    IN    A    192.112.36.4
i.root-servers.net.    502640    IN    A    192.36.148.17
i.root-servers.net.    555890    IN    AAAA    2001:7fe::53
j.root-servers.net.    537043    IN    A    192.58.128.30
j.root-servers.net.    236384    IN    AAAA    2001:503:c27::2:30
k.root-servers.net.    502394    IN    A    193.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:
;.                IN    NS

;; ANSWER SECTION:
.            243102    IN    NS    f.root-servers.net.
.            243102    IN    NS    h.root-servers.net.
.            243102    IN    NS    i.root-servers.net.
.            243102    IN    NS    d.root-servers.net.
.            243102    IN    NS    b.root-servers.net.
.            243102    IN    NS    l.root-servers.net.
.            243102    IN    NS    m.root-servers.net.
.            243102    IN    NS    e.root-servers.net.
.            243102    IN    NS    a.root-servers.net.
.            243102    IN    NS    c.root-servers.net.
.            243102    IN    NS    j.root-servers.net.
.            243102    IN    NS    k.root-servers.net.
.            243102    IN    NS    g.root-servers.net.

;; ADDITIONAL SECTION:
a.root-servers.net.    502295    IN    A    198.41.0.4
a.root-servers.net.    508626    IN    AAAA    2001:503:ba3e::2:30
b.root-servers.net.    502546    IN    A    192.228.79.201
c.root-servers.net.    502546    IN    A    192.33.4.12
d.root-servers.net.    523757    IN    A    199.7.91.13
e.root-servers.net.    502546    IN    A    192.203.230.10
f.root-servers.net.    580936    IN    A    192.5.5.241
f.root-servers.net.    236290    IN    AAAA    2001:500:2f::f
g.root-servers.net.    502546    IN    A    192.112.36.4
i.root-servers.net.    502546    IN    A    192.36.148.17
i.root-servers.net.    555796    IN    AAAA    2001:7fe::53
j.root-servers.net.    536949    IN    A    192.58.128.30
j.root-servers.net.    236290    IN    AAAA    2001:503:c27::2:30
k.root-servers.net.    502300    IN    A    193.0.14.129
k.root-servers.net.    75429    IN    AAAA    2001:7fd::1
l.root-servers.net.    502546    IN    A    199.7.83.42
m.root-servers.net.    502546    IN    A    202.12.27.33
m.root-servers.net.    30760    IN    AAAA    2001: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:
;.                IN    NS

;; ANSWER SECTION:
.            243053    IN    NS    d.root-servers.net.
.            243053    IN    NS    f.root-servers.net.
.            243053    IN    NS    h.root-servers.net.
.            243053    IN    NS    a.root-servers.net.
.            243053    IN    NS    b.root-servers.net.
.            243053    IN    NS    e.root-servers.net.
.            243053    IN    NS    j.root-servers.net.
.            243053    IN    NS    m.root-servers.net.
.            243053    IN    NS    k.root-servers.net.
.            243053    IN    NS    c.root-servers.net.
.            243053    IN    NS    i.root-servers.net.
.            243053    IN    NS    l.root-servers.net.
.            243053    IN    NS    g.root-servers.net.

;; ADDITIONAL SECTION:
a.root-servers.net.    502246    IN    A    198.41.0.4
a.root-servers.net.    508577    IN    AAAA    2001:503:ba3e::2:30
b.root-servers.net.    502497    IN    A    192.228.79.201
c.root-servers.net.    502497    IN    A    192.33.4.12
d.root-servers.net.    523708    IN    A    199.7.91.13
d.root-servers.net.    538431    IN    AAAA    2001:500:2d::d
e.root-servers.net.    502497    IN    A    192.203.230.10
f.root-servers.net.    580887    IN    A    192.5.5.241
f.root-servers.net.    236241    IN    AAAA    2001:500:2f::f
g.root-servers.net.    502497    IN    A    192.112.36.4
i.root-servers.net.    502497    IN    A    192.36.148.17
i.root-servers.net.    555747    IN    AAAA    2001:7fe::53
j.root-servers.net.    536900    IN    A    192.58.128.30
j.root-servers.net.    236241    IN    AAAA    2001:503:c27::2:30
k.root-servers.net.    502251    IN    A    193.0.14.129
k.root-servers.net.    75380    IN    AAAA    2001:7fd::1
l.root-servers.net.    502497    IN    A    199.7.83.42
m.root-servers.net.    502497    IN    A    202.12.27.33
m.root-servers.net.    30711    IN    AAAA    2001:dc3::35

;; Query time: 249 msec
;; SERVER: 198.41.0.4#53(198.41.0.4)
;; WHEN: Fri Jan 18 15:41:04 2013
;; MSG SIZE  rcvd: 627



2013/1/17 Mark Andrews <ma...@isc.org>
output.txt

Warren Kumari

unread,
Jan 18, 2013, 10:19:39 AM1/18/13
to Daniele, Bind Users Mailing List

On Jan 18, 2013, at 9:44 AM, Daniele <d.imb...@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 9999 -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-...@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

---
Schizophrenia beats being alone.


Mark Andrews

unread,
Jan 18, 2013, 4:22:31 PM1/18/13
to Daniele, Bind Users Mailing List

In message <CAL_2sc1sZsTUMPMfCeUqrF87...@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
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. 3600000 IN A 198.41.0.4
a.root-servers.net. 3600000 IN AAAA 2001:503:ba3e::2:30
b.root-servers.net. 3600000 IN A 192.228.79.201
c.root-servers.net. 3600000 IN A 192.33.4.12
d.root-servers.net. 3600000 IN A 199.7.91.13
d.root-servers.net. 3600000 IN AAAA 2001:500:2d::d
e.root-servers.net. 3600000 IN A 192.203.230.10
f.root-servers.net. 3600000 IN A 192.5.5.241
f.root-servers.net. 3600000 IN AAAA 2001:500:2f::f
g.root-servers.net. 3600000 IN A 192.112.36.4
h.root-servers.net. 3600000 IN A 128.63.2.53
h.root-servers.net. 3600000 IN AAAA 2001:500:1::803f:235
i.root-servers.net. 3600000 IN A 192.36.148.17
i.root-servers.net. 3600000 IN AAAA 2001:7fe::53

;; Query time: 182 msec
;; SERVER: 198.41.0.4#53(198.41.0.4)
;; WHEN: Sat Jan 19 08:06:22 EST 2013
;; MSG SIZE rcvd: 512

Daniele

unread,
Jan 22, 2013, 5:18:48 AM1/22/13
to Bind Users Mailing List
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>

Matus UHLAR - fantomas

unread,
Jan 22, 2013, 9:21:36 AM1/22/13
to bind-...@lists.isc.org
On 22.01.13 11:18, Daniele wrote:
>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),

it should, but it appears that it does not. your ISP seems to beintercepting
those messages. Ask your ISP how to turn it off.

>or is it processed by some other cache-server on the path? And why 'named'
>doesn't "understand" the responses from these cache-servers?

in your case it's getting non-authoritative responses, but with recursion
allowed. Both are unexpected so named complains.


--
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.
- Have you got anything without Spam in it?
- Well, there's Spam egg sausage and Spam, that's not got much Spam in it.

Warren Kumari

unread,
Jan 22, 2013, 9:56:15 AM1/22/13
to Daniele, Bind Users Mailing List

On Jan 22, 2013, at 5:18 AM, Daniele <d.imb...@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?
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>
> bind-users mailing list
> bind-...@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

--
The duke had a mind that ticked like a clock and, like a clock, it regularly went cuckoo.

-- (Terry Pratchett, Wyrd Sisters)


Mark Andrews

unread,
Jan 22, 2013, 10:04:47 AM1/22/13
to bind-...@isc.org

In message <20130122142...@fantomas.sk>, Matus UHLAR - fantomas writes:
> On 22.01.13 11:18, Daniele wrote:
> >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),
>
> it should, but it appears that it does not. your ISP seems to beintercepting
> those messages. Ask your ISP how to turn it off.
>
> >or is it processed by some other cache-server on the path? And why 'named'
> >doesn't "understand" the responses from these cache-servers?
>
> in your case it's getting non-authoritative responses, but with recursion
> allowed. Both are unexpected so named complains.

As I said named doesn't get the answers it needs. If you ask a
recursive server non-recursive queries it will refer you to the
best set of nameserve it knows about.

When you have a "transparent" intercepting DNS recursive server
named just gets referrals for any question that it doesn't have a
cached answer for.

The intercepting server is expecting to see queries with "rd=1".
Named makes queries with "rd=0".

Mark

> --
> 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.
> - Have you got anything without Spam in it?
> - Well, there's Spam egg sausage and Spam, that's not got much Spam in it.
0 new messages