Re: Email migration and MX records

[Bruce Johnson via bind-users]

No one realistically has a choice about dealing with either for email.

In any case, we found a vastly simpler way of doing this; our cloud email 
security/anti-spam provider (Barracuda) can spool mail for delivery if our 
systems go offline for up to 96 hours, so we’re setting them to not deliver 
tonight, doing the migration, changing our MX Records after to let the outside  
know where its supposed to send us email and then changing the delivery address 
we have on Barracuda to the new one, and the mail should flow in.

In theory! :-)

Thanks for all the suggestions, everyone.


On Jan 6, 2023, at 12:52 PM, Mark Andrews mailto:ma...@isc.org>> 
wrote:

Just a reason to not use them for your email.  Not everybody is in a position 
to repair stuff on a 7/24/365 basis. Notify that the mail is delayed by don’t 
bounce.
--
Mark Andrews

On 7 Jan 2023, at 06:11, Brown, William mailto:wbr...@e1b.org>> 
wrote:

Last I saw, both M365 and Google only retry for 24 hours before returning as 
undeliverable.


--
William Brown
WNYRIC/Erie 1 BOCES

-Original Message-
From: bind-users 
mailto:bind-users-boun...@lists.isc.org>> On 
Behalf Of Marcus Kool
Sent: Wednesday, January 4, 2023 7:17 AM
To: bind-users@lists.isc.org
Subject: Re: Email migration and MX records

 This email originated from outside of the organization. Use caution 
when replying, opening attachment(s), and/or clicking on URL's. 


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

Confidentiality Notice: This electronic message and any attachments may contain 
confidential or privileged information, and is intended only for the individual 
or entity identified above as the addressee. If you are not the addressee (or 
the employee or agent responsible to deliver it to the addressee), or if this 
message has been addressed to you in error, you are hereby notified that you 
may not copy, forward, disclose or use any part of this message or any 
attachments. Please notify the sender immediately by return e-mail or telephone 
and delete this message from your system.
--
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

--
Bruce Johnson
University of Arizona
College of Pharmacy
Information Technology Group

Institutions do not have opinions, merely customs

-- 
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: DNS Cookies Causing FORMERR

[Mark Andrews]

Really there are very few servers that are broken and the numbers are 
decreasing.  They are well under 1%. Just contact the few remaining server 
operators and inform them that they are broken.  It should just be an upgrade 
to the current version to fix. 

The behavior for unknown EDNS options was tightened nearly 10 years ago (April 
2013). It was unspecified in the original EDNS RFC and made ignored in in the 
updated RFC which every vendor should have picked up. At the time some vendors 
ignored unknown options and others returned FORMERR or NOTIMP or REFUSED. 
Others just dropped the request. Some returned BADVER.  It was a mess. 

There are also implementations that don’t know how to return FORMERR properly.  
You don’t echo back the request with rcode set to FORMERR and QR to 1 as that 
produces broken responses but some implementations do that. Why would you send 
a message that you don’t understand?  Nowhere is there any instructions to do 
this. 

To send a FORMER you send a DNS message header with rcode set to FORMERR. If 
you can parse the question section for QUERY copy that into the response. If 
you understand EDNS you can add an OPT record. Similarly TSIG if appropriate 
and you support it  Yes you can sign a FORMERR. 
-- 
Mark Andrews

