Re: stop on unrecognized qresult in rpz_rewrite()

2018-09-29 Thread Evan Hunt
On Sat, Sep 29, 2018 at 05:48:55PM -0400, Lee wrote:
> Can someone tell me what can cause
>   stop on unrecognized qresult in rpz_rewrite()failed:
> or how to fix whatever it was?

It's an interaction between RPZ and aggressive negative caching (i.e.
"synth-from-dnssec"). It's fixed in the upcoming release.

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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


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

2018-09-29 Thread Karol Babioch
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



signature.asc
Description: OpenPGP digital signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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


stop on unrecognized qresult in rpz_rewrite()

2018-09-29 Thread Lee
I tried to go to https://fpki.idmanagement.gov/ and got some error
message about not finding the site with a "try again" button.  Tried
again and it worked:

29-Sep-2018 15:56:21.677 queries: info: client @01F0C8672910
127.0.0.1#58997 (fpki.idmanagement.gov): query: fpki.idmanagement.gov
IN A + (127.0.0.1)
29-Sep-2018 15:56:21.708 query-errors: debug 1: client
@01F0C8672910 127.0.0.1#58997 (fpki.idmanagement.gov): rpz QNAME
rewrite dfew6wnpm1gb5.cloudfront.net via dfew6wnpm1gb5.cloudfront.net
stop on unrecognized qresult in rpz_rewrite()failed:  : SERVFAIL
29-Sep-2018 15:56:21.708 query-errors: info: client @01F0C8672910
127.0.0.1#58997 (fpki.idmanagement.gov): query failed (SERVFAIL) for
fpki.idmanagement.gov/IN/A at ..\query.c:8580

29-Sep-2018 15:56:34.893 queries: info: client @01F0C91812E0
127.0.0.1#51991 (fpki.idmanagement.gov): query: fpki.idmanagement.gov
IN A + (127.0.0.1)


I tried searching on the error message & got lots of pointers to
query.c but I haven't found anything that explains what happened.

I've got nothing for .net or .cloudfront.net in my rpz.zone file & the
rpz zone is configured as
   response-policy { zone "rpz.zone"  log yes; } break-dnssec yes
recursive-only no  qname-wait-recurse no;

Can someone tell me what can cause
  stop on unrecognized qresult in rpz_rewrite()failed:
or how to fix whatever it was?

Thanks
Lee
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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


Re: BIND and UDP tuning

2018-09-29 Thread Alex
Hi,

> DOCSIS cable systems use an upstream request/grant system to avoid
> collisions (they act as a hub where only one cable modem in the node can
> transmit at the same time). This leads to low pps rates compared with
> ethernet. Even a 10M ethernet connection (1k-10k pps) will outperform a
> 1gig cable connection (a few hundred pps).
>
> Based on the info you've provided, I suspect that you may be running
> into this limit. As another poster suggested, you might consider moving
> your DNS server to a VPS hosted on an ethernet connection at a location
> more suited for DNS server operation or otherwise try to leverage your
> upstream provider's DNS or an outside DNS server.

I remember hearing this some time ago, and had even made mention very
early on that I questioned if it was the cable itself.

However, I've tried using Optonline's DNS and the "Name service error"
errors from postfix continued. Could it be affecting that traffic as
well, considering effectively the same UDP packets are being
transferred?

I also used socat to build an encrypted tunnel between this system
connected to the cable modem and our VPS system, and the SERVFAIL
messages stopped. However, there are still quite a few "Name service
error" errors from postfix.

I realize this is bind-users, not a postfix list, but any idea if
those errors could also be due to it being a cable circuit?

Sep 29 14:33:54 mail03 postfix/dnsblog[3290]: warning: dnsblog_query:
lookup error for DNS query 123.139.28.66.dnsbl.sorbs.net: Host or
domain name not found. Name service error for
name=123.139.28.66.dnsbl.sorbs.net type=A: Host not found, try again

I'd really be interested in people's input here.

Thanks,
Alex
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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