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

Help on NXDOMAIN to try next forwarder in the list

1,687 views
Skip to first unread message

sumsum 2000

unread,
May 30, 2013, 3:26:49 AM5/30/13
to bind-...@lists.isc.org
Hi,
I have the following change to be available from BIND9.

I have zone forwarders as follows with BIND9 setup with forward only option on a Non Authoritative DNS server

zone  "mytestdomain101.com" IN  {
        type forward;
        forwarders {8.8.8.8;4.2.2.1;8.8.4.4};
        forward only;
};


If I am doing a dig on mytestdomain101.com, the first DNS server gives NXDOMAIN. In this example, say it tries 8.8.8.8 and returns. I would want the other servers 4.2.2.1 and 8.8.4.4 to be tried and then finally return NXDOMAIN to have the same functionality as that of the SERVFAIL.

This is not currently possible and I have tried it on BIND9.8.2  version.
Could you please suggest if there is a way to do it.

Thanks
Sum2hike
 

Steven Carr

unread,
May 30, 2013, 3:35:23 AM5/30/13
to bind-users
It's not possible. NXDOMAIN is NXDOMAIN, it doesn't exist, it doesn't
mean try another server to see if you get lucky next time.

Steve
> _______________________________________________
> 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

Ashok Agarwal

unread,
May 30, 2013, 3:55:01 AM5/30/13
to Steven Carr, bind-users
One possible way can also be to set the number of nameservers to be looked upon in the /etc/hosts file.

nameserver 8.8.8.8
nameserver 4.4.2.2
nameserver 4.1.2.2

Regards,
Ashok
--
Ashok

Ashok Agarwal

unread,
May 30, 2013, 3:56:26 AM5/30/13
to Steven Carr, bind-users
Sorry, its not /etc/hosts file rather its /etc/resolv.conf.
--
Ashok

Sten Carlsen

unread,
May 30, 2013, 4:22:16 AM5/30/13
to bind-...@lists.isc.org
Well you can do that.

It does not change the fact that NXDOMAIN is a DEFINITIVE answer - it does not exist, there is no reason to look further.
-- 
Best regards

Sten Carlsen

No improvements come from shouting:
       "MALE BOVINE MANURE!!!"

sumsum 2000

unread,
May 30, 2013, 5:30:08 AM5/30/13
to Sten Carlsen, bind-...@lists.isc.org
Hi,
This is a non-standard behavior and  I would like to have the following:
In the case where I am working on,
 /etc/resolv.conf  contains localhost 127.0.0.1  and BIND is listening on localhost port 53 as non-authoritative DNS

So all the requests are sent through 127.0.0.1 and based on the domain they are in forward only mode.

There are specific domains for eg mygeo1.mycompany.com. There are specific authoritative  DNS servers which contain this record.
mygeo1.mycompany.com  is forwarded to myDNS1.mycompany.com, myDNS2.mycompany.com, myDNS3.mycompany.com which are specific authoritative DNS servers to mycompany.com But administrator does not know which one has it
The option is to change BIND code to have this behavior. I  wanted to check if there is some patch/way to get this done.
Thanks
Sum2hike

Steven Carr

unread,
May 30, 2013, 5:49:53 AM5/30/13
to bind-users
So your administrator is breaking DNS if all 3 servers have been added
as NS records but the zone is not available on all 3 servers. Get
him/her to fix your DNS hierarchy first then you wont need to check
which server is hosting the subdomain.

Steve

Barry Margolin

unread,
May 30, 2013, 10:05:24 AM5/30/13
to comp-protoc...@isc.org
In article <mailman.383.1369900...@lists.isc.org>,
Ashok Agarwal <ashokaga...@gmail.com> wrote:

> Sorry, its not */etc/hosts* file rather its */etc/resolv.conf*.
>
>
> On Thu, May 30, 2013 at 1:25 PM, Ashok Agarwal
> <ashokaga...@gmail.com>wrote:
>
> > One possible way can also be to set the number of nameservers to be looked
> > upon in the /etc/hosts file.
> >
> > nameserver 8.8.8.8
> > nameserver 4.4.2.2
> > nameserver 4.1.2.2

No. /etc/resolv.conf failover only happens on errors, not NXDOMAIN
responses.

--
Barry Margolin
Arlington, MA

Matus UHLAR - fantomas

unread,
May 31, 2013, 3:35:32 AM5/31/13
to bind-...@lists.isc.org
On 30.05.13 12:56, sumsum 2000 wrote:
>I have zone forwarders as follows with BIND9 setup with forward only option
>on a Non Authoritative DNS server
>
>zone "mytestdomain101.com" IN {
> type forward;
> forwarders {8.8.8.8;4.2.2.1;8.8.4.4};
> forward only;
>};

On 30.05.13 15:00, sumsum 2000 wrote:
>This is a non-standard behavior and I would like to have the following:
>In the case where I am working on,
> /etc/resolv.conf contains localhost 127.0.0.1 and BIND is listening on
>localhost port 53 as non-authoritative DNS
>
>So all the requests are sent through 127.0.0.1 and based on the domain they
>are in forward only mode.

