Re: force nameserver(bind) information exchanges with clients via tcp only
Hello Petr,
This setup was not meant to address a specific problem or be implemented
in a production situation. I am running an experiment
and one of the criteria was for clients to connect with us via tcp only.
I don't have control on the clients (only nameserver) and relying on
whether clients have set certain flags is not a viable option in my case
unfortunately.
Best Regards,
Donika
On 01.10.21 10:47, Petr Menšík wrote:
Hi Donika,
I think it can be partially archieved by options use-vc in
/etc/resolv.conf on end clients. But I doubt every software would
process this flag, only part of them would use it. I doubt many daemons
doing direct DNS queries would follow such configuration.
Can you share why you are even attempting to move to TCP only? What is
your motivation? What should it solve?
Regards,
Petr
On 9/30/21 15:17, Donika Mirdita wrote:
Hello,
I have set up a nameserver and I would like to force all future client
requests to TCP only.
Essentially, one scenario would be for all UDP requests to be
countered with a packet that has the TC bit set so the connection
is retried via TCP. I want this rule to be applicable to all incoming
request, no actual data exchange
via UDPs, even for a simple dig request. I tried achieving this with
the following 2 strategies but with no success:
1. set split value to 1 (in the rate-limit argument in
named.conf.options)
2. I also tried to setup a response policy zone. I added the following
in named.conf.options
response-policy {
zone "rpz.example.com" policy tcp-only;
};
and the appropriate CNAME record for rpz-tcp-only. in
rpz.example.com.
Neither worked out.
I know this scenario is not compliant to standard DNS, it is only an
experimental setup.
I am using bind 9.16.1 and the OS is Ubuntu 20.04.
If anyone has ideas on how to achieve this with bind, it would be very
helpful.
Best Regards,
Donika Mirdita
___
Please 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
___
Please 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: Broken trust chain presumably due to some zone operators using LetsEncrypt certificates
Ondřej Surý said: > Hi Richard, > this is not the case. > slack.com botched their DS/DNSKEY deployment (there’s a thread on > dns-operations about it). Thanks for the correction, my mistake. Apologies for the list spam! Richard. ___ Please 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: Broken trust chain presumably due to some zone operators using LetsEncrypt certificates
Hi Richard,
this is not the case.
slack.com botched their DS/DNSKEY deployment (there’s a thread on
dns-operations about it).
Ondrej
--
Ondřej Surý (He/Him)
ond...@isc.org
> On 1. 10. 2021, at 18:46, Richard T.A. Neal wrote:
>
> For those of you facing a curious issue with BIND failing to resolve records
> for some zones today it’s not necessarily BIND having “a Friday moment”
>
> It looks like the LetsEncrypt root certificate expiry is even impacting some
> DNSSEC zones that have used a LetsEncrypt certificate to sign their zone file.
>
> For example my BIND 9.17.18 / Ubuntu 21.04 servers are failing to resolve
> {anything}.slack.com at the moment, presumably because Slack have used
> LetsEncrypt to sign their zone. BIND is logging the following in my
> query-errors.log file:
>
> (app.slack.com): query failed (broken trust chain) for app.slack.com/IN/A at
> query.c:7658
>
> There’s a little more info about the LetsEncrypt issue at the following two
> links (not my site):
>
> https://scotthelme.co.uk/lets-encrypt-old-root-expiration/
> and
> https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/
>
> Richard.
>
> ___
> Please 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
___
Please 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: force nameserver(bind) information exchanges with clients via tcp only
I should be clearer about this. The media devices send a lot of traffic. They manipulate the wifi landscape in proprietary (remember the TCP throughput wars 20+ years ago?) or at least unexpected ways. Stupid wifi access point follows "conventional wisdom" and drops UDP traffic. Doesn't bother the media devices, but 1980s stub resolver logic isn't up to competing with 100,000:1 packet contention and doesn't provide any way to do traffic shaping. -- Fred On Fri, 1 Oct 2021, Fred Morris wrote: On Thu, 30 Sep 2021, Carl Byington wrote: On Thu, 2021-09-30 at 16:30 -0700, Fred Morris wrote: https://github.com/m3047/tcp_only_forwarder So what exactly are the media devices doing to screw up dns resolution between the osx laptop and the local dns server? Dropping UDP replies. As a consequence, TCP is never tried. 1980s stub resolver logic. -- Fred ___ Please 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
Broken trust chain presumably due to some zone operators using LetsEncrypt certificates
For those of you facing a curious issue with BIND failing to resolve records
for some zones today it’s not necessarily BIND having “a Friday moment”
It looks like the LetsEncrypt root certificate expiry is even impacting some
DNSSEC zones that have used a LetsEncrypt certificate to sign their zone file.
For example my BIND 9.17.18 / Ubuntu 21.04 servers are failing to resolve
{anything}.slack.com at the moment, presumably because Slack have used
LetsEncrypt to sign their zone. BIND is logging the following in my
query-errors.log file:
(app.slack.com): query failed (broken trust chain) for app.slack.com/IN/A at
query.c:7658
There’s a little more info about the LetsEncrypt issue at the following two
links (not my site):
https://scotthelme.co.uk/lets-encrypt-old-root-expiration/
and
https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/
Richard.
___
Please 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: force nameserver(bind) information exchanges with clients via tcp only
Exactly! On Thu, 30 Sep 2021, Carl Byington wrote: On Thu, 2021-09-30 at 16:30 -0700, Fred Morris wrote: https://github.com/m3047/tcp_only_forwarder So what exactly are the media devices doing to screw up dns resolution between the osx laptop and the local dns server? Dropping UDP replies. As a consequence, TCP is never tried. 1980s stub resolver logic. -- Fred ___ Please 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: Recursion setting for bind9
Hi Sonal,
I do not think forwarders specified in zone work as fixed order. It
would not work by first contacting 127.0.0.1, if that did not deliver
the answer, try 199.165.24.21. Forwarders in bind are configured as a
set, not ordered list. It would use whatever just gives faster replies.
I am afraid BIND does not work similar to /etc/resolv.conf, where such
approach might work. It expects authoritative server for the zone can be
found and produces the answer. Which is only cached by named. It expects
any configured forwarder would get the same answer, just how fast it is
would be measured.
I think more correct would be setting more specific zones of e164.arpa
configured with only one forwarder.
Regards,
Petr
On 9/29/21 09:21, Sonal Pahuja wrote:
>
> Hi All,
>
>
>
> Is there any option to set recursion =1 in named.conf file for the
> zone. I just want bind9 to do recursion only once.
>
> If bind9 receives answer from one of the forwarders then it should not
> do recursion (forward query) to any other forwarder IP.
>
>
>
> Below is my snapshot of my named.conf file
>
>
>
> options {
>
> listen-on port 53 { any; };
>
> listen-on-v6 port 53 { any; };
>
> directory "/var/named";
>
> dump-file "/var/named/data/cache_dump.db";
>
> statistics-file "/var/named/data/named.stats";
>
> memstatistics-file "/var/named/data/named_mem_stats.txt";
>
> allow-query { localhost; !blocked; allowed; };
>
> // allow-query { localhost; };
>
> recursion yes;
>
> zone-statistics yes;
>
> dnssec-enable no;
>
> dnssec-validation no;
>
> auth-nxdomain no;
>
> // additional-from-auth no;
>
> // additional-from-cache no;
>
> /* Path to ISC DLV key */
>
> bindkeys-file "/etc/named.iscdlv.key";
>
>
>
> managed-keys-directory "/var/named/dynamic";
>
>
>
>
>
> };
>
> zone "e164.arpa" IN {
>
> type forward ;
>
> forwarders { 127.0.0.1 port 49153; 199.165.24.21 port 49153; };
>
> forward only;
>
> };
>
>
>
> Regards,
>
> Sonal
>
>
> ___
> Please 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
--
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
___
Please 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: force nameserver(bind) information exchanges with clients via tcp only
Hi Donika,
I think it can be partially archieved by options use-vc in
/etc/resolv.conf on end clients. But I doubt every software would
process this flag, only part of them would use it. I doubt many daemons
doing direct DNS queries would follow such configuration.
Can you share why you are even attempting to move to TCP only? What is
your motivation? What should it solve?
Regards,
Petr
On 9/30/21 15:17, Donika Mirdita wrote:
> Hello,
>
> I have set up a nameserver and I would like to force all future client
> requests to TCP only.
> Essentially, one scenario would be for all UDP requests to be
> countered with a packet that has the TC bit set so the connection
> is retried via TCP. I want this rule to be applicable to all incoming
> request, no actual data exchange
> via UDPs, even for a simple dig request. I tried achieving this with
> the following 2 strategies but with no success:
>
> 1. set split value to 1 (in the rate-limit argument in
> named.conf.options)
>
> 2. I also tried to setup a response policy zone. I added the following
> in named.conf.options
>
> response-policy {
> zone "rpz.example.com" policy tcp-only;
> };
>
> and the appropriate CNAME record for rpz-tcp-only. in
> rpz.example.com.
>
> Neither worked out.
>
> I know this scenario is not compliant to standard DNS, it is only an
> experimental setup.
> I am using bind 9.16.1 and the OS is Ubuntu 20.04.
> If anyone has ideas on how to achieve this with bind, it would be very
> helpful.
>
> Best Regards,
>
> Donika Mirdita
>
> ___
> Please 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
--
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
___
Please 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
