Re: Forwarders working differently on bind9.8 & bind9.11
Hi Prashasti.
I'm on my phone, so I'll keep it brief.
- ditch both 9.8 and 9.11; install 9.18
- why are you forwarding to yourself? 127.0.0.1
- get binary packet captures and look at them in Wireshark to see what's
actually going on.
- real IPs please.
- why use "port xxx"?
Cheers, Greg
On Tue, 19 Sep 2023, 12:28 Prashasti Arora,
wrote:
> I have configured a new zone to forward certain queries to my application
> on 2 VMs (One local and the other in my network) through a specific port. I
> have 2 similar setups - they are identical, except that one uses bind9.8
> and the other uses bind9.11. Configuration is also identical for both.
>
> On the first setup (using bind9.8): the traffic I send gets distributed
> uniformly.
> On the second setup (using bind9.11): the traffic gets distributed barely.
> 99% of the traffic is sent to one VM.
>
> I have verified that forwarding is working correctly on both, the issue is
> not with the application because both VMs on each setup can handle traffic
> individually, the firewall is not blocking the queries, and the
> configuration is correct.
>
> This is the zone:
>
> zone "example.com" IN {
> type forward;
> forwarders { 127.0.0.1 port xxx; a.b.c.d port xxx; };
> forward only;
> };
>
>
> Please share any other possible solutions.
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Forwarders working differently on bind9.8 & bind9.11
On Tue, Sep 19, 2023 at 7:28 AM Prashasti Arora
wrote:
I have configured a new zone to forward certain queries to my application
on 2 VMs (One local and the other in my network) through a specific port. I
have 2 similar setups - they are identical, except that one uses bind9.8
and the other uses bind9.11. Configuration is also identical for both.
On the first setup (using bind9.8): the traffic I send gets distributed
uniformly.
On the second setup (using bind9.11): the traffic gets distributed barely.
99% of the traffic is sent to one VM.
BIND wants to get responses as soon as possible, thus it queries servers who
respond fastest.
BIND keeps track of how fast servers are responding, and which server
responds faster, will get queries more often.
Time to time, BIND re-checks other servers to see if they perform better,
because that can change over time.
What is the problem?
I have verified that forwarding is working correctly on both, the issue is
not with the application because both VMs on each setup can handle traffic
individually, the firewall is not blocking the queries, and the
configuration is correct.
This is the zone:
zone "example.com" IN {
type forward;
forwarders { 127.0.0.1 port xxx; a.b.c.d port xxx; };
forward only;
};
Please share any other possible solutions.
On 19.09.23 08:25, Bob Harold wrote:
Note that the 'forwarders' line, from the BIND 9.11 manual: "There may be
one or more forwarders, and they are queried in turn until the list is
exhausted
or an answer is found." So the first one will get all the traffic, the
second is just a backup to be used if the first fails.
If you expect that to do load balancing, it will not. Try a real load
balancer, or 'dnsdist'.
I think this behaviour changed to the one I described above a long time ago.
Perhaps after BIND 9.8
--
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.
Support bacteria - they're the only culture some people have.
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: unresolvable pms.psc.gov, but google/cloudflare/unbound work
Thanks for the help. I guess it is time to move to 9.18. _ Nicholas Miller, OIT, University of Colorado at Boulder > On Sep 19, 2023, at 1:53 AM, Ondřej Surý wrote: > > [External Email - Use caution] > > >> On 19. 9. 2023, at 9:25, Petr Špaček wrote: >> >> All can I tell you is "it works on my system" (with BIND, of course): > > I can reproduce this on BIND 9.16 (-c /dev/null as named.conf): > > ## BIND 9.19-dev > > 19-Sep-2023 09:33:51.633 validating pms.psc.gov/CNAME: no valid signature > found > 19-Sep-2023 09:33:52.485 validating ha.psc.gov/DS: no valid signature found > 19-Sep-2023 09:33:52.485 validating ha.psc.gov/DS: no valid signature > found > 19-Sep-2023 09:33:52.485 validating pms.ha.psc.gov/A: no valid signature found > > $ bin/dig/dig +noall +comments -p 12345 pms.psc.gov @127.0.0.1 > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35947 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 1232 > ; COOKIE: 76cc17ac4ce491b90100650950c533d1d3531585cef9 (good) > > ## BIND 9.18-dev > > 19-Sep-2023 09:36:10.717 validating pms.psc.gov/CNAME: no valid signature > found > 19-Sep-2023 09:36:11.581 validating ha.psc.gov/DS: no valid signature found > 19-Sep-2023 09:36:11.581 validating ha.psc.gov/DS: no valid signature > found > 19-Sep-2023 09:36:11.581 validating pms.ha.psc.gov/A: no valid signature found > > $ bin/dig/dig +noall +comments -p 12345 pms.psc.gov @127.0.0.1 > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30482 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 1232 > ; COOKIE: f109de3980764a4201006509507caea9fe0064088c8e (good) > > > ## BIND 9.16-dev > > 19-Sep-2023 09:37:17.685 validating pms.psc.gov/CNAME: no valid signature > found > 19-Sep-2023 09:37:27.685 query client=0x7f0b840013b0 > thread=0x7f0b8ed7b6c0(pms.ha.psc.gov/A): query_gotanswer: unexpected error: > timed out > > $ bin/dig/dig +short -p 12345 pms.psc.gov @127.0.0.1 > > $ bin/dig/dig +noall +comments -p 12345 pms.psc.gov @127.0.0.1 > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 45084 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 1232 > ; COOKIE: e5b154394f27002201006509503c139afd80b72dd04a (good) > > Those servers are broken with QNAME minimization and should be fixed, but > as we changed the QNAME minimization algorithm to use NS records instead > of A records in BIND 9.18.17 and higher, it works now. > > I can confirm this works in BIND 9.18.17 and higher. And it's absolutely not > BIND 9's fault. > > Cheers, > -- > Ondřej Surý (He/Him) > ond...@isc.org > > My working hours and your working hours may be different. Please do not feel > obligated to reply outside your normal working hours. > > > -- > Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from > this list > > ISC funds the development of this software with paid support subscriptions. > Contact us at https://www.isc.org/contact/ for more information. > > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Forwarders working differently on bind9.8 & bind9.11
On Tue, Sep 19, 2023 at 7:28 AM Prashasti Arora
wrote:
> I have configured a new zone to forward certain queries to my application
> on 2 VMs (One local and the other in my network) through a specific port. I
> have 2 similar setups - they are identical, except that one uses bind9.8
> and the other uses bind9.11. Configuration is also identical for both.
>
> On the first setup (using bind9.8): the traffic I send gets distributed
> uniformly.
> On the second setup (using bind9.11): the traffic gets distributed barely.
> 99% of the traffic is sent to one VM.
>
> I have verified that forwarding is working correctly on both, the issue is
> not with the application because both VMs on each setup can handle traffic
> individually, the firewall is not blocking the queries, and the
> configuration is correct.
>
> This is the zone:
>
> zone "example.com" IN {
> type forward;
> forwarders { 127.0.0.1 port xxx; a.b.c.d port xxx; };
> forward only;
> };
>
>
> Please share any other possible solutions.
> --
>
Note that the 'forwarders' line, from the BIND 9.11 manual: "There may be
one or more forwarders, and they are queried in turn until the list is
exhausted
or an answer is found." So the first one will get all the traffic, the
second is just a backup to be used if the first fails.
If you expect that to do load balancing, it will not. Try a real load
balancer, or 'dnsdist'.
---
Bob Harold
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: unresolvable pms.psc.gov, but google/cloudflare/unbound work
On 19. 09. 23 9:53, Ondřej Surý wrote: On 19. 9. 2023, at 9:25, Petr Špaček wrote: $ bin/dig/dig +short -p 12345 pms.psc.gov @127.0.0.1 $ bin/dig/dig +noall +comments -p 12345 pms.psc.gov @127.0.0.1 ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 45084 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: e5b154394f27002201006509503c139afd80b72dd04a (good) Those servers are broken with QNAME minimization and should be fixed, but as we changed the QNAME minimization algorithm to use NS records instead of A records in BIND 9.18.17 and higher, it works now. I can confirm this works in BIND 9.18.17 and higher. And it's absolutely not BIND 9's fault. So all in all, time to upgrade! BIND 9.16 series will reach end of life at the end of 2023 anyway. -- Petr Špaček -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Forwarders working differently on bind9.8 & bind9.11
I have configured a new zone to forward certain queries to my application
on 2 VMs (One local and the other in my network) through a specific port. I
have 2 similar setups - they are identical, except that one uses bind9.8
and the other uses bind9.11. Configuration is also identical for both.
On the first setup (using bind9.8): the traffic I send gets distributed
uniformly.
On the second setup (using bind9.11): the traffic gets distributed barely.
99% of the traffic is sent to one VM.
I have verified that forwarding is working correctly on both, the issue is
not with the application because both VMs on each setup can handle traffic
individually, the firewall is not blocking the queries, and the
configuration is correct.
This is the zone:
zone "example.com" IN {
type forward;
forwarders { 127.0.0.1 port xxx; a.b.c.d port xxx; };
forward only;
};
Please share any other possible solutions.
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: unresolvable pms.psc.gov, but google/cloudflare/unbound work
> On 19. 9. 2023, at 9:25, Petr Špaček wrote: > > All can I tell you is "it works on my system" (with BIND, of course): I can reproduce this on BIND 9.16 (-c /dev/null as named.conf): ## BIND 9.19-dev 19-Sep-2023 09:33:51.633 validating pms.psc.gov/CNAME: no valid signature found 19-Sep-2023 09:33:52.485 validating ha.psc.gov/DS: no valid signature found 19-Sep-2023 09:33:52.485 validating ha.psc.gov/DS: no valid signature found 19-Sep-2023 09:33:52.485 validating pms.ha.psc.gov/A: no valid signature found $ bin/dig/dig +noall +comments -p 12345 pms.psc.gov @127.0.0.1 ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35947 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: 76cc17ac4ce491b90100650950c533d1d3531585cef9 (good) ## BIND 9.18-dev 19-Sep-2023 09:36:10.717 validating pms.psc.gov/CNAME: no valid signature found 19-Sep-2023 09:36:11.581 validating ha.psc.gov/DS: no valid signature found 19-Sep-2023 09:36:11.581 validating ha.psc.gov/DS: no valid signature found 19-Sep-2023 09:36:11.581 validating pms.ha.psc.gov/A: no valid signature found $ bin/dig/dig +noall +comments -p 12345 pms.psc.gov @127.0.0.1 ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30482 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: f109de3980764a4201006509507caea9fe0064088c8e (good) ## BIND 9.16-dev 19-Sep-2023 09:37:17.685 validating pms.psc.gov/CNAME: no valid signature found 19-Sep-2023 09:37:27.685 query client=0x7f0b840013b0 thread=0x7f0b8ed7b6c0(pms.ha.psc.gov/A): query_gotanswer: unexpected error: timed out $ bin/dig/dig +short -p 12345 pms.psc.gov @127.0.0.1 $ bin/dig/dig +noall +comments -p 12345 pms.psc.gov @127.0.0.1 ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 45084 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: e5b154394f27002201006509503c139afd80b72dd04a (good) Those servers are broken with QNAME minimization and should be fixed, but as we changed the QNAME minimization algorithm to use NS records instead of A records in BIND 9.18.17 and higher, it works now. I can confirm this works in BIND 9.18.17 and higher. And it's absolutely not BIND 9's fault. Cheers, -- Ondřej Surý (He/Him) ond...@isc.org My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: unresolvable pms.psc.gov, but google/cloudflare/unbound work
On 18. 09. 23 15:29, Nicholas Miller wrote: I know this is an old thread but we are having issues resolving pms.psc.gov as well. Disabling DNSSec validation on a test server doesn’t solve the problem. I can add a forwarding zone for ha.psc.gov pointed to their NS servers and things work. I would love to know what is broken here. dig pms.psc.gov ; <<>> DiG 9.16.43 <<>> pms.psc.gov ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 60669 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: 20b2eb2c9840bfbd010065084978288fdde1e6f7c2a6 (good) ;; QUESTION SECTION: ;pms.psc.gov. IN A ;; Query time: 2993 msec ;; SERVER: 128.138.240.1#53(128.138.240.1) ;; WHEN: Mon Sep 18 06:58:32 MDT 2023 ;; MSG SIZE rcvd: 68 That's hard to diagnose without logs or any other supporting data. All can I tell you is "it works on my system" (with BIND, of course): $ dig pms.psc.gov ; <<>> DiG 9.19.18-dev <<>> +timeout +retry pms.psc.gov ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29005 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: 5f2a9d77850917bd010065094c8ec7febc2147e2408d (good) ;; QUESTION SECTION: ;pms.psc.gov. IN A ;; ANSWER SECTION: pms.psc.gov.3600IN CNAME pms.ha.psc.gov. pms.ha.psc.gov. 30 IN A 156.40.178.24 ;; Query time: 1533 msec ;; SERVER: 127.0.0.111#53(127.0.0.111) (UDP) ;; WHEN: Tue Sep 19 09:23:58 CEST 2023 ;; MSG SIZE rcvd: 105 -- Petr Špaček -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: consolidating in-addr.arpa data
On 18. 09. 23 18:02, John Thurston wrote: Yep. I understand the IP space can be delegated, and some of it allocated for use by systems registering in MS DNS. But this isn't going to happen. There are multiple MS Active Directories, with registered machines scattered willy-nilly across the 10-dot address-space, sometimes several competing in the same subnets. The "design and delegate" ship sailed years ago. I don't have a prayer of correctly fixing the underlying problem. After thinking harder, I don't even need correct records in all of the publishers of the various 10.in-addr.arpa zones. My goal now is simpler. Get the PTR-records from the zones handled by ISC BIND into (and out of) one particular MS DNS system. I don't need to get the PTRs registered in MS DNS back into the BIND data. I think I can get where I need to be by leveraging /nsdiff/ No. We won't be correctly publishing accurate PTRs from all of the possible DNS services in the environment. But this is achievable, and will address the problem (of our own making) which is causing pain. FTR one-way synchronization could also leverage IXFR to get list of recent updates. Of course some custom code and possibly nsdiff are in order as fallback when IXFR is not available. -- Petr Špaček Internet Systems Consortium -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
