HI Guys,

I have some problems with my DNS.

I recently have my internet provider, who has changed his DNS Ip address
-> None of my machines were working....

took me a lot of time come back on line....

I still have a machine, which is not working....
Maybe you can help me on this "school case",

I have a router with 2 ADSL. -> I have setup on the router 2 DNS IP
address to fill in.
- ONE is with the ADSL n#1
- the second one is from the the ADSL n#2

On my CentOS machine, into my Ne I have set up :
1st DNS IP : I place the router IP address
2nd DNS IP : I place one of my DNS provider
3rd DNS IP : I place one of my DNS provider ( from the 2nd provider )

Now, I found that this machine could access Internet, even being a bit
slow...

into /etc/resolv.conf
nameserver 192.168.4.7 ( IP addres router )
nameserver 62.xx.dd.ee ( DNS IP addess of Provider1)
nameserver 212.xx.vv.ee ( DNS IP addess of Provider2)


Now, If I write in command line :

dig yahoo.com - fine I've got some info
host yahoo.com -> Host yahoo.com not found: 5(REFUSED ) ? ????!?!?!?!?


- Any idea what could be the problem ?
- Is there another file to check ??

Thanks
Steve,

Steve schreef:
HI Guys,

I have some problems with my DNS.

I recently have my internet provider, who has changed his DNS Ip address
-> None of my machines were working....

took me a lot of time come back on line....

I still have a machine, which is not working....
Maybe you can help me on this "school case",

I have a router with 2 ADSL. -> I have setup on the router 2 DNS IP
address to fill in.
- ONE is with the ADSL n#1
- the second one is from the the ADSL n#2

On my CentOS machine, into my Ne I have set up :
1st DNS IP : I place the router IP address
2nd DNS IP : I place one of my DNS provider
3rd DNS IP : I place one of my DNS provider ( from the 2nd provider )

Now, I found that this machine could access Internet, even being a bit
slow...

into /etc/resolv.conf
nameserver 192.168.4.7 ( IP addres router )
nameserver 62.xx.dd.ee ( DNS IP addess of Provider1)
nameserver 212.xx.vv.ee ( DNS IP addess of Provider2)


Now, If I write in command line :

dig yahoo.com - fine I've got some info
host yahoo.com -> Host yahoo.com not found: 5(REFUSED ) ? ????!?!?!?!?


- Any idea what could be the problem ?
- Is there another file to check ??

Thanks
Steve,


Can you ping the dns servers?

Can you reach the dns servers?
telnet 192.168.4.7 53

Also check your /etc/nsswitch.conf to see if the line for hosts looks
someting like this:
hosts: files dns


Kind regards,


Jan Gerrit Kootstra

Jan Gerrit Kootstra wrote:
Steve schreef:
HI Guys,

I have some problems with my DNS.

I recently have my internet provider, who has changed his DNS Ip address
-> None of my machines were working....

took me a lot of time come back on line....

I still have a machine, which is not working....
Maybe you can help me on this "school case",

I have a router with 2 ADSL. -> I have setup on the router 2 DNS IP
address to fill in.
- ONE is with the ADSL n#1
- the second one is from the the ADSL n#2

On my CentOS machine, into my Ne I have set up :
1st DNS IP : I place the router IP address
2nd DNS IP : I place one of my DNS provider
3rd DNS IP : I place one of my DNS provider ( from the 2nd provider )

Now, I found that this machine could access Internet, even being a
bit slow...

into /etc/resolv.conf
nameserver 192.168.4.7 ( IP addres router )
nameserver 62.xx.dd.ee ( DNS IP addess of Provider1)
nameserver 212.xx.vv.ee ( DNS IP addess of Provider2)


Now, If I write in command line :

dig yahoo.com - fine I've got some info
host yahoo.com -> Host yahoo.com not found: 5(REFUSED ) ? ????!?!?!?!?


