Re: Views vs Separate Authoritative & Recursive DNS
Hi E R. My short answer would be, don't configure views unless you have a good use case for them. For example you are running resolvers that have two different kinds of clients that need to be handled differently - one client set needs RPZ, the other doesn't. Or something like that. BIND has views inside anyway. If you run "rndc stats" it produces a file called "named.stats", in which you will see line like this: [View: _bind] [View: default] The "_bind" view is always there and is used for internal processing. The "default" exists for all client processing and if you define your own views it disappears. So having one user-defined view is functionally equivalent to having no views. One possible reason I can think of for defining a view would be if you know you will need to add more views in future, so would like to standardise the structure of your config day one. It's a bit like configuring an Ethernet switch: do I configure VLANs even though (today) it's one flat network? Hope that helps. Greg On Wed, 4 Jan 2023 at 01:15, E R wrote: > New to BIND and just starting to read the 5th edition from O'Reilly after > watching some videos online while it made its way to me. I am trying to > understand why the view statement appears to be included by default in most > Linux distributions if best practice says you should have separate servers > for each? Based on the comments in the named.conf sample file I am > inclined to remove all of the view statements so it operates in "default > view" on new servers I am setting up to replace old ones. Is the view > statement just there for those who need to ignore best practices or am I > missing something? > -- > 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: Email migration and MX records
SMTP is a wonderful protocol that queues messages and retries delivery for 5 days so a non-responsive email server is no issue. Just do not have a temporary solution that bounces emails since those will never arrive (the sender is notified about the bounce). Marcus On 03/01/2023 21:31, Bruce Johnson via bind-users wrote: We’re making an O365 tenant switchover for our domain (a subdomain of the arizona.edu domain) and moving from our Barracuda cloud email SMTP to the University’s tenant, but email cannot flow until the Arizona.edu O365 tenant can take over our email domain. In anticipation I set our TTL for MX records quite low before the break (150 seconds) so, but the process may take up to an hour (if everything goes well ) Will setting our mx record to a bogus address cause email to bounce on the sending end and eventually get retried later after the mx record has been properly set to the Universities main smtp MX address? Or are we approaching this in the wrong way? Basically our end result is we want to stop accepting email from anywhere until the whole process has been changed and we have established the correct route so email starts flowing correctly. As it’s been explained to me the main campus tenant cannot start accepting email for our domain until we’ve transferred the email domain between tenants, so we cannot just change the MX record in our DNS server to the University’s (a Cisco Ironport 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
RE: Email migration and MX records
Bruce, I would push back and ask for more information from whomever is leading you down that path as it does not sound right to me although others more familiar with DNS magic might have better suggestions to DNS changes. But if Barracuda is just a front-end for email that does antivirus/spam filtering I would expect you could update Barracuda to send email to your new M365 tenant when it is ready without any DNS change to your MX record. Once that change was made you could then update MX records to bypass the Barracuda service altogether. Keep in mind that you may specify a short TTL, but you may see emails for DAYS after the change from my experience when we changed our MX servers years ago. If you received information that you could not use a third party device in front of M365, you received incorrect information. You can definitely use another service in front of M365 although the additional cost might not pencil out. We let the third party store dangerous/nasty emails in their quarantine and forward SPAM/Bulk over to M365 Junk Email folders so employees have one space to look for those things. > > -Original Message- > From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of > Bruce Johnson via bind-users > Sent: Tuesday, January 3, 2023 3:32 PM > To: bind-users@lists.isc.org > Subject: Email migration and MX records > > We?re making an O365 tenant switchover for our domain (a subdomain of the > arizona.edu domain) and moving from our Barracuda cloud email SMTP to the > University?s tenant, but email cannot flow until the Arizona.edu O365 > tenant can take over our email domain. > > In anticipation I set our TTL for MX records quite low before the break > (150 seconds) so, but the process may take up to an hour (if everything > goes well ) > > Will setting our mx record to a bogus address cause email to bounce on the > sending end and eventually get retried later after the mx record has been > properly set to the Universities main smtp MX address? > > Or are we approaching this in the wrong way? Basically our end result is > we want to stop accepting email from anywhere until the whole process has > been changed and we have established the correct route so email starts > flowing correctly. > > As it?s been explained to me the main campus tenant cannot start accepting > email for our domain until we?ve transferred the email domain between > tenants, so we cannot just change the MX record in our DNS server to the > University?s (a Cisco Ironport 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
Re: Email migration and MX records
Bruce Johnson via bind-users wrote:- >Were making an O365 tenant switchover for our domain (a subdomain of the >arizona.edu domain) and moving from our Barracuda cloud email SMTP to the >Universitys tenant, but email cannot flow until the Arizona.edu O365 tenant >can take over our email domain. This is probably more of an email than a DNS question. In any event, I have reasonably regularly undertaken such moves for clients. You are correct that the email often cannot be setup on the system until it is removed from the old. Trying to achieve this with a simple MX change WILL result in some email being rejected/bounced. >In anticipation I set our TTL for MX records quite low before the break (150 >seconds) so, but the process may take up to an hour (if everything goes well ) Sensible... >Will setting our mx record to a bogus address cause email to bounce on the >sending end and eventually get retried later after the mx record has been >properly set to the Universities main smtp MX address? Depending on what you mean by "bogus", this approach has the scope to end badly. It might work, but it might not. Furthermore, you will not know whether is did work or not. Indeed, different senders may produce different results. An approach which should cause queuing (which I do not recommend) would be to have a hostname & IP as the MX, which is under your control and which does NOT have an SMTP server running. >Or are we approaching this in the wrong way? Basically our end result is we >want to stop accepting email from anywhere until the whole process has been >changed and we have established the correct route so email starts flowing >correctly. You have correctly identified "we want to stop accepting email from anywhere until the whole process has been changed". My approach, as has been suggested by others, is to have a temporary email server as an intermediate MX (ie only ONE MX server), which has a hard delivery rule to the real OLD mail server. In order for this to work, the old and new mail servers have to be configured not to do any DNS based processing on messages from the temporary server; specifically not SPF or DNSBL. Just before the migration, configure the server not to deliver the email but hold it in a queue. When the work is complete and tested, configure the temporary server to deliver email to the new mail destination. Once dequeued and everything is working, change the DNS MX to point to the new destination. After TTL expiry (plus a bit), remove the temporary config re SPF etc from the new server. Doing this fairly often, I keep a temporary server for the purpose, in my case a fairly simple Postfix configuration. This also allows one to see all the logs and (if one wishes) take copies of emails in transit to assist with troubleshooting or for resubmission. >As its been explained to me the main campus tenant cannot start accepting >email for our domain until weve transferred the email domain between >tenants, so we cannot just change the MX record in our DNS server to the >Universitys (a Cisco Ironport setup) This sounds plausible. Hope this helps. -- Best wishes, Matthew -- 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: managed-keys vs trust-anchors
On Mon, Jan 02, 2023 at 07:33:46AM -0500, Bob McDonald wrote: > I've upgraded to bind 9.16.36. > > I went to the ISC site and picked up the bind.keys file. > > However, it is intended for use in bind 9.11 and contains the managed-keys > clause. This throws an error in the syslog messages during startup. It > appears to still function correctly. > > In the ARM for bind 9.16 it states that managed-keys clause is deprecated. > Replacing the managed-keys clause with the trust-anchors clause seems to > fix the issue. In the file itself it states the following: > > # This file is NOT expected to be user-configured. > > Perhaps I've missed something. If not, the documentation needs to be a bit > more clear on this. Would it be helpful to have a version of the bind.keys > file for bind 9.16 and above? Thanks for bringing this to our attention. It's no longer necessary to get the bind.keys file from the ISC website. We've updated the site to remove the downloadable version, and just put some explanatory text there instead. The bind.keys file was originally put there for reasons that aren't really applicable anymore; you can safely rely on the one that's compiled in to named now. Some background on this can be found in the discussion at https://www.mail-archive.com/bind-users@lists.isc.org/msg31664.html. (And, if for some odd reason you really do need to download a new copy of bind.keys instead of updating BIND, you can pull it from the source tree: https://gitlab.isc.org/isc-projects/bind9/-/blob/main/bind.keys.) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. -- 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: managed-keys vs trust-anchors
Thanks Evan and Ondrej. I'll let the folks at FreeBSD know also. Their bind packages still include that file. Bob On Wed, Jan 4, 2023, 14:59 Evan Hunt wrote: > On Mon, Jan 02, 2023 at 07:33:46AM -0500, Bob McDonald wrote: > > I've upgraded to bind 9.16.36. > > > > I went to the ISC site and picked up the bind.keys file. > > > > However, it is intended for use in bind 9.11 and contains the > managed-keys > > clause. This throws an error in the syslog messages during startup. It > > appears to still function correctly. > > > > In the ARM for bind 9.16 it states that managed-keys clause is > deprecated. > > Replacing the managed-keys clause with the trust-anchors clause seems to > > fix the issue. In the file itself it states the following: > > > > # This file is NOT expected to be user-configured. > > > > Perhaps I've missed something. If not, the documentation needs to be a > bit > > more clear on this. Would it be helpful to have a version of the > bind.keys > > file for bind 9.16 and above? > > Thanks for bringing this to our attention. It's no longer necessary > to get the bind.keys file from the ISC website. We've updated the > site to remove the downloadable version, and just put some explanatory > text there instead. > > The bind.keys file was originally put there for reasons that aren't really > applicable anymore; you can safely rely on the one that's compiled in to > named now. Some background on this can be found in the discussion at > https://www.mail-archive.com/bind-users@lists.isc.org/msg31664.html. > > (And, if for some odd reason you really do need to download a new copy of > bind.keys instead of updating BIND, you can pull it from the source tree: > https://gitlab.isc.org/isc-projects/bind9/-/blob/main/bind.keys.) > > -- > Evan Hunt -- e...@isc.org > Internet Systems Consortium, Inc. > -- 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: managed-keys vs trust-anchors
On Wed, Jan 04, 2023 at 03:25:10PM -0500, Bob McDonald wrote: > Thanks Evan and Ondrej. I'll let the folks at FreeBSD know also. Their > bind packages still include that file. The file itself is harmless. But we used to say it was best practice to check for updates at the ISC website before turning on DNSSEC validation, and we no longer consider that to be worthwhile advice. Just keep your packages up to date and you'll be fine. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. -- 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
Deprecation notice force BIND 9.20+: source port(s)
Hi, in line with out deprecation policy, I am notifying the mailing list about our preliminary intent to deprecate the definition of the source ports and rely on the operating system to provide reasonable ephemeral port range for outgoing UDP and TCP connections. Specifying outgoing ports is a bad practice, it's already discouraged, it's prone to errors (it's not only specifying single port, but specifying not enough ports removes a layer of protection) and is already full of caveats like: .. note:: The address specified in the :any:`query-source` option is used for both UDP and TCP queries, but the port applies only to UDP queries. TCP queries always use a random unprivileged port. .. warning:: Specifying a single port is discouraged, as it removes a layer of protection against spoofing errors. .. warning:: The configured :term:`port` must not be the same as the listening port. The deprecation will include: * specifying **port** in following statements: - `query-source` - `query-source-v6` - `transfer-source` - `transfer-source-v6` - `notify-source` - `notify-source-v6` - `parental-source` - `parental-source-v6` * following statements as whole: - `use-v4-udp-ports` - `use-v6-udp-ports` - `avoid-v4-udp-ports` - `avoid-v6-udp-ports` These options will be marked as deprecated in BIND 9.20[1][2] and removed in BIND 9.22[3]. 1. BIND 9.20 will be released early 2024 2. Most probably we will also enable the warning in BIND 9.18 to notify users that skip versions. 3. BIND 9.22 will be release in early 2026 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
