Re: Best way to handle multiple retries from BIND?

[Fred Morris]

Well in this case... I'd be more interested in ways to tune BIND's 
internal resolver behavior.


On Sun, 25 Jun 2023, Randy Bush wrote:

If you have a true duplicate you only need to answer it once otherwise
you have different clients and you need to answer all of them.  Note
there can be multiple clients on the same address.


True, in the general case. Here, not so much.


i gotta ask.

so, for address foux, how do i know if there is one client or more than
one?


In this case DNS is a gateway sitting in front of a source of telemetry 
data on a private network, and I know it only has defined clients because 
I set it up that way. Anything that needs the data can ask those clients 
(e.g. BIND) and that's the point: to hand off caching and access control 
instead of reinventing the wheel. Nothing else running on the machine 
where BIND is running in this example has any need to access the data in 
the zone, whether directly or via BIND.


--

Fred Morris

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

Changes to GitLab Sign-Up policy

[Ondřej Surý]

Hey all,

we had a massive Spam surge over couple past days, so we had to tighten the 
GitLab Sign-Up policy,
so we don't waste our time on deleting spam from the issues.

There's now couple of domains that are on denylist for signups:

- hotmail.com 
- outlook.com 
- gmail.com 

Those are the domains mostly used by 99% of the spam users [1].

If you absolutely need to create an account from these domains, talk to us, we 
can create the account
for you.

Also the same restrictions as before apply - any account created must have 2fa 
or create an issue within
one day or it will be banned and then deleted.  Any bio will be deleted in each 
Victor the GitLab Cleaner[2]
run in the CI in the initial period to avoid a Bio Spam. Unfortunately with 
these rules, the Spammers were
able to keep their accounts by creating Spam Issues, so we had to implement 
additional measures.

I understand this might complicate things for some of you, but a) there were 
only couple of legitimate accounts
with gmail/hotmail/outlook domain in the past, b) it's better if you use your 
real address and real name if you
want our help[3].

1. I have also enabled the qq.com  (and any domain hosted by 
their SMTP servers) as their implementation
of DMARC is broken and all email from GitLab bounces.

2. http://gitlab.isc.org/ondrej/gitlab-victor/edit#js-general-project-settings

3. https://berthub.eu/articles/posts/anonymous-help/

Ondrej
--
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: DNSSEC doubt

[Matthijs Mekking]

Perhaps this article is a better read for you:

https://kb.isc.org/v1/docs/en/dnssec-key-and-signing-policy

Best regards,

Matthijs


On 6/22/23 22:03, Daniel A. Rodriguez via bind-users wrote:

Thanks, I was reading but wasn't able to decode that.


Best regards


El 22 de junio de 2023 4:27:21 p. m. GMT-03:00, "Ondřej Surý" 
 escribió:


It’s not. TL;DR use dnssec-policy.

The more elaborate version of the TL;DR can be found in the DNSSEC
Guide here:
https://bind9.readthedocs.io/en/v9.18.16/dnssec-guide.html


--
Ondřej Surý — ISC (He/Him)

My working hours and your working hours may be different. Please do
not feel obligated to reply outside your normal working hours.


On 22. 6. 2023, at 20:43, Daniel A. Rodriguez via bind-users
 wrote:


I wonder if it's mandatory make a manual deployment prior to an
automated setup.
-- 
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: Best way to handle multiple retries from BIND?

[Petr Menšík]

I would suggest doing what forwarders do, joining multiple queries into 
single upstream request. When the answer arrives, send replies to all 
requestors of this common transaction. If you cannot fix your server to 
handle the response right away and have pre-computed answers, as is 
common for authoritative servers.


It is expected authoritative server does not have to do anything serious 
per client. What is that resource intensive operation we are talking 
about? Do you sign on the fly? Can you explain a bigger picture? Maybe 
there is a design of the service, which could be improved instead. 
Attempt to suppress a retry when the server does not answer quickly 
enough is not correct way of solving it IMO.


Regards,
Petr

On 6/26/23 03:05, Fred Morris wrote:


I have an authoritative server which performs a resource intensive 
operation to determine an answer; sometimes it takes long enough that 
BIND asks again (and again!). Firing off multiple attempts to 
determine the answer just digs the hole deeper.


What's the best approach, assuming the same client asks repeatedly:

  * Discard later queries, answer the first one?
  * Discard earlier queries, answer the last one?
  * Send same the response (when we get it) in response to all queries
(I don't like this one)?

And does anyone know can the recommended mitigation be presumed to be 
the best option regardless of the recursive server (BIND, Unbound, etc.)?


Thanks in advance...

--

Fred Morris




--
Petr Menšík
Software Engineer, RHEL
Red Hat,https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
-- 
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