Bind sometimes SERVFAIL

[Pawel Rutkowski]

Hello,

My Internet ISP give two nameservers address.
But when I'm asking those two servers sometimes I get:
[root@linux ~]# host d.yimg.com ns.my.isp
Using domain server:
Name: ns.my.isp
Address: ns.my.isp#53
Aliases:
Host d.yimg.com not found: 2(SERVFAIL)

but sometimes I get:

[root@linux ~]# host d.yimg.com ns.my.isp
Using domain server:
Name: ns.my.isp
Address: ns.my.isp#53
Aliases:
d.yimg.com is an alias for geoycs-d.gy1.b.yahoodns.net.
geoycs-d.gy1.b.yahoodns.net is an alias for fo-anyycs-d.ay1.b.yahoodns.net.
fo-anyycs-d.ay1.b.yahoodns.net has address 98.137.80.54

He explain me this thats a normal because of this:
http://www.faqs.org/rfcs/rfc2308.html
Some resolvers incorrectly continue processing if the authoritative
answer flag is not set, looping until the query retry threshold is
exceeded and then returning SERVFAIL. This is a problem when your
nameserver is listed as a FORWARDER for such resolvers. If the
nameserver is used as a FORWARDER by such resolver, the authority
flag will have to be forced on for NXDOMAIN responses to these
resolvers. In practice this causes no problems even if turned on
always, and has been the default behaviour in BIND from 4.9.3
onwards.

Is this true ?

Thanks
Pawel R.

[Gregory Hicks]

> From: "Pawel Rutkowski" <rut...@freelance-worker.net>
> To: <bind-...@lists.isc.org>
> Subject: Bind sometimes SERVFAIL
> Date: Wed, 11 Nov 2009 07:42:14 +0100

>
> Hello,
>
> My Internet ISP give two nameservers address.
> But when I'm asking those two servers sometimes I get:
> [root@linux ~]# host d.yimg.com ns.my.isp
> Using domain server:
> Name: ns.my.isp
> Address: ns.my.isp#53
> Aliases:
> Host d.yimg.com not found: 2(SERVFAIL)

I just saw the same thing:

metis% host d.timg.com
Host d.timg.com not found: 3(NXDOMAIN)
metis% !!
host d.timg.com
Host d.timg.com not found: 3(NXDOMAIN)
metis% host d.yimg.com

d.yimg.com is an alias for geoycs-d.gy1.b.yahoodns.net.
geoycs-d.gy1.b.yahoodns.net is an alias for
fo-anyycs-d.ay1.b.yahoodns.net.

fo-anyycs-d.ay1.b.yahoodns.net has address 98.137.88.88
metis% named -v
BIND 9.6.1-P1

Above executed in the space of about a minute...

>
> but sometimes I get:
>
> [root@linux ~]# host d.yimg.com ns.my.isp
> Using domain server:
> Name: ns.my.isp
> Address: ns.my.isp#53
> Aliases:
> d.yimg.com is an alias for geoycs-d.gy1.b.yahoodns.net.
> geoycs-d.gy1.b.yahoodns.net is an alias for
fo-anyycs-d.ay1.b.yahoodns.net.
> fo-anyycs-d.ay1.b.yahoodns.net has address 98.137.80.54
>
>
> He explain me this thats a normal because of this:
> http://www.faqs.org/rfcs/rfc2308.html
> Some resolvers incorrectly continue processing if the authoritative
> answer flag is not set, looping until the query retry threshold is
> exceeded and then returning SERVFAIL. This is a problem when your
> nameserver is listed as a FORWARDER for such resolvers. If the
> nameserver is used as a FORWARDER by such resolver, the authority
> flag will have to be forced on for NXDOMAIN responses to these
> resolvers. In practice this causes no problems even if turned on
> always, and has been the default behaviour in BIND from 4.9.3
> onwards.
>
> Is this true ?
>
> Thanks
> Pawel R.
>
>
>

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

---------------------------------------------------------------------
Gregory Hicks | Principal Systems Engineer
| Direct: 408.569.7928

People sleep peaceably in their beds at night only because rough men
stand ready to do violence on their behalf -- George Orwell

The price of freedom is eternal vigilance. -- Thomas Jefferson

"The best we can hope for concerning the people at large is that they
be properly armed." --Alexander Hamilton

[Jukka Pakkanen]

> Hello,
>
> My Internet ISP give two nameservers address.
> But when I'm asking those two servers sometimes I get:
> [root@linux ~]# host d.yimg.com ns.my.isp
> Using domain server:
> Name: ns.my.isp
> Address: ns.my.isp#53
> Aliases:
> Host d.yimg.com not found: 2(SERVFAIL)

I just saw the same thing:

