problem with resolving SOME EXTERNAL domains

en...@bih.net.ba

unread,

Jun 7, 2005, 8:31:48 AM6/7/05

to

Hi all,

I am new to this mailing list.

I administrate two name servers (master and slave).
Configuration is Solaris 9, Bind 9.2.3.

When I moved the Bind to new hardware platform (two SPARC machines)
problems started to hapen.
I just can not resolve some domais (mail admistrators says that this is
big amount of domains not resolving - mail communicate with DNS server
because of SPAMASSASIN).
DNS server from some other domain CAN resolve those domains
(www.dnsstuff.com <http://www.dnsstuff.com/> also).
I am prety much sure that my Bind configuration is fine, i checked
nsswintch.conf file, DNS servers ARE NOT behind any firewall, i put
query-source address * port 53; directive in named.conf (in every case),
BUT NOTHING HELPS.
TCP and UDP seems works fine. I checked it through SNOOP and netstat -s.

Do you have some sugestions.

Thanks in advance.

P.S I used default installations of Solaris 9 form vendor (Fujitsu
Siemens). I thinking of new instalation of Solaris 9.

Stephane Bortzmeyer

unread,

Jun 7, 2005, 8:47:17 AM6/7/05

to

On Tue, Jun 07, 2005 at 02:31:48PM +0200,
en...@bih.net.ba <en...@bih.net.ba> wrote

a message of 29 lines which said:

> I just can not resolve some domais

It would be a good idea to give us at least some of these domains so
we can test...

> i put query-source address * port 53; directive in named.conf

Bad idea.

> Do you have some sugestions.

dig +trace and post the result.

Ronan Flood

unread,

Jun 7, 2005, 11:12:53 AM6/7/05

to

<en...@bih.net.ba> wrote:

> There are some domains which 'works' through dig and nslookup.
>
> # dig cnn.com +trace
>
> ; <<>> DiG 8.3 <<>> cnn.com +trace

dig 8.3 doesn't support +trace -- have you snipped the error message?

% dig cnn.com. +trace
; *** Invalid option: trace

; <<>> DiG 8.3 <<>> cnn.com. +trace

Try the dig that comes with BIND 9.2.3, which you're running.

--
Ronan Flood <R.F...@noc.ulcc.ac.uk>
working for but not speaking for
Network Services, University of London Computer Centre
(which means: don't bother ULCC if I've said something you don't like)

en...@bih.net.ba

unread,

Jun 7, 2005, 8:58:02 AM6/7/05

to

Thanks veru much for replying.
Here is dig output

# dig usno.navy.mil +trace

; <<>> DiG 8.3 <<>> usno.navy.mil +trace
;; res options: init recurs defnam dnsrch
;; res_nsend to server default -- 195.222.32.10: Connection timed out
#
#
#
# dig usno.navy.mil +debug

; <<>> DiG 8.3 <<>> usno.navy.mil +debug
;; res_nmkquery(QUERY, usno.navy.mil, IN, A)
;; res options: init debug recurs defnam dnsrch
;; res_send()
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8225
;; flags: rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUERY SECTION:
;; usno.navy.mil, type = A, class = IN

;; Querying server (# 1) address = 195.222.32.10
;; new DG socket
;; timeout
;; Querying server (# 1) address = 195.222.32.10
;; timeout
;; res_nsend to server default -- 195.222.32.10: Connection timed out

P.S I can NOT trace or ping 3 root DNS server, althought i CAN do
nslookup to them, for example, nslookup then server *****.
I think that part of my configuration file regarding root hints is fine.
Are there is some catch?

Stephane Bortzmeyer

unread,

Jun 7, 2005, 9:48:07 AM6/7/05

to

On Tue, Jun 07, 2005 at 02:58:02PM +0200,
en...@bih.net.ba <en...@bih.net.ba> wrote

a message of 34 lines which said:

> ;; res_nsend to server default -- 195.222.32.10: Connection timed out

I assume that 195.222.32.10 is your recursive name server? You should
test on it (and debug the clients later).

What's the result with the domains which do work?

> P.S I can NOT trace or ping 3 root DNS server,

Yes, it seems the root name servers are not reachable from
195.222.32.10. (ping is a bad test, not all the root name servers are
pinguable, B and D, for instance, you should use dig.)

> althought i CAN do nslookup to them, for example, nslookup then
> server *****.

That's not a proper test.

en...@bih.net.ba

unread,

Jun 7, 2005, 10:07:17 AM6/7/05

to

Yes this is a recursive DNS server.

<
You should test on it (and debug the clients later).

What's the result with the domains which do work?
>

What is your exact proposal?
What did you mean by the results with the domains which do work?

What is your opinion about not be able to trace B and D?

Stephane Bortzmeyer

unread,

Jun 7, 2005, 10:21:22 AM6/7/05

to

On Tue, Jun 07, 2005 at 04:07:17PM +0200,
en...@bih.net.ba <en...@bih.net.ba> wrote

a message of 14 lines which said:

> What did you mean by the results with the domains which do work?

Your subject says you have problems with "SOME EXTERNAL domains". You
showed us a dig +trace with only one domain, one which fails. I infer
from your subject that some domains do work. Show that so we can see
the difference.

> What is your opinion about not be able to trace B and D?

No opinion, it is perfectly normal. Test the root name servers with
dig, *not* with ping (in a world of firewalls, ping means now
nothing.)

en...@bih.net.ba

unread,

Jun 7, 2005, 10:29:59 AM6/7/05

to

OK

There are some domains which 'works' through dig and nslookup.

# dig cnn.com +trace

; <<>> DiG 8.3 <<>> cnn.com +trace

;; res options: init recurs defnam dnsrch

;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61278
;; flags: qr rd ra; QUERY: 1, ANSWER: 8, AUTHORITY: 4, ADDITIONAL: 4
;; QUERY SECTION:
;; cnn.com, type = A, class = IN

;; ANSWER SECTION:
cnn.com. 1m53s IN A 64.236.16.116
cnn.com. 1m53s IN A 64.236.24.4
cnn.com. 1m53s IN A 64.236.24.12
cnn.com. 1m53s IN A 64.236.24.20
cnn.com. 1m53s IN A 64.236.24.28
cnn.com. 1m53s IN A 64.236.16.20
cnn.com. 1m53s IN A 64.236.16.52
cnn.com. 1m53s IN A 64.236.16.84

;; AUTHORITY SECTION:
cnn.com. 4m54s IN NS twdns-01.ns.aol.com.
cnn.com. 4m54s IN NS twdns-02.ns.aol.com.
cnn.com. 4m54s IN NS twdns-03.ns.aol.com.
cnn.com. 4m54s IN NS twdns-04.ns.aol.com.

;; ADDITIONAL SECTION:
twdns-01.ns.aol.com. 54m55s IN A 149.174.213.151
twdns-02.ns.aol.com. 54m53s IN A 152.163.239.216
twdns-03.ns.aol.com. 54m53s IN A 207.200.73.85
twdns-04.ns.aol.com. 54m53s IN A 64.12.147.120

;; Total query time: 2 msec
;; FROM: ns1 to SERVER: default -- 195.222.32.10
;; WHEN: Tue Jun 7 16:20:30 2005
;; MSG SIZE sent: 25 rcvd: 316

#
#
# nslookup
Default Server: ns1.bih.net.ba
Address: 195.222.32.10

> set type=any
>
>
> cnn.com
Server: ns1.bih.net.ba
Address: 195.222.32.10

Non-authoritative answer:
cnn.com internet address = 64.236.24.28
cnn.com internet address = 64.236.16.20
cnn.com internet address = 64.236.16.52
cnn.com internet address = 64.236.16.84
cnn.com internet address = 64.236.16.116
cnn.com internet address = 64.236.24.4
cnn.com internet address = 64.236.24.12
cnn.com internet address = 64.236.24.20
cnn.com nameserver = twdns-04.ns.aol.com
cnn.com nameserver = twdns-01.ns.aol.com
cnn.com nameserver = twdns-02.ns.aol.com
cnn.com nameserver = twdns-03.ns.aol.com

Authoritative answers can be found from:
cnn.com nameserver = twdns-04.ns.aol.com
cnn.com nameserver = twdns-01.ns.aol.com
cnn.com nameserver = twdns-02.ns.aol.com
cnn.com nameserver = twdns-03.ns.aol.com
twdns-01.ns.aol.com internet address = 149.174.213.151
twdns-02.ns.aol.com internet address = 152.163.239.216
twdns-03.ns.aol.com internet address = 207.200.73.85
twdns-04.ns.aol.com internet address = 64.12.147.120
>

# dig abbott.com.ba +trace

; <<>> DiG 8.3 <<>> abbott.com.ba +trace

;; res options: init recurs defnam dnsrch

;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53461
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUERY SECTION:
;; abbott.com.ba, type = A, class = IN

;; AUTHORITY SECTION:
abbott.com.ba. 2h57m5s IN SOA ns1.com.ba. dns.bih.net.ba. (
1008 ; serial
1D ; refresh
2H ; retry
1W ; expiry
2D ) ; minimum

;; Total query time: 2 msec
;; FROM: ns1 to SERVER: default -- 195.222.32.10
;; WHEN: Tue Jun 7 16:21:11 2005
;; MSG SIZE sent: 31 rcvd: 83

#
#
# nslookup
Default Server: ns1.bih.net.ba
Address: 195.222.32.10

> set type=any
>
>
> abbott.com.ba
Server: ns1.bih.net.ba
Address: 195.222.32.10

Non-authoritative answer:
abbott.com.ba
origin = ns1.com.ba
mail addr = dns.bih.net.ba
serial = 1008
refresh = 86400 (1D)
retry = 7200 (2H)
expire = 604800 (1W)
minimum ttl = 172800 (2D)

Authoritative answers can be found from:
com.ba nameserver = ns1.com.ba
ns1.com.ba internet address = 195.222.32.30

Mark Andrews

unread,

Jun 7, 2005, 7:16:04 PM6/7/05

to

> Hi all,
>
> I am new to this mailing list.
>
> I administrate two name servers (master and slave).
> Configuration is Solaris 9, Bind 9.2.3.

Upgrade. Bind 9.2.3 is past it "use by" date.

> When I moved the Bind to new hardware platform (two SPARC machines)
> problems started to hapen.
> I just can not resolve some domais (mail admistrators says that this is
> big amount of domains not resolving - mail communicate with DNS server
> because of SPAMASSASIN).
> DNS server from some other domain CAN resolve those domains
> (www.dnsstuff.com <http://www.dnsstuff.com/> also).
> I am prety much sure that my Bind configuration is fine, i checked
> nsswintch.conf file, DNS servers ARE NOT behind any firewall, i put
> query-source address * port 53; directive in named.conf (in every case),
> BUT NOTHING HELPS.
> TCP and UDP seems works fine. I checked it through SNOOP and netstat -s.
>

> Do you have some sugestions.
>

> Thanks in advance.
>
> P.S I used default installations of Solaris 9 form vendor (Fujitsu
> Siemens). I thinking of new instalation of Solaris 9.
>
>
>
>

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_A...@isc.org

peter h

unread,

Jun 13, 2005, 1:23:39 AM6/13/05

to

<en...@bih.net.ba> wrote in message news:<d844sf$1cv$1...@sf1.isc.org>...

I have read the trhread until 10 june, and also tried a few
'dig's to your nameservers.

And it seems to me that :
1/ your named is working correct
2/ at least "usno.navy.mil"'s nameservers are refusing to communicate
with your ip-range ( or provider)

My observation is based on :
"dig ipsec.se ns @195.222.32.20" ( this works )
"dig usno.navy.mil ns @195.222.32.20" ( end with a refusal)

I would start checking about connectivity and possible change of ISP.

Peter h

Peter Dambier

unread,

Jun 13, 2005, 3:24:46 PM6/13/05

to

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

dig does rely on a well maintained /etc/hosts file :)

I did have problems digging and I did see the same problems with
check_soa program from the O'Reilly book "DNS and BIND".

There are some programmes that can read a zone file and build an
/etc/hosts like file for you. Please read more on one of the following
sites:

http://www.kokoom.com/iason
http://iason.site.voila.fr

Dont worry most of the documentation is english.

After I had the glue records "added" to my /etc/hosts both
dig and check_soa worked fine.

|
| Can you query those servers directly by IP address from dig, eg
| ns-naples.navy.mil is 138.180.5.138, so
|
| dig @138.180.5.138 usno.navy.mil. a +norec
|
| should list the NS records for usno.navy.mil and the A records for those
| servers:

try: dig -t any @138.180.5.138 usno.navy.mil. a +norec
and: dig -t any @138.180.5.138 usno.navy.mil. a +norec +vc

"-t any" gets you all information. If you had hit the SOA it would
return only the "A" record.

"+vc" will use tcp not udp. That might be necessary if the returned
data does not fit into an udp packet.

; <<>> DiG 9.1.3 <<>> @138.143.200.2 usno.navy.mil. a +norec
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48291
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 3

;; QUESTION SECTION:
;usno.navy.mil. IN A

;; AUTHORITY SECTION:
usno.navy.mil. 86400 IN NS CHARON.usno.navy.mil.
usno.navy.mil. 86400 IN NS PSYCHE.usno.navy.mil.
usno.navy.mil. 86400 IN NS METIS.usno.navy.mil.

;; ADDITIONAL SECTION:
METIS.usno.navy.mil. 86400 IN A 198.116.61.5
CHARON.usno.navy.mil. 86400 IN A 199.211.133.5
PSYCHE.usno.navy.mil. 86400 IN A 192.5.41.214

;; Query time: 173 msec
;; SERVER: 138.143.200.2#53(138.143.200.2)
;; WHEN: Mon Jun 13 21:18:11 2005
;; MSG SIZE rcvd: 141

; <<>> DiG 9.1.3 <<>> @192.245.206.2 usno.navy.mil. a +norec
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29025
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 3

;; QUESTION SECTION:
;usno.navy.mil. IN A

;; AUTHORITY SECTION:
usno.navy.mil. 86400 IN NS CHARON.usno.navy.mil.
usno.navy.mil. 86400 IN NS PSYCHE.usno.navy.mil.
usno.navy.mil. 86400 IN NS METIS.usno.navy.mil.

;; ADDITIONAL SECTION:
METIS.usno.navy.mil. 86400 IN A 198.116.61.5
CHARON.usno.navy.mil. 86400 IN A 199.211.133.5
PSYCHE.usno.navy.mil. 86400 IN A 192.5.41.214

;; Query time: 247 msec
;; SERVER: 192.245.206.2#53(192.245.206.2)
;; WHEN: Mon Jun 13 21:16:23 2005
;; MSG SIZE rcvd: 141

This looks not like a problem with bind.

|
| Is this a network problem, or..?
| Possible network problems on communication with root DNS servers?

This is a network problem.

Maybe you have problems with routing.
Maybe you are not connected at all.

Regards,
Peter and Karin Dambier
Public-Root

- --
Peter and Karin Dambier
Public-Root
Graeffstrasse 14
D-64646 Heppenheim
+49-6252-671788 (Telekom)
+49-6252-599091 (O2 Genion)
+1-360-226-6583-9738 (INAIC)
mail: pe...@peter-dambier.de
http://iason.site.voila.fr
http://www.kokoom.com/iason
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQFCrd14PGG/Vycj6zYRAmp6AKCCv8X1FQMKLH98H/OqN3YoHul+qgCfWXiJ
D8G7OOkPe6aGeJX8j0U/HWY=
=O1SQ
-----END PGP SIGNATURE-----

mayer

unread,

Jun 14, 2005, 12:22:51 PM6/14/05

to

----- Original Message Follows -----

That would come as a big surprise to the BIND development team.
dig and all of the other tools don't know or care about the
/etc/hosts file and wouldn't look at it. DNS was developed
to replace /etc/hosts files.

dig only looks at the /etc/resolv.conf if it needs to find the
nameserver to use (if not defined on the command line) and only
looks at the rest of the content if requested to.

>
> I did have problems digging and I did see the same problems with
> check_soa program from the O'Reilly book "DNS and BIND".
>
> There are some programmes that can read a zone file and build an
> /etc/hosts like file for you. Please read more on one of the following
> sites:
>
> http://www.kokoom.com/iason
> http://iason.site.voila.fr
>
> Dont worry most of the documentation is english.
>
> After I had the glue records "added" to my /etc/hosts both
> dig and check_soa worked fine.

Then you have a different problem. It won't affect dig.

Danny

Ronan Flood

unread,

Jun 14, 2005, 1:41:30 PM6/14/05

to

"mayer" <ma...@gis.net> wrote:

> ----- Original Message Follows -----
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >

> > | (Question to group/list: does dig 9.3.1 rely on the configured
> > resolver, | using gethostbyname or similar, to resolve the NS names to
> > addresses, | ignoring any glue A in additional sections? I've seen
> > something that | does)
> >
> > dig does rely on a well maintained /etc/hosts file :)
>
> That would come as a big surprise to the BIND development team.
> dig and all of the other tools don't know or care about the
> /etc/hosts file and wouldn't look at it. DNS was developed
> to replace /etc/hosts files.
>
> dig only looks at the /etc/resolv.conf if it needs to find the
> nameserver to use (if not defined on the command line) and only
> looks at the rest of the content if requested to.

Well in answer to my question, I've just built dig 9.3.1 and tried
"dig www.usno.navy.mil. a +trace" with /etc/resolv.conf pointing to
a resolver with query-logging turned on.

dig reports (truncated):

; <<>> DiG 9.3.1 <<>> www.usno.navy.mil. a +trace
;; global options: printcmd
. 33231 IN NS L.ROOT-SERVERS.NET.
[snip]
;; Received 436 bytes from 194.83.56.246#53(194.83.56.246) in 9 ms

mil. 86400 IN NS G.ROOT-SERVERS.NET.
[snip]
;; Received 426 bytes from 198.32.64.12#53(L.ROOT-SERVERS.NET) in 160 ms

navy.mil. 86400 IN NS NS-NORVA.navy.mil.
[snip]
;; Received 237 bytes from 192.112.36.4#53(G.ROOT-SERVERS.NET) in 286 ms

usno.navy.mil. 86400 IN NS CHARON.usno.navy.mil.

[snip]
;; Received 145 bytes from 205.56.138.34#53(NS-NORVA.navy.mil) in 90 ms

www.usno.navy.mil. 43200 IN A 198.116.61.213
[snip]
;; Received 161 bytes from 199.211.133.5#53(CHARON.usno.navy.mil) in 84 ms

The query log on the (BIND 8) resolver shows (truncated):

XX /..././NS/IN
XX+/.../L.ROOT-SERVERS.NET/A/IN
XX+/.../G.ROOT-SERVERS.NET/A/IN
XX+/.../NS-NORVA.navy.mil/A/IN
XX+/.../CHARON.usno.navy.mil/A/IN

So dig +trace *is* querying the resolver for the addresses of the
intermediate nameservers on the descent from the root, rather than
using any associated glue. Is there any way to override this and
force dig +trace to do *all* the resolution itself? If not, perhaps
there should be ...

mayer

unread,

Jun 15, 2005, 9:05:44 AM6/15/05

to

----- Original Message Follows -----
> "mayer" <ma...@gis.net> wrote:
>
> > ----- Original Message Follows -----
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > >
> > > | (Question to group/list: does dig 9.3.1 rely on the configured
> > > resolver, | using gethostbyname or similar, to resolve the NS
> > > names to addresses, | ignoring any glue A in additional sections?
> > > I've seen something that | does)
> > >
> > > dig does rely on a well maintained /etc/hosts file :)
> >
> > That would come as a big surprise to the BIND development team.
> > dig and all of the other tools don't know or care about the
> > /etc/hosts file and wouldn't look at it. DNS was developed
> > to replace /etc/hosts files.
> >
> > dig only looks at the /etc/resolv.conf if it needs to find the
> > nameserver to use (if not defined on the command line) and only
> > looks at the rest of the content if requested to.
>
> Well in answer to my question, I've just built dig 9.3.1 and tried
> "dig www.usno.navy.mil. a +trace" with /etc/resolv.conf pointing to
> a resolver with query-logging turned on.
>
> dig reports (truncated):
>
> ; <<>> DiG 9.3.1 <<>> www.usno.navy.mil. a +trace
> ;; global options: printcmd

You didn't specify a nameserver to use so it goes to /etc/resolv.conf
to get one. If you had specified one on the command line (@nameserver)
it would not even have done that.

dig +trace is meant to use the nameserver for all lookups. It just
does iterative queries to that nameserver. dig isn't designed to
do resolution itself. All it can do is ask for a specific piece of
information from a specific nameserver and get an answer back. +trace
makes it ask for each piece one after the other. But all it's doing
is iterating.

Danny

Ronan Flood

unread,

Jun 16, 2005, 6:37:42 AM6/16/05

to

On Wed, 15 Jun 2005 09:05:44 -0400,
"mayer" <ma...@gis.net> wrote:

> > So dig +trace *is* querying the resolver for the addresses of the
> > intermediate nameservers on the descent from the root, rather than
> > using any associated glue. Is there any way to override this and
> > force dig +trace to do *all* the resolution itself? If not, perhaps
> > there should be ...
>
> You didn't specify a nameserver to use so it goes to /etc/resolv.conf
> to get one. If you had specified one on the command line (@nameserver)
> it would not even have done that.

It would if I'd specified @ns.example.com (i.e. name rather than IP) :-/

> dig +trace is meant to use the nameserver for all lookups. It just
> does iterative queries to that nameserver. dig isn't designed to
> do resolution itself. All it can do is ask for a specific piece of
> information from a specific nameserver and get an answer back. +trace
> makes it ask for each piece one after the other. But all it's doing
> is iterating.

That's fair enough; I'm only saying that having some means of doing,
and showing, the full workings might be useful. Perhaps a separate
utility -- there may even be something out there already, eg along
the lines of the DNS traversal http://www.squish.net/dnscheck/

mayer

unread,

Jun 16, 2005, 1:47:59 PM6/16/05

to

----- Original Message Follows -----

> On Wed, 15 Jun 2005 09:05:44 -0400,
> "mayer" <ma...@gis.net> wrote:
>
> > > So dig +trace *is* querying the resolver for the addresses of the
> > > intermediate nameservers on the descent from the root, rather than
> > > using any associated glue. Is there any way to override this and
> > > force dig +trace to do *all* the resolution itself? If not,
> > > perhaps there should be ...
> >
> > You didn't specify a nameserver to use so it goes to
> > /etc/resolv.conf to get one. If you had specified one on the command
> > line (@nameserver) it would not even have done that.
>
> It would if I'd specified @ns.example.com (i.e. name rather than IP)
> :-/
>

Well it has to know the address of the nameserver in order to get
started.

Danny