Forward type "only" no longer working (possibly a regression)?

Kevin Darcy kevin.darcy at fcagroup.com
Mon Oct 1 18:46:55 UTC 2018


You need to get to the root cause of what's causing the SERVFAIL.

Removing "forward only" just masks the problem by telling the resolver
algorithm to fail over to iterative resolution when it encounters the
SERVFAIL. So, sure, the query resolves, but probably not from the correct
server, and probably returns the wrong result. The SERVFAIL is the
proximate cause, and until you solve that, your forwarding to that server
isn't going to work.

Why this behavior changed from BIND 9.10.x to 9.13.x eludes me. It's a clue
to help you get to the root cause of the SERVFAIL, but only a clue. More
diagnosis and testing is required.


                            - Kevin

On Sat, Sep 29, 2018 at 7:45 PM Karol Babioch <karol at babioch.de> wrote:

> Hi,
>
> after upgrading my bind installation from 9.10.0 to 9.13.3 I'm
> encoutering issues with zones that are forwarded. My setup is somewhat
> complicated, but I was able to simplify it, so hopefully explanations.
>
> Basically I have a split horizon DNS, so on my local resolver I'm
> forwarding specific requests to an internal authoritative nameserver.
>
> The named.conf looks somewhat like this:
>
> > options {
> >     listen-on port 53 { 127.0.0.1; 10.24.0.1; };
> >     listen-on-v6 port 53 { ::1; };
> >     directory "/var/named";
> >     pid-file "/run/named/named.pid";
> >     recursion yes;
> >     allow-query { localhost; 10.24.0.0/16; };
> > };
> >
> > include "/etc/named.rfc1912.zones";
> > include "/etc/named.root.zone";
> >
> > zone "babioch.de" IN {
> >     type forward;
> >     forward only;
> >     forwarders { 10.24.0.10; };
> > };
>
> This used to work fine before the upgrade, but it fails now. When using
> this resolver, I'm running into the following issue:
>
> > dig @127.0.0.1 mail.babioch.de
> >
> > ; <<>> DiG 9.13.3 <<>> @127.0.0.1 mail.babioch.de
> > ; (1 server found)
> > ;; global options: +cmd
> > ;; Got answer:
> > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 28826
> > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
> >
> > ;; OPT PSEUDOSECTION:
> > ; EDNS: version: 0, flags:; udp: 4096
> > ; COOKIE: bfe2507f6ca6291e360aae925bb00ba55dc000437399d823 (good)
> > ;; QUESTION SECTION:
> > ;mail.babioch.de.             IN      A
> >
> > ;; Query time: 1 msec
> > ;; SERVER: 127.0.0.1#53(127.0.0.1)
> > ;; WHEN: So Sep 30 01:32:53 CEST 2018
> > ;; MSG SIZE  rcvd: 72
>
> As you can see the status is "SERVFAIL" and no response is returned. The
> query log for this contains the following information:
>
> > Sep 30 01:33:31 kvm1.babioch.de named[16298]: client @0x7ff0c40ad670
> 127.0.0.1#51022 (mail.babioch.de): query: mail.babioch.de IN A +E(0)K
> (127.0.0.1)
> > Sep 30 01:33:31 kvm1.babioch.de named[16298]: client @0x7ff0c40ad670
> 127.0.0.1#51022 (mail.babioch.de): query failed (SERVFAIL) for
> mail.babioch.de/IN/A at query.c:10672
>
> The line in question is handling stale answers [1]. I'm not entirely
> sure how this applies to my use-case, since nothing should be stale here.
>
> Interestingly enough I can get it working, when I'm removing the
> "forward only" directive from my configuration. This looks like this:
>
> > dig @127.0.0.1 mail.babioch.de
> >
> > ; <<>> DiG 9.13.3 <<>> @127.0.0.1 mail.babioch.de
> > ; (1 server found)
> > ;; global options: +cmd
> > ;; Got answer:
> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35694
> > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
> >
> > ;; OPT PSEUDOSECTION:
> > ; EDNS: version: 0, flags:; udp: 4096
> > ; COOKIE: 85a469a4288546b7b55ea9a65bb00cc92c9846104f77fdab (good)
> > ;; QUESTION SECTION:
> > ;mail.babioch.de.             IN      A
> >
> > ;; ANSWER SECTION:
> > mail.babioch.de.      300     IN      A       10.24.0.20
> >
> > ;; Query time: 129 msec
> > ;; SERVER: 127.0.0.1#53(127.0.0.1)
> > ;; WHEN: So Sep 30 01:37:45 CEST 2018
> > ;; MSG SIZE  rcvd: 88
>
> I definitely want the "forward only" directive to make sure that only
> nameservers specified in the "forwarders" directive are contacted - in
> all cases. This seems no longer to be possible. I couldn't find any
> description of this in the change log, so this seems to be a bug and/or
> regression to me.
>
> What do you think? Can anyone verify this? Am I missing or
> mis-understanding something here?
>
> Thank you very much!
>
> Best regards,
> Karol Babioch
>
> [1]:
>
> https://gitlab.isc.org/isc-projects/bind9/blob/v9_13_3/lib/ns/query.c#L10672
>
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20181001/b5890645/attachment.html>


More information about the bind-users mailing list