metis% host d.timg.com
Host d.timg.com not found: 3(NXDOMAIN)
metis% !!
host d.timg.com
Host d.timg.com not found: 3(NXDOMAIN)
metis% host d.yimg.com
d.yimg.com is an alias for geoycs-d.gy1.b.yahoodns.net.
geoycs-d.gy1.b.yahoodns.net is an alias for
fo-anyycs-d.ay1.b.yahoodns.net.
fo-anyycs-d.ay1.b.yahoodns.net has address 98.137.88.88
metis% named -v
BIND 9.6.1-P1

Above executed in the space of about a minute...

---------------------------

timg <> yimg

[Stephane Bortzmeyer]

On Wed, Nov 11, 2009 at 01:27:30PM +0200,
Jukka Pakkanen <jukka.p...@qnet.fi> wrote

a message of 94 lines which said:

> I just saw the same thing:

There are no less than *four* CNAMEs to resolve to get to the result,
while even two is discouraged. It is not suprising that it may fails
with resolvers which limit the number of chained CNAME (to avoid
endless loops).

[Pawel Rutkowski]

Hello again,

>
>> I just saw the same thing:
>

Please look below, it's normal ? Sometime servfail, sometimes nxdomain.

[root@linux ~]# host 209.85.255.187 ns1.isp
Using domain server:
Name: ns1.isp
Address: ns1.isp#53
Aliases:

Host 187.255.85.209.in-addr.arpa not found: 2(SERVFAIL)
[root@linux ~]# host 209.85.255.187 ns1.isp
Using domain server:
Name: ns1.isp
Address: ns1.isp#53
Aliases:

Host 187.255.85.209.in-addr.arpa not found: 3(NXDOMAIN)
[root@linux ~]# host 209.85.255.187 ns1.isp
Using domain server:
Name: ns1.isp
Address: ns1.isp#53
Aliases:

Host 187.255.85.209.in-addr.arpa not found: 3(NXDOMAIN)

Thanks
Pawel R.

[Matus UHLAR - fantomas]

Use 'dig -x 209.85.255.187 @ns1.isp' and look at "NS" records and TTLs.
Invalid delegations and inconsistent NS records (domain is delegated from
parent to different servers than those listed in the domain) often cause
these kinds of problems.

--
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.
Emacs is a complicated operating system without good text editor.

[Kevin Darcy]

Generally speaking, it's not a good idea to use RFCs to diagnose
operational issues, unless you've already narrowed the problem down to
some sort of standard-conformance or interoperability issue.

What is described below is merely one of potentially *dozens* of
different causes of a SERVFAIL result.

Follow normal root-cause analysis. Eliminate variables/causes.
Understand and test dependencies. Get to the heart of the matter. If you
don't know how to do that personally, escalate to someone who does.

- Kevin

Pawel Rutkowski wrote:
> Hello,
>
> My Internet ISP give two nameservers address.
> But when I'm asking those two servers sometimes I get:
> [root@linux ~]# host d.yimg.com ns.my.isp
> Using domain server:
> Name: ns.my.isp
> Address: ns.my.isp#53
> Aliases:
> Host d.yimg.com not found: 2(SERVFAIL)
>

[Luis Daniel Lucio Quiroz]

I think I did have same problem
with 9.4.1p1, 9.5p2 and 9.6p1. Look

[dieu@brandmauer ~]$ host www.bbc.co.uk 127.0.0.1
Using domain server:
Name: 127.0.0.1
Address: 127.0.0.1#53
Aliases:

www.bbc.co.uk is an alias for www.bbc.net.uk.
www.bbc.net.uk has address 212.58.253.68
Host www.bbc.net.uk not found: 2(SERVFAIL)
[dieu@brandmauer ~]$

I did sniff connecction and It seems that the query that fails is a MX request
of www.bbc.net.mx. Odd thing.

When I ask to a exchange dns server, query is okay.

Is this a bug?

[Kevin Darcy]

Luis Daniel Lucio Quiroz wrote:
> Le mercredi 11 novembre 2009 09:15:12, Matus UHLAR - fantomas a �crit :

By default, "host" looks up A, AAAA and MX records, in that order.

> I did sniff connecction and It seems that the query that fails is a MX request
> of www.bbc.net.mx. Odd thing.
>
>

The delegated nameservers for bbc.net.uk are answering an MX query with
an A record:

$ dig www.bbc.net.uk mx @ns0.rbsov.bbc.co.uk +short
212.58.253.68
$ dig www.bbc.net.uk mx @ns0.thdo.bbc.co.uk +short
212.58.253.68

Really bad stuff, but this is a *persistent* condition, caused by the
domain owner(s), and probably not related to the issue reported by the
previous poster.

- Kevin