- Any idea what could be the problem ?
- Is there another file to check ??

Thanks
Steve,


Can you ping the dns servers?

Can you reach the dns servers?
telnet 192.168.4.7 53

Also check your /etc/nsswitch.conf to see if the line for hosts looks
someting like this:
hosts: files dns


Kind regards,


Jan Gerrit Kootstra


Hi Jan,

Well..

Telnet 192.168.4.7 53 -> NO ... seems NOT to work ? It says...
trying.....

DNS IP Address from provider...
telnet 158.152.1.58 53 -> yes... then "close by host"
telnet 158.152.1.43 43 -> yes
telnet 62.241.163.200 -> yes

/etc/nsswitch.conf

passwd: files
shadow: files
group: files

hosts: file dns

ethers: files
netmask: files
( and so on....)

( nothing else.. is that normal ?)



Steve,

I have a router with 2 ADSL. -> I have setup on the router 2 DNS IP
address to fill in.
- ONE is with the ADSL n#1
- the second one is from the the ADSL n#2

On my CentOS machine, into my Ne I have set up :
1st DNS IP : I place the router IP address
2nd DNS IP : I place one of my DNS provider
3rd DNS IP : I place one of my DNS provider ( from the 2nd provider )

Now, I found that this machine could access Internet, even being a bit
slow...

into /etc/resolv.conf
nameserver 192.168.4.7 ( IP addres router )

nameserver 62.xx.dd.ee ( DNS IP addess of Provider1)
nameserver 212.xx.vv.ee ( DNS IP addess of Provider2)

Now, If I write in command line :
dig yahoo.com - fine I've got some info

host yahoo.com -> Host yahoo.com not found: 5(REFUSED ) ? ????!?!?!?!?

- Any idea what could be the problem ?

- Is there another file to check ??

On Wed, 25 Mar 2009, in the Usenet newsgroup linux.redhat, in article
CKmyl.162146$de5.39499 at (no spam) newsfe10.ams2>, Steve wrote:

I have a router with 2 ADSL. -> I have setup on the router 2 DNS IP
address to fill in.
- ONE is with the ADSL n#1
- the second one is from the the ADSL n#2

On my CentOS machine, into my Ne I have set up :
1st DNS IP : I place the router IP address
2nd DNS IP : I place one of my DNS provider
3rd DNS IP : I place one of my DNS provider ( from the 2nd provider )

OK - that's a nice invitation to failure. First problem is that DNS
believes any answer it receives - even when that answer is "I don't
know". Thus, any server you query must be able to provide ALL answers
to all questions. Second, many providers don't like to waste resources
providing services to _NON-CUSTOMERS_ and it looks as if you've set up
that problem.

Now, I found that this machine could access Internet, even being a bit
slow...

A packet sniffer would be useful here. This slowness _could_ be due to
a number of different reasons - IPv6, asking the "wrong server", etc.

into /etc/resolv.conf
nameserver 192.168.4.7 ( IP addres router )

