Forward zone giving SERVFAIL

[Neil Aggarwal]

Hello:

I set up a forward zone in the internal view of my named.conf:

view internal {
match-clients {
127.0.0.1;
};
recursion yes;
allow-query-cache { any; };
zone "dnsbl" {
type forward;
forwarders {
127.0.0.1 port 54;
};
forward only;
};
};

When I run dig against the forward zone:
dig -p 54 @127.0.0.1 2.0.0.127.zen.dnsbl

It gives me the expected output:
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6_4.6 <<>> -p 54 @127.0.0.1
2.0.0.127.zen.dnsbl
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57571
;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;2.0.0.127.zen.dnsbl. IN A

;; ANSWER SECTION:
2.0.0.127.zen.dnsbl. 300 IN A 127.0.0.2
2.0.0.127.zen.dnsbl. 300 IN A 127.0.0.10
2.0.0.127.zen.dnsbl. 300 IN A 127.0.0.4

;; Query time: 1 msec
;; SERVER: 127.0.0.1#54(127.0.0.1)
;; WHEN: Wed Nov 27 21:24:45 2013
;; MSG SIZE rcvd: 85

But, when I run dig against bind:
dig -p 53 @127.0.0.1 2.0.0.127.zen.dnsbl

I get a SERVFAIL response:
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6_4.6 <<>> -p 53 @127.0.0.1
2.0.0.127.zen.dnsbl
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 46895
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;2.0.0.127.zen.dnsbl. IN A

;; Query time: 144 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Nov 27 21:25:50 2013
;; MSG SIZE rcvd: 37

Taking a look at /var/named/data/named.run, I see these lines:
error (chase DS servers) resolving 'zen.dnsbl/DS/IN': 127.0.0.1#54
error (unexpected RCODE REFUSED) resolving 'dnsbl/NS/IN': 127.0.0.1#54
error (no valid DS) resolving '2.0.0.127.zen.dnsbl/A/IN': 127.0.0.1#54

I am not sure what to make of this.

Anyone have any ideas?

Thanks,
Neil

--
Neil Aggarwal, (972) 834-1565
We lend money to investors to buy or refinance single family rent houses.
No origination fees, quick approval, no credit check.

[Dave Warren]

On 2013-11-27 19:27, Neil Aggarwal wrote:
> Anyone have any ideas?

This is a shot in the dark, but is your server carrying a root zone or
using hints? I vaguely recall running into similar a few weeks back when
rolling out a new mail server, it turned out that the server was
configured as a root server (with a copy of the root zone) and this
broke forwards to a local rdnsbld on :54.

Since no one could remember why our mail servers had root zones and it
didn't seem to make any practical difference, we switched over to using
hints and suddenly forwards started working too.

Or so my memory recalls, there were so many minor disasters during
testing on that roll-out that I might have some details off in my brain,
but if this doesn't help, I'll ask around and see.

--
Dave Warren
http://www.hireahit.com/
http://ca.linkedin.com/in/davejwarren

[Neil Aggarwal]

Dave:

> This is a shot in the dark, but is your server carrying a root zone or
> using hints? I vaguely recall running into similar a few weeks back when

Bind complained about the pre-defined zones not being in a view when
I added my views so I removed them.

I added the following to my /var/named/named.zones file:

zone "." in{
type hint;
file "named.ca";
};

include "/etc/named.rfc1912.zones";

I restarted named and I am still getting the SERVFAIL error.

It looks like having those zones is not making a difference.

Thanks,
Neil

--
Neil Aggarwal, (972)834-1565, http://UnmeteredVPS.net/centos
Virtual private server with CentOS 6 preinstalled
Unmetered bandwidth = no overage charges

[Sten Carlsen]

IIRC "forward" means ask the forwarder to do a recursive lookup. If the server you forward to does not do recursion, there is a problem here.

I think the advice is to look at stub zones, they might be useful here.

Virtual private server with CentOS 6 preinstalled
Unmetered bandwidth = no overage charges

_______________________________________________
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

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!" 

[Mark Andrews]

You have DNSSEC enabled and the root zone is signed in a way that
prevents the addition of rougue TLDs which 'dnsbl' is. This is a
good thing with ICANN adding lots of new TLDs.

In addition to that the alternate nameserver on port 54 doesn't
handle NS queries. Nameserver developers shouldn't assume that the
only queries that will be made to a nameserver will be A queries.
These days you have A and AAAA for addresses as well as NS, DS and
DNSKEY queries for DNSSEC. Then add in TLSA queries for DANE and
as browsers check for HTTPS support. The list of different query
types that regularly appear continues to grow. Nameserver should
expect the unexpected. It really isn't any harder to send a NODATA
response rather than a REFUSED.

I suggest that you report this to the black list and nameserver
vendors. Squatting on TLD's is a no-no. If they want a TLD for
their service they should pony up the money otherwise move the name
into namespace they control. Doing a half backed nameserver will
cause operational problems. All zones are supposed to have NS and
SOA records so there is no excuse for not supporting them. As for
the other qtypes NODATA or NXDOMAIN should be returned depending
upon whether the name exists in the zone or not. Simlarly NODATA
or NXDOMAIN should be returned for NS and SOA not at the zone apex.

A nameserver doesn't have to support returning all types but it
should say that they don't exist rather than cop out with NOTIMP
or REFUSED which just cause recursive servers to move onto the next
listed server and eventually return SERVFAIL to the client.

Mark

> Anyone have any ideas?
>
> Thanks,
> Neil
>
> --

> Neil Aggarwal, (972) 834-1565
> We lend money to investors to buy or refinance single family rent houses.
> No origination fees, quick approval, no credit check.
>
>
>

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

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