Re: How should I configure internal and external DNS servers

2023-11-05 Thread Michael Richardson

Greg Choules via bind-users  wrote:
> What would be better (IMHO) is for you to keep "example.com" as your
> external zone in an external (hopefully in a DMZ) primary server,
> serving the world with public addresses they need to reach, and
> internally create a new zone - "internal.example.com" (maybe also other
> "somethingX.example.com" too) as your internal zone in an internal
> primary server for serving internal clients with the addresses they
> need.

Would anyone be interested in formulating this into an IETF BCP RFC?
Or maybe a RIPE BCOP.
Your write up is excellent.  Worth keeping it somewhere.

> The reason for the delegation is DNSSEC. If you enable DNSSEC

Yes.

> That was a bit of an essay, but I hope at least some of it made sense.

:-)



signature.asc
Description: PGP signature
-- 
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


Can we enable serve-stale parameter in bind

2023-11-05 Thread Prasanna Mathivanan (pmathiva) via bind-users
Hi team,

If there is a scenario where NS are not reachable, until its up we can serve 
from cache.

Enabling serve-stale can help us with this use case, is it safe to enable this 
parameter and what should be the recommended value set for max-stale-ttl ?

--
Regards,
Prasanna

-- 
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: Help about DNS documentation

2023-11-05 Thread Andrew Latham
* Commonly when an answer to a query is larger than UDP should handle, a
switch to TCP is required. This can be configurable and done in unexpected
ways to thwart DDOS
* I do not know of any laws specifically mentioning DNS. General computer
system/network laws could apply.
* I think there would be some demonstrations out there. I searched for
`github dns amplification attack` and saw many.

On Fri, Nov 3, 2023 at 9:21 AM Amaury Van Pevenaeyge <
avanpevenae...@outlook.fr> wrote:

> Hello everyone,
>
>
>
> I'm currently a final year Master's student at the Free University of
> Brussels. As part of my Master's thesis, I have to implement a DNS
> amplification scenario within a Cyber Range. However, before achieving this
> final goal, I first need to make amplification rate measurements within a
> virtual machine system. I therefore have a few questions about the DNS
> protocol and DNS servers.
>
>
>
>- Why do some DNS servers respond via TCP to an ANY query made under
>UDP? I have read in RFC8482 that modern DNS servers try to limit responses
>to ANY queries in order to limit the impact of their use in DNS
>amplification attack but I would like to learn more about the security
>measures/best practices currently in place for this type of query and for
>big TXT responses. Does anyone have any sources or other RFCs that might be
>useful?
>
>
>
>- Would you have any advice/recommendations or sources on the legal
>Framework to be respected for my Master’s thésis, so that I can carry out
>my various measures without being illegal or alerting certain entities?
>
>
>
>- Would you have some articles and researches or others about DNS
>protocol, DNS protocol security or good research practices for DNS
>amplification attacks?
>
>
>
> Thank you in advance for your help. I remain at your disposal should you
> have any questions.
> --
> 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
>


-- 
- Andrew "lathama" Latham -
-- 
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: Can we enable serve-stale parameter in bind

2023-11-05 Thread Ondřej Surý
This is a horrible reason to enable serve-stale. Serve stale is a bandaid. You 
should increase a resiliency of the architecture - have more nameservers for 
the domain, make the restarts seamless, etc.

Serve-stale was meant to deal with unexpected outages and not as a workaround 
for bad engineering in the first place.

Ondřej
--
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 6. 11. 2023, at 3:04, Prasanna Mathivanan (pmathiva) via bind-users 
>  wrote:
> 
> 
> Hi team,
>  
> If there is a scenario where NS are not reachable, until its up we can serve 
> from cache.
>  
> Enabling serve-stale can help us with this use case, is it safe to enable 
> this parameter and what should be the recommended value set for max-stale-ttl 
> ?
>  
> -- 
> Regards,
> Prasanna
>  
> --
> 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