> On 7 Jan 2023, at 06:50, Justin Krejci  wrote:
> 
> 
> DNS Servers that do not properly support or properly ignore DNS cookies and 
> instead return FORMERR is annoying. This is not new. However I have been 
> seeing more or perhaps just have more users that are finding more domains 
> that are hosted on authoritative servers with this unfortunate behavior.
> 
> Example progrowth.com name severs.
> 
> Individual work arounds on caching BIND servers are not difficult to 
> implement, like this
> 
> server  47.206.74.18 {
> send-cookie no;
> };
> server  209.131.228.178 {
> send-cookie no;
> };
> 
> 
> However this workaround is problematic in terms of ongoing upkeep of this 
> list and the increasing need to add new entries to the list. I'd like to be 
> able to start sending cookies again if the servers begin to operate compliant 
> to the EDNS RFC and I would like to not have to write any tools to remove 
> entries from this list or schedule some regular calendar reminder to check or 
> add to Nagios or whatever. I'd also rather not just globally disable sending 
> of DNS cookies but it is something being considered.
> 
> In this article @ https://kb.isc.org/docs/aa-01387 it states near the bottom
> 
> "Nevertheless, mishandling of the COOKIE option has been known to cause 
> errors that are fatal to name resolution when the resolver is validating 
> responses coming from a signed zone, and the authoritative server returns 
> either FORMERR or BADVERS, or fails to respond to the query. named treats 
> these answers as if the server does not support EDNS (which it doesn't) so it 
> stops sending any EDNS queries at all, which makes it impossible to get a 
> DNSSEC response back." 
> 
> This statement indicates this fall-back method is only applicable to signed 
> domains. Is there a knob in BIND to apply this behavior to all domains? 
> Basically, if the authoritative server is behaving incorrectly in this way 
> then enable no-EDNS or no-COOKIE mode in the interest of allowing DNS queries 
> to continue to be answered for the end users.
> 
> My caching servers are running the BIND 9.18 branch
> 
> Thanks for any pointers or suggestions.
> 
> -Justin
> -- 
> 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

[Mark Andrews]

Just a reason to not use them for your email.  Not everybody is in a position 
to repair stuff on a 7/24/365 basis. Notify that the mail is delayed by don’t 
bounce.
-- 
Mark Andrews

> On 7 Jan 2023, at 06:11, Brown, William  wrote:
> 
> Last I saw, both M365 and Google only retry for 24 hours before returning as 
> undeliverable.
> 
> 
> --
> William Brown
> WNYRIC/Erie 1 BOCES
> 
> -Original Message-
> From: bind-users  On Behalf Of Marcus Kool
> Sent: Wednesday, January 4, 2023 7:17 AM
> To: bind-users@lists.isc.org
> Subject: Re: Email migration and MX records
> 
>  This email originated from outside of the organization. Use caution 
> when replying, opening attachment(s), and/or clicking on URL's. 
> 
> 
> 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).
> 
> Confidentiality Notice: This electronic message and any attachments may 
> contain confidential or privileged information, and is intended only for the 
> individual or entity identified above as the addressee. If you are not the 
> addressee (or the employee or agent responsible to deliver it to the 
> addressee), or if this message has been addressed to you in error, you are 
> hereby notified that you may not copy, forward, disclose or use any part of 
> this message or any attachments. Please notify the sender immediately by 
> return e-mail or telephone and delete this message from your system.
> -- 
> 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

DNS Cookies Causing FORMERR

[Justin Krejci]

DNS Servers that do not properly support or properly ignore DNS cookies and 
instead return FORMERR is annoying. This is not new. However I have been seeing 
more or perhaps just have more users that are finding more domains that are 
hosted on authoritative servers with this unfortunate behavior.

Example progrowth.com name severs.

Individual work arounds on caching BIND servers are not difficult to implement, 
like this

server  47.206.74.18 {
send-cookie no;
};
server  209.131.228.178 {
send-cookie no;
};


However this workaround is problematic in terms of ongoing upkeep of this list 
and the increasing need to add new entries to the list. I'd like to be able to 
start sending cookies again if the servers begin to operate compliant to the 
EDNS RFC and I would like to not have to write any tools to remove entries from 
this list or schedule some regular calendar reminder to check or add to Nagios 
or whatever. I'd also rather not just globally disable sending of DNS cookies 
but it is something being considered.

In this article @ https://kb.isc.org/docs/aa-01387 it states near the bottom

"Nevertheless, mishandling of the COOKIE option has been known to cause errors 
that are fatal to name resolution when the resolver is validating responses 
coming from a signed zone, and the authoritative server returns either FORMERR 
or BADVERS, or fails to respond to the query. named treats these answers as if 
the server does not support EDNS (which it doesn't) so it stops sending any 
EDNS queries at all, which makes it impossible to get a DNSSEC response back."

This statement indicates this fall-back method is only applicable to signed 
domains. Is there a knob in BIND to apply this behavior to all domains? 
Basically, if the authoritative server is behaving incorrectly in this way then 
enable no-EDNS or no-COOKIE mode in the interest of allowing DNS queries to 
continue to be answered for the end users.

My caching servers are running the BIND 9.18 branch

Thanks for any pointers or suggestions.

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

[Brown, William]

Last I saw, both M365 and Google only retry for 24 hours before returning as 
undeliverable.


--
William Brown
WNYRIC/Erie 1 BOCES

-Original Message-
From: bind-users  On Behalf Of Marcus Kool
Sent: Wednesday, January 4, 2023 7:17 AM
To: bind-users@lists.isc.org
Subject: Re: Email migration and MX records

 This email originated from outside of the organization. Use caution 
when replying, opening attachment(s), and/or clicking on URL's. 


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

Confidentiality Notice: This electronic message and any attachments may contain 
confidential or privileged information, and is intended only for the individual 
or entity identified above as the addressee. If you are not the addressee (or 
the employee or agent responsible to deliver it to the addressee), or if this 
message has been addressed to you in error, you are hereby notified that you 
may not copy, forward, disclose or use any part of this message or any 
attachments. Please notify the sender immediately by return e-mail or telephone 
and delete this message from your system.
-- 
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