There is no point in forwarding just one domain to google recursive servers.
Either forward ALL domains there (but in such case you could simply avoid
local BIND and point resolv.conf to google), or point the domain directly to
its servers instead of google.

Since BIND 9.8 and you can do it by using "type static-stub" instead of type
forward and use server-addresses instead of forwarders.

>There are specific domains for eg mygeo1.mycompany.com. There are specific
>authoritative DNS servers which contain this record.

If you are trying to say that some of authoritative servers for a domain do
know about one record and others do not know, then the servers and the
domain are broken and they need to be fixed.

>mygeo1.mycompany.com is forwarded to myDNS1.mycompany.com,
>myDNS2.mycompany.com, myDNS3.mycompany.com which are specific authoritative
>DNS servers to mycompany.com But administrator does not know which one has
>it

So, is that mytestdomain101.com or mycompany.com or mygeo1.mycompany.com?
It would be easier to look at the problem if you provided us correct data.

--
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.
42.7 percent of all statistics are made up on the spot.

sumsum 2000

unread,
May 31, 2013, 7:11:25 AM5/31/13
to bind-...@lists.isc.org
Hi,
The google DNS server was only examples.. it can be some internal DNS servers and external DNS servers. For eg 10.10.10.10; 120.10.13.12 etc. where the DNS requests are being forwarded to..

There are issues with connectivity where the DNS entries are not synced up. And these entries are all specific to  say "mycompany.com" where the DNS are residing in several locations..
So when my local DNS is returning NXDOMAIN, the other locations which might have the entries are not tried.

the example mytestdomain101.mycompany.com is an example where my list is 10.10.10.10; 120.10.13.12 for example..  i try 10.10.10.10 - NXDOMAIN returned.. i want to try 120.10.13.12 before sending NXDOMAIN to my initial request.

I hope this helps.
Thanks





42.7 percent of all statistics are made up on the spot. _______________________________________________

Matus UHLAR - fantomas

unread,
May 31, 2013, 8:01:18 AM5/31/13
to bind-...@lists.isc.org
On 31.05.13 16:41, sumsum 2000 wrote:
>The google DNS server was only examples.. it can be some internal DNS
>servers and external DNS servers. For eg 10.10.10.10; 120.10.13.12 etc.
>where the DNS requests are being forwarded to..

Then it was bad example. You use "type forward" when you want to ask other
server to recursively resolve the domain instead of yours.the example with
google servers even supported this case.
As I have stated in my previous e-mail, you can use "type static-stub" if
you want specific server to answer your questions (non-recursively).

>There are issues with connectivity where the DNS entries are not synced up.

How long do the issues usually persist? What kind are they, slaves not
fetching from master? Or do you use forwarders and they return NXDOMAIN?
In the first case you need to fix connectivity issues or make them less
important, in the second lower your SOA "minimum" value (which affects the
negative TTL)

>And these entries are all specific to say "mycompany.com" where the DNS
>are residing in several locations..
>So when my local DNS is returning NXDOMAIN, the other locations which might
>have the entries are not tried.
>
>the example mytestdomain101.mycompany.com is an example where my list is
>10.10.10.10; 120.10.13.12 for example.. i try 10.10.10.10 - NXDOMAIN
>returned.. i want to try 120.10.13.12 before sending NXDOMAIN to my initial
>request.

This was answered already: It's impossible and illogical to ask again if
someone replies THERE IS NO SUCH RECORD. You need to fix your DNS
infrastructure, not try to circumvent it's issues.

--
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.
Honk if you love peace and quiet.

John Wobus

unread,
May 31, 2013, 11:31:47 AM5/31/13
to bind-users
I will add my +1:

NXDOMAIN does not mean "I don't have a number for that name but
someone else
might." It means "The DNS lists this name as having no number (or
whatever)."
There's no more reason to look further than if you got a positive
answer from one server and still wondered if some other DNS server
might say something else. You might just as well recheck positive
A-record answers with other servers because they might say NXDOMAIN.

The only reason to look further is if you are monitoring
for inconsistencies/brokenness.

"Settling time" is an issue, e.g. when you don't have an
effective NOTIFY authoritative servers temporarily disagree
for a significant interval. Still, if you get two answers
(one NXDOMAIN and one A record) from servers, there is no
way to tell which is "correct", just as if you got two different
A-record answers. It's up to the zone's maintainer to assure
the (hopefully temporary) inconsistency doesn't cause issues.

John Wobus
Cornell Univ IT

Barry Margolin

unread,
May 31, 2013, 12:13:20 PM5/31/13
to comp-protoc...@isc.org
In article <mailman.395.1370014...@lists.isc.org>,
Theoretically, clients could query multiple servers, and we could have
required them to include the SOA serial number in all replies, and the
client could select the answer with the highest serial.

But that's not how the protocol was designed. DNS makes a trade-off
between overhead and perfection -- it makes extensive use of caching,
and it's understood that there will be windows during which different
clients may have different views of a record. TTLs, refresh times, and
NOTIFY allow DNS administrators to limit the size of those windows.
Application developers are expected to work around this at higher
levels, as best they can.
0 new messages