"Ask the router" If the router provides ANY answer (address OR one of
the error codes like NXDOMAIN - game ends here.

nameserver 62.xx.dd.ee ( DNS IP addess of Provider1)
nameserver 212.xx.vv.ee ( DNS IP addess of Provider2)

"Ask the ISPs". Problem here _MAY_ be if you use the Provider 1
address to ask the name server of Provider 2 (or vice-versa), the
provider may tell you to fsck-off as you're obviously not a customer.

Now, If I write in command line :
dig yahoo.com - fine I've got some info

Dig usually tells you which name server it's using. Is it the "right"
one for the IP address you are using to speak to it?

host yahoo.com -> Host yahoo.com not found: 5(REFUSED ) ? ????!?!?!?!?

From RFC1035 page 27

RCODE Response code - this 4 bit field is set as part of
responses. The values have the following
interpretation:

0 No error condition
[...]
5 Refused - The name server refuses to
perform the specified operation for
policy reasons. For example, a name
server may not wish to provide the
information to the particular requester,
or a name server may not wish to perform
a particular operation (e.g., zone
transfer) for particular data.

- Any idea what could be the problem ?

ONE interpretation of the result is that you asked ISP One for a
hostname that is not part of their domain, but you asked from an
address that belongs to ISP Two.

- Is there another file to check ??

Firewall rules? Only ask DNS.ISP.ONE questions from IP.AD.ISP.ONE
and only ask DNS.ISP.TWO questions from IP.AD.ISP.TWO.

What might be an easier choice is to run your own recursive name server
and have it do all resolving (starting at x.ROOT-SERVERS.NET, and
recursively following the chain down to the authoritative name server)
as described in the DNS-HOWTO.

Old guy

Moe Trin wrote:

Steve wrote:

From RFC1035 page 27

5 Refused - The name server refuses to
perform the specified operation for
policy reasons. For example, a name
server may not wish to provide the
information to the particular requester,

- Is there another file to check ??

Firewall rules? Only ask DNS.ISP.ONE questions from IP.AD.ISP.ONE
and only ask DNS.ISP.TWO questions from IP.AD.ISP.TWO.

At the moment, I don't have a bad behaviour now. I just remove
192.168......

OK, I see the picture... DNS from the provider ONE, asking for DNS from
the provider 2
But I am using a Router with 2 WAN ( -> ISP provider ) and I am using
load balancing... so I can't tell you which one I will use ??!?!

May be I should have a look more deeply into a DNS Server...
That may be the solution....

On Wed, 25 Mar 2009, in the Usenet newsgroup linux.redhat, in article
49CAA850.6030004 at (no spam) nobody.com>, Steve wrote:

Moe Trin wrote:

Steve wrote:

From RFC1035 page 27

5 Refused - The name server refuses to
perform the specified operation for
policy reasons. For example, a name
server may not wish to provide the
information to the particular requester,

- Is there another file to check ??
Firewall rules? Only ask DNS.ISP.ONE questions from IP.AD.ISP.ONE
and only ask DNS.ISP.TWO questions from IP.AD.ISP.TWO.

At the moment, I don't have a bad behaviour now. I just remove
192.168......

I'm a network guy, so I'm used to using a packet sniffer. This will
almost always provide the clues needed to diagnose the problem. Using
the common tcpdump command

/usr/sbin/tcpdump -n -s 512 port 53

gets both the UDP and TCP traffic to/from port 53. Things to look at
is what question are you asking _from_ which address, _to_ which DNS
server, and what (if any) reply do you get. Problems are usually quite
obvious from even that minimal data.

If your 192.168.x.x name server only knows the 192.168.x.x addresses,
AND it's not forwarding requests it doesn't know, then when you ask
for www.google.com, it can truly answer NXDOMAIN - the hostname or
IP doesn't exist. The result is your client saying "never heard of it"
rather than asking a different name server. The client _got_ an
answer - it just happens to be wrong, but it _is_ an answer. You run
into the same problem asking an outside name server about your RFC1918
addresses. The remote says 'NXDOMAIN, and the game is over.

The solution there is to run a full service name server that is
authoritative for your RFC1918 addresses AND knows how to ask someone
else for other addresses. Point all of your clients at this server,
so they always get a "NOERROR' response.

OK, I see the picture... DNS from the provider ONE, asking for DNS from
the provider 2
But I am using a Router with 2 WAN ( -> ISP provider ) and I am using
load balancing... so I can't tell you which one I will use ??!?!

Are you asking from RFC1918 addresses that are masqueraded, or are you
asking from "real" addresses such as "83.104.224.24" which is owned by
Demon? You wouldn't want to ask a Orange, or BT name server to resolve
(example) www.google.com from a Demon address - obviously you aren't a
customer of BT or Orange if you're using a Demon IP, and they're well
in their right to tell you to "go elsewhere". That would be a logical
explanation for a '5' or 'REFUSED' result code.

Load balancing isn't always a good idea - especially if asking the
"wrong" name server. I don't know how you are doing load balancing,
but there should be a way to only forward DNS queries to the correct
name server (use a Demon address when talking to the Demon nameserver,
an Orange address for Orange, BT for BT and so on). Exactly how would
depend on the software you are using for load balancing.

May be I should have a look more deeply into a DNS Server...
That may be the solution....

Running a full name server is more likely to succeed. Your _traffic_
to resolve names is going over someone's wires, but as it's not
asking the wire owner to resolve a "foreign" name, you won't have the
conflict. Also, most name servers do caching of results, so the hosts
on your network will have better performance. The cost? Depends on
how diverse your name requests are - your name server may want more
memory to cache the answers.

Old guy
Old Guy,

Moe Trin schreef:

I'm a network guy, so I'm used to using a packet sniffer. This will
almost always provide the clues needed to diagnose the problem. Using
the common tcpdump command

/usr/sbin/tcpdump -n -s 512 port 53

gets both the UDP and TCP traffic to/from port 53. Things to look at
is what question are you asking _from_ which address, _to_ which DNS
server, and what (if any) reply do you get. Problems are usually quite
obvious from even that minimal data.

I think the DNS server might not be running anymore.

On Thu, 26 Mar 2009, in the Usenet newsgroup linux.redhat, in article
8ccd4$49cb2768$d55d2be5$9480 at (no spam) news.chello.nl>, Jan Gerrit Kootstra wrote:

Moe Trin schreef:

I'm a network guy, so I'm used to using a packet sniffer. This will
almost always provide the clues needed to diagnose the problem. Using
the common tcpdump command

/usr/sbin/tcpdump -n -s 512 port 53

gets both the UDP and TCP traffic to/from port 53. Things to look at
is what question are you asking _from_ which address, _to_ which DNS
server, and what (if any) reply do you get. Problems are usually quite
obvious from even that minimal data.

I think the DNS server might not be running anymore.

That's a reason to use a packet sniffer such as tcpdump as shown above.

If there is no name server at address $FOO, sending a DNS query will
result in one of two responses, depending on the firewall on the system
being queried. No DNS server (and no firewall) _OR_ a firewall that
rejects connections:

client -> DNS server "What is the IP address of $BAR"
DNS server -> client "Go away kid - you're bothering me"[1]

If there is a firewall, and it is set to "DROP" unwanted packets:

client -> DNS server "What is the IP address of $BAR"

which is to say - nothing comes back at all. Generally, the client
will make three attempts to ask to each DNS server listed in the
/etc/resolv.conf file. If you have the 'avahi' multicast DNS crap
installed and running (definitely NOT recommended) on the client, it
will also send a mDNS query to address 224.0.0.251 (and FF02::FB if
you are using IPv6) port 5353. Depending on the configuration of
/etc/nsswitch.conf, this mDNS query usually occurs before the normal
DNS query. Each time the resolver sends a mDNS or DNS query and
receives no response (black hole), the resolver waits for a response
before trying something else, or giving up. This is the normal cause
of 'slow" connections. Note that if your system has IPv6 enabled,
there are a lot of b0rken name servers out there that will ignore
an IPv6 query (AAAA record), but WILL respond in some manner to an
IPv4 query (A record) for the same hostname. IPv6 enabled clients
ask for an AAAA record first, and if none exists (NXDOMAIN or NODATA)
or after the timeout, will ask for an A record. This is a common
problem (RFC4074),

If there _is_ a name server and no firewall rules in the way, the DNS
server will give one of three[2] responses:

DNS server -> client "$BAR is at 192.0.2.143 NOERROR" (result code 0)

or

DNS server -> client "$BAR NXDOMAIN" (result code 3)

or

DNS server -> client "REFUSED" (result code 5)

In the first case, you got your answer - go talk to that host. In
the second case (NXDOMAIN), the name server is saying that the
hostname/address does not exist. The resolver believes this, and
will not ask anyone else. The application on the client will give a
message that says "never heard of it", and that's the end of that.
In the third case (REFUSED), the client _may_ (or may not) try to
ask a different server, but this is resolver library dependent.

Old guy

[1] ICMP Type 3 Code 3 (port unreachable) = "Nobody listening here"
[2] RFC1035 lists six result codes [0-5]. RFC2136 expands on this, and
adds five additional result codes [6-10]. RFC2308 adds a twelfth
result - the pseudo-code "NODATA" (coded as a zero which means NOERROR
but having all data fields empty). How your resolver handles these
other codes depends on the resolver library design.
Old guy,

Moe Trin schreef:
On Thu, 26 Mar 2009, in the Usenet newsgroup linux.redhat, in article
8ccd4$49cb2768$d55d2be5$9480 at (no spam) news.chello.nl>, Jan Gerrit Kootstra wrote:

Moe Trin schreef:

I'm a network guy, so I'm used to using a packet sniffer. This will
almost always provide the clues needed to diagnose the problem. Using
the common tcpdump command

/usr/sbin/tcpdump -n -s 512 port 53

gets both the UDP and TCP traffic to/from port 53. Things to look at
is what question are you asking _from_ which address, _to_ which DNS
server, and what (if any) reply do you get. Problems are usually quite
obvious from even that minimal data.

I think the DNS server might not be running anymore.

That's a reason to use a packet sniffer such as tcpdump as shown above.

If there is no name server at address $FOO, sending a DNS query will
result in one of two responses, depending on the firewall on the system
being queried. No DNS server (and no firewall) _OR_ a firewall that
rejects connections:

client -> DNS server "What is the IP address of $BAR"
DNS server -> client "Go away kid - you're bothering me"[1]

If there is a firewall, and it is set to "DROP" unwanted packets:

client -> DNS server "What is the IP address of $BAR"

which is to say - nothing comes back at all. Generally, the client
will make three attempts to ask to each DNS server listed in the
/etc/resolv.conf file. If you have the 'avahi' multicast DNS crap
installed and running (definitely NOT recommended) on the client, it
will also send a mDNS query to address 224.0.0.251 (and FF02::FB if
you are using IPv6) port 5353. Depending on the configuration of
/etc/nsswitch.conf, this mDNS query usually occurs before the normal
DNS query. Each time the resolver sends a mDNS or DNS query and
receives no response (black hole), the resolver waits for a response
before trying something else, or giving up. This is the normal cause
of 'slow" connections. Note that if your system has IPv6 enabled,
there are a lot of b0rken name servers out there that will ignore
an IPv6 query (AAAA record), but WILL respond in some manner to an
IPv4 query (A record) for the same hostname. IPv6 enabled clients
ask for an AAAA record first, and if none exists (NXDOMAIN or NODATA)
or after the timeout, will ask for an A record. This is a common
problem (RFC4074),

If there _is_ a name server and no firewall rules in the way, the DNS
server will give one of three[2] responses:

DNS server -> client "$BAR is at 192.0.2.143 NOERROR" (result code 0)

or

DNS server -> client "$BAR NXDOMAIN" (result code 3)

or

DNS server -> client "REFUSED" (result code 5)

In the first case, you got your answer - go talk to that host. In
the second case (NXDOMAIN), the name server is saying that the
hostname/address does not exist. The resolver believes this, and
will not ask anyone else. The application on the client will give a
message that says "never heard of it", and that's the end of that.
In the third case (REFUSED), the client _may_ (or may not) try to
ask a different server, but this is resolver library dependent.

Old guy

[1] ICMP Type 3 Code 3 (port unreachable) = "Nobody listening here"
[2] RFC1035 lists six result codes [0-5]. RFC2136 expands on this, and
adds five additional result codes [6-10]. RFC2308 adds a twelfth
result - the pseudo-code "NODATA" (coded as a zero which means NOERROR
but having all data fields empty). How your resolver handles these
other codes depends on the resolver library design.
Old guy,


The disadvantage of tcpdump is: one needs to understand the output.
Wireshark makes it a little easier to read.

Not every Linux specialist is a network specialist.


Kind regards,


Jan Gerrit Kootstra
P.S. Why do you snip my contribution to the discussion without marking
it as a snip.

Moe Trin wrote:
On Wed, 25 Mar 2009, in the Usenet newsgroup linux.redhat, in article
CKmyl.162146$de5.39... at (no spam) newsfe10.ams2>, Steve wrote:

I have a router with 2 ADSL. -> I have setup on the router 2 DNS IP
address to fill in.
- ONE is with the ADSL n#1
- the second one is from the the ADSL n#2

On my CentOS machine, into my Ne I have set up  :
1st DNS IP : I place the router IP address
2nd DNS IP : I place one of my DNS provider
3rd DNS IP : I place one of my DNS provider ( from the 2nd provider )

OK - that's a nice invitation to failure.  First problem is that DNS
believes any answer it receives - even when that answer is "I don't
know". Thus, any server you query must be able to provide ALL answers
to all questions.  Second, many providers don't like to waste resources
providing services to _NON-CUSTOMERS_ and it looks as if you've set up
that problem.

Now, I found that this machine could access Internet, even being a bit
slow...

A packet sniffer would be useful here.  This slowness _could_ be due to
a number of different reasons - IPv6, asking the "wrong server", etc.

into /etc/resolv.conf
nameserver 192.168.4.7  ( IP addres router )

"Ask the router"  If the router provides ANY answer (address OR one of
the error codes like NXDOMAIN - game ends here.

nameserver 62.xx.dd.ee  ( DNS IP addess of Provider1)
nameserver 212.xx.vv.ee  ( DNS IP addess of Provider2)

"Ask the ISPs".   Problem here _MAY_ be if you use the Provider 1
address to ask the name server of Provider 2 (or vice-versa), the
provider may tell you to fsck-off as you're obviously not a customer.

Now, If I write in command line :
dig yahoo.com  - fine I've got some info

Dig usually tells you which name server it's using. Is it the "right"
one for the IP address you are using to speak to it?

host yahoo.com  -> Host yahoo.com not found: 5(REFUSED )  ? ????!?!?!?!?

From RFC1035 page 27

RCODE           Response code - this 4 bit field is set as part of
                responses.  The values have the following
                interpretation:

                0               No error condition
[...]
                5               Refused - The name server refuses to
                                perform the specified operation for
                                policy reasons.  For example, a name
                                server may not wish to provide the
                                information to the particular requester,
                                or a name server may not wish to perform
                                a particular operation (e.g., zone
                                transfer) for particular data.

- Any idea what could be the problem ?

ONE interpretation of the result is that you asked ISP One for a
hostname that is not part of their domain, but you asked from an
address that belongs to ISP Two.

- Is there another file to check ??

Firewall rules?   Only ask DNS.ISP.ONE questions from IP.AD.ISP.ONE
and only ask DNS.ISP.TWO questions from IP.AD.ISP.TWO.

What might be an easier choice is to run your own recursive name server
and have it do all resolving (starting at x.ROOT-SERVERS.NET, and
recursively following the chain down to the authoritative name server)
as described in the DNS-HOWTO.

        Old guy

Hi Guys,

At the moment, I don't have a bad behaviour now. I just remove 192.168.......

OK, I see the picture... DNS from the provider ONE, asking for DNS from
the provider 2
But I am using a Router with 2 WAN ( -> ISP provider ) and I am using
load balancing... so I can't tell you which one I will use ??!?!

May be I should have a look more deeply into a DNS Server...
That may be the solution....