Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 29 Jan 2009 22:33:24 -0800, Al Stu wrote: Analyze this. Query MX dns.com Response MX nullmx.domainmanager.com Query A nullmx.domainmanager.com Response CNAME mta.dewile.net, A 64.40.103.249 So the fact that other random folks make errors in their dns is suprising, or do you wish to use the existence of those errors to justify making those same errors yourself? -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFJgzPXL6j7milTFsERAmK2AKCHBKTudsFFbdekhR0pmCN0EAv+LwCfarkK PTfobRXHugzLPmLdb1UQCMI= =YQjr -END PGP SIGNATURE- ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal
David Sparks wrote: There are plenty of ways to get a mail loop that don't involve DNS mis-configuration. As such pretty much every major MTA detects and stops mail loops. Not if you (accidentally) fat-finger the MTA configuration. It is completely possible to still mis-configure a MTA to deliver to itself as fast as possible. A DNS configuration with CNAMEs in the mix short-circuits delivery loop detection at the MX level and just sets up more potential for a loop. So mail loops are a non-issue ... next? That is the _entire_ issue here. Regards, Mike ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal
On 30.01.09 22:55, Al Stu wrote: History is fraught with individuals or a few being ridiculed for putting forth that which goes against the conventional wisdom of the masses and so called experts, only to be vindicated once the masses and so called experts get their head out where the sun is shining and exposed to the light of day. Once upon a time the world was 'flat'. For some of you, apparently is still is 'flat'. Don Quijote -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Christian Science Programming: Let God Debug It!. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal
What?! And all this time I just assumed it was the Martian Sand variety that was being spoken of on all the save the whales bumper stickers. Maybe Al will end up winning the Darwin Award for another one of his avante garde ideas. He'll decide that the conventional wisdom that exhausting his engine through a tail pipe instead of into the cabin is the cause of global warming and modify his car... -Original Message- From: bind-users-boun...@lists.isc.org [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Danny Thomas Sent: Saturday, January 31, 2009 2:18 AM To: bind-users@lists.isc.org Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal Al Stu wrote: History is fraught with individuals or a few being ridiculed for putting forth that which goes against the conventional wisdom of the masses and so called experts, only to be vindicated once the masses and so called experts get their head out where the sun is shining and exposed to the light of day. Once upon a time the world was 'flat'. For some of you, apparently is still is 'flat'. and for every Einstein, Columbus, etc, there have been untold people whose beliefs were not accepted. So whenever I see this line of argument advanced in a simplistic way, particularly with a hint of an heroic struggle against orthodoxy, I can't help thinking that the odds of heretical views being vindicated is pretty low. One belief yet to be accepted is the existence of Martian sand whales. *really plonk* ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users Please consider our environment before printing this e-mail or attachments. -- CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential information and is for the sole use of the intended recipient(s). If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you. -- ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal
The authoritative name servers for nullmx.domainmanager.com are ns1.domainmanager.com and ns2.domainmanager.com. They are domain parking name servers. They return 64.40.103.249 (or at least something close to that) to the query for any A record. The real address of mta.dewile.net is 69.59.189.80 (as supplied by ns1.alices-registry.com, one of the authoritative name servers for dewile.net). -Original Message- From: bind-users-boun...@lists.isc.org [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Al Stu Sent: Friday, January 30, 2009 12:33 AM To: bind-users@lists.isc.org Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal Analyze this. Query MX dns.com Response MX nullmx.domainmanager.com Query A nullmx.domainmanager.com Response CNAME mta.dewile.net, A 64.40.103.249 See attached network trace. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal
You just don't get it. You are off wandering around in the weeds. Read the tail end of Chapter 5 in the book DNS and BIND describing the MX selection algorithm in layman's terms to (perhaps) understand why having MX records referencing CNAMEs is bad. It may work right now for you, but referencing CNAMEs in MX records eventually _will_ cause delivery loops the next time you accidentally fat-finger a config. If you continue to be hard-headed about this and not listen to the 100s of years of collective wisdom dispensed, then go ahead and leave yourself set up for a potential DoS against yourself, we're not going to stop you... and we're not going to feel sorry for you either. FIN Regards, Mike Al Stu wrote: Analyze this. Query MX dns.com Response MX nullmx.domainmanager.com Query A nullmx.domainmanager.com Response CNAME mta.dewile.net, A 64.40.103.249 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal
History is fraught with individuals or a few being ridiculed for putting forth that which goes against the conventional wisdom of the masses and so called experts, only to be vindicated once the masses and so called experts get their head out where the sun is shining and exposed to the light of day. Once upon a time the world was 'flat'. For some of you, apparently is still is 'flat'. - Original Message - From: Michael Milligan mi...@acmeps.com To: Al Stu al_...@verizon.net Cc: bind-users@lists.isc.org Sent: Friday, January 30, 2009 10:20 AM Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal You just don't get it. You are off wandering around in the weeds. Read the tail end of Chapter 5 in the book DNS and BIND describing the MX selection algorithm in layman's terms to (perhaps) understand why having MX records referencing CNAMEs is bad. It may work right now for you, but referencing CNAMEs in MX records eventually _will_ cause delivery loops the next time you accidentally fat-finger a config. If you continue to be hard-headed about this and not listen to the 100s of years of collective wisdom dispensed, then go ahead and leave yourself set up for a potential DoS against yourself, we're not going to stop you... and we're not going to feel sorry for you either. FIN Regards, Mike Al Stu wrote: Analyze this. Query MX dns.com Response MX nullmx.domainmanager.com Query A nullmx.domainmanager.com Response CNAME mta.dewile.net, A 64.40.103.249 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal
On Sat, 2009-01-31 at 16:55, Al Stu wrote: History is fraught with individuals or a few being ridiculed for putting forth that which goes against the conventional wisdom of the masses and so You don't get to speak for anyone else but yourself, just because you believe in your own trolling, don't assume agree with you, let alone masses of others ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal
Al Stu wrote: History is fraught with individuals or a few being ridiculed for putting forth that which goes against the conventional wisdom of the masses and so called experts, only to be vindicated once the masses and so called experts get their head out where the sun is shining and exposed to the light of day. Once upon a time the world was 'flat'. For some of you, apparently is still is 'flat'. and for every Einstein, Columbus, etc, there have been untold people whose beliefs were not accepted. So whenever I see this line of argument advanced in a simplistic way, particularly with a hint of an heroic struggle against orthodoxy, I can't help thinking that the odds of heretical views being vindicated is pretty low. One belief yet to be accepted is the existence of Martian sand whales. *really plonk* ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal
On 27.01.09 10:18, Al Stu wrote: I not only say it, I have demonstrated it. But you have demonstrated something different than we're discussing all the time. BIND is the DNS system we are discussing. Have not looked to see if that specifically is spec'ed in an RFC. Yes other DNS implementations do return both the A and CNAME. It depends on the query sent. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Fighting for peace is like fucking for virginity... ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal
On Jan 26, 2009, at 11:27 PM, David Ford wrote: hand because each line isn't strictly well-formed per RFC. If every vendor was as utterly asinine about absolutist conformance, sure, we'd have a lot less mess out there, but we'd have a lot less forward movement as well as a lot more fractioning of software packages. Since everyone wants to do the protocol their own way, we'd just have a multitude of protocol variations rather than more flexible interoperability. it could be argued, that if there was absolutist conformance to standards, we could move forward even faster. There is literally a 20% developer tax on debugging css and html to make it work with most browsers. Many compromises made to satisfy the lack of strictness. I am not totally disagreeing with you, I am not known to make ascii art in emails :) but I do think we would have a better systems if standards were more adhered to. -- Scott ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal
So then you disagree that the following example returns a valid address record for srv1? srv1 300 IN A 1.2.3.4 mx1 300 IN CNAME srv1.xyz.com. @ 300 IN MX 1 mx1.xyz.com. 1) Select Target Host: The MX query for xyz.com delivers mx1.xyz.com which is a CNAME. 2) Get Target Host Address: The A query for mx1.xyz.com delivers the address (A) record of srv1.xyz.com, 1.2.3.4, and also delivers the alias (CNAME) record of mx1.xyz.com. *** PLEASE don't copy me on replies, I'll read them in the group *** - Original Message - From: Mark Andrews mark_andr...@isc.org To: Al Stu al_...@verizon.net Cc: bind-users@lists.isc.org Sent: Tuesday, January 27, 2009 1:46 AM Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal In message 10b3763032c94ae2ba4900b3137d1...@ahsnbw1, Al Stu writes: The paragraph you cite regarding LOCAL has a alias and the alias is listed in the MX records for REMOTE... is a peripery issue which is handled by not doing that. Them why are you complaining? The error message is only emitted when you add such a alias. No one is saying a CNAME is not permitted in response to a MX query. Well good then, we agree. No. The MX record data value can be a CNAME. No. That is what BIND is complaining about, and I in turn saying should be changed/removed. i.e. BIND should not complain about the following, but it does. It says the MX record is illegal. But it is not. srv1 300 IN A 1.2.3.4 mx1 300 IN CNAME srv1.xyz.com. @ 300 IN MX 1 mx1.xyz.com. The MX query for xyz.com delivers mx1.xyz.com which is a CNAME. The A query for mx1.xyz.com delivers the address (A) record of srv1.xyz.com, 1.2.3.4, and the alias (CNAME) record of mx1.xyz.com. *** PLEASE don't copy me on replies, I'll read them in the group *** - Original Message - From: Mark Andrews mark_andr...@isc.org To: Al Stu al_...@verizon.net Cc: bind-users@lists.isc.org Sent: Monday, January 26, 2009 10:03 PM Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal In message b3ba5e37553642e28149093cdee78...@ahsnbw1, Al Stu writes: Yes, the response to an MX query, that is the subject here. And a CNAME is in fact permitted and specified by the RFC's to be accepted as the response to an MX lookup. No one is saying a CNAME is not permitted in response to a MX query. If the response does not contain an error response, and does not contain aliases See there, alias is permitted. You just keep proving the my case. We are saying that when you lookup the address of the mail exchanger that you shouldn't get a CNAME record. MX - CNAME is not permitted. Others have quoted similar text from more recent RFC's. RFC 974 Note that the algorithm to delete irrelevant RRs breaks if LOCAL has a alias and the alias is listed in the MX records for REMOTE. (E.g. REMOTE has an MX of ALIAS, where ALIAS has a CNAME of LOCAL). This can be avoided if aliases are never used in the data section of MX RRs. I am not taking it out of context. It is very explicitly stated. And the context is that of locating the target/remote host by first submitting an MX query, then submitting an A query of the MX query result. The text you quote is ONLY talking about the MX query. There is no then submitting an A query of the MX query result at this point in the RFC. The MX query result is permitted to be and alias, which in turn when submitted for an A query results in both the A and CNAME being returned. Thus meeting the SMTP RFC requirements. - Original Message - From: Mark Andrews mark_andr...@isc.org To: Al Stu al_...@verizon.net Cc: bind-users@lists.isc.org Sent: Monday, January 26, 2009 8:41 PM Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal In message 3c802402a28c4b2390b088242a91f...@ahsnbw1, Al Stu writes: RFC 974: There is one other special case. If the response contains an answer which is a CNAME RR, it indicates that REMOTE is actually an alias for some other domain name. The query should be repeated with the canonical domain name. And that is talking about the response to a MX query. The section from which you quote starts with: Issuing a Query The first step for the mailer at LOCAL is to issue a query for MX RRs for REMOTE. It is strongly urged that this step be taken every time a mailer attempts to send the message. The hope is that changes in the domain database will rapidly be used by mailers, and thus domain administrators will be able to re-route in-transit messages for defective hosts by simply changing their domain databases. and the paragraph after that which you quote is: If the response does not contain an error response, and does not contain aliases, its answer section should be a (possibly zero length) list of MX RRs for domain name
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal
On 27.01.09 08:46, Al Stu wrote: So then you disagree that the following example returns a valid address record for srv1? srv1 300 IN A 1.2.3.4 mx1 300 IN CNAME srv1.xyz.com. @ 300 IN MX 1 mx1.xyz.com. 1) Select Target Host: The MX query for xyz.com delivers mx1.xyz.com which is a CNAME. 2) Get Target Host Address: The A query for mx1.xyz.com delivers the address (A) record of srv1.xyz.com, 1.2.3.4, and also delivers the alias (CNAME) record of mx1.xyz.com. They are two queries. If mx1 would be an A, it would be returned in the first query. Since it's a CNAME, the IP is not returned in the MX query. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. It's now safe to throw off your computer. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal
When Section 5.1 of RFC 5321 says If a CNAME record is found, the resulting name is processed as if it were the initial name, it is referring to the situation where a query is sent for the MX record for xyz.com, and instead of an MX record being returned for xyz.com, a CNAME record is returned for xyz.com (e.g., xyz.com. IN CNAME abc.com.). In that case, the client is then expected to start the whole process over by querying for the MX record for abc.com. It is not referring to the case where a query is sent for the MX record for xyz.com and an MX record is returned for xyz.com having a CNAME for the RDATA (such as, XYZ IN MX 10 cn.xyz.com, where cn.xyz.com is a CNAME for srv1.xyz.com.) In fact, Section 5.1 of RFC 5321 goes on to discuss having CNAMEs returned in the RDATA of MX records and refers the reader to Section 10.3 of RFC 2181, which explicity forbids CNAMEs in the RDATA of either NS or MX records (The domain name used as the value of a NS resource record, or part of the value of a MX resource record must not be an alias.). -Original Message- From: bind-users-boun...@lists.isc.org [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Al Stu Sent: Tuesday, January 27, 2009 12:13 PM To: bind-users@lists.isc.org Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal They are two queries. If mx1 would be an A, it would be returned in the first query. Since it's a CNAME, the IP is not returned in the MX query. So. RFC 5321 5.1, Locating the Target Host, says the CNAME is to be processed. The lookup first attempts to locate an MX record associated with the name. If a CNAME record is found, the resulting name is processed as if it were the initial name. *** PLEASE don't copy me on replies, I'll read them in the group *** - Original Message - From: Matus UHLAR - fantomas uh...@fantomas.sk To: bind-users@lists.isc.org Sent: Tuesday, January 27, 2009 9:01 AM Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal On 27.01.09 08:46, Al Stu wrote: So then you disagree that the following example returns a valid address record for srv1? srv1 300 IN A 1.2.3.4 mx1 300 IN CNAME srv1.xyz.com. @ 300 IN MX 1 mx1.xyz.com. 1) Select Target Host: The MX query for xyz.com delivers mx1.xyz.com which is a CNAME. 2) Get Target Host Address: The A query for mx1.xyz.com delivers the address (A) record of srv1.xyz.com, 1.2.3.4, and also delivers the alias (CNAME) record of mx1.xyz.com. They are two queries. If mx1 would be an A, it would be returned in the first query. Since it's a CNAME, the IP is not returned in the MX query. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. It's now safe to throw off your computer. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal
In message d53c69e1f478453a8371b49b4f04c...@ahsnbw1, Al Stu writes: So then you disagree that the following example returns a valid address record for srv1? The MX query won't return the A record for srv1. The additional section processing rules say to add A / records not CNAME records. You fail to understand that the rule is there so that MX processing can be done in a deterministic manner. I don't care that when you look up mx1.xyz.com you eventually get a address record. The damage is done long before that lookup is performed. Email is processed in this order: Look up MX records. Process the MX RRset. Lookup address records and attempt to deliver the email. Mark srv1 300 IN A 1.2.3.4 mx1 300 IN CNAME srv1.xyz.com. @ 300 IN MX 1 mx1.xyz.com. 1) Select Target Host: The MX query for xyz.com delivers mx1.xyz.com which is a CNAME. 2) Get Target Host Address: The A query for mx1.xyz.com delivers the address (A) record of srv1.xyz.com, 1.2.3.4, and also delivers the alias (CNAME) record of mx1.xyz.com. *** PLEASE don't copy me on replies, I'll read them in the group *** - Original Message - From: Mark Andrews mark_andr...@isc.org To: Al Stu al_...@verizon.net Cc: bind-users@lists.isc.org Sent: Tuesday, January 27, 2009 1:46 AM Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal In message 10b3763032c94ae2ba4900b3137d1...@ahsnbw1, Al Stu writes: The paragraph you cite regarding LOCAL has a alias and the alias is listed in the MX records for REMOTE... is a peripery issue which is handled by not doing that. Them why are you complaining? The error message is only emitted when you add such a alias. No one is saying a CNAME is not permitted in response to a MX query. Well good then, we agree. No. The MX record data value can be a CNAME. No. That is what BIND is complaining about, and I in turn saying should be changed/removed. i.e. BIND should not complain about the following, but it does. It says the MX record is illegal. But it is not. srv1 300 IN A 1.2.3.4 mx1 300 IN CNAME srv1.xyz.com. @ 300 IN MX 1 mx1.xyz.com. The MX query for xyz.com delivers mx1.xyz.com which is a CNAME. The A query for mx1.xyz.com delivers the address (A) record of srv1.xyz.com, 1.2.3.4, and the alias (CNAME) record of mx1.xyz.com. *** PLEASE don't copy me on replies, I'll read them in the group *** - Original Message - From: Mark Andrews mark_andr...@isc.org To: Al Stu al_...@verizon.net Cc: bind-users@lists.isc.org Sent: Monday, January 26, 2009 10:03 PM Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal In message b3ba5e37553642e28149093cdee78...@ahsnbw1, Al Stu writes: Yes, the response to an MX query, that is the subject here. And a CNAME is in fact permitted and specified by the RFC's to be accepted as the response to an MX lookup. No one is saying a CNAME is not permitted in response to a MX query. If the response does not contain an error response, and does not contain aliases See there, alias is permitted. You just keep proving the my case. We are saying that when you lookup the address of the mail exchanger that you shouldn't get a CNAME record. MX - CNAME is not permitted. Others have quoted similar text from more recent RFC's. RFC 974 Note that the algorithm to delete irrelevant RRs breaks if LOCAL has a alias and the alias is listed in the MX records for REMOTE. (E.g. REMOTE has an MX of ALIAS, where ALIAS has a CNAME of LOCAL). This can be avoided if aliases are never used in the data section of MX RRs. I am not taking it out of context. It is very explicitly stated. And the context is that of locating the target/remote host by first submitting an MX query, then submitting an A query of the MX query result. The text you quote is ONLY talking about the MX query. There is no then submitting an A query of the MX query result at this point in the RFC. The MX query result is permitted to be and alias, which in turn when submitted for an A query results in both the A and CNAME being returned. Thus meeting the SMTP RFC requirements. - Original Message - From: Mark Andrews mark_andr...@isc.org To: Al Stu al_...@verizon.net Cc: bind-users@lists.isc.org Sent: Monday, January 26, 2009 8:41 PM Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal In message 3c802402a28c4b2390b088242a91f...@ahsnbw1, Al Stu writes: RFC 974: There is one other special case. If the response contains an answer which is a CNAME RR, it indicates that
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal
In article glma06$8d...@sf1.isc.org, Mark Andrews mark_andr...@isc.org wrote: Liberal in what you accepts means don't die on arbitary input. You should still reject rubbish. But MX pointing to CNAME is not rubbish. It's a violation of the letter of the spec, but it's very clear what is intended. -- Barry Margolin, bar...@alum.mit.edu Arlington, MA *** PLEASE don't copy me on replies, I'll read them in the group *** ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal
In article glmqqb$jv...@sf1.isc.org, mlel...@serpens.de (Michael van Elst) wrote: Barry Margolin bar...@alum.mit.edu writes: customer.com. IN MX 10 mx.yourdomain.com. mx.yourdomain.com. IN CNAME mx.outsourcer.com. mx.outsourcer.com. IN A ... That's just the same as | customer.com. IN MX 10 mx.outsourcer.com. | mx.outsourcer.com. IN A ... except to people with half-a-knowledge about DNS queries. It's the same in layer 7, but not in layer 8. If you decide to change outsourcing companies, you have to get hundreds of customers to change their MX records, instead of just changing one CNAME record. I used to work at an ISP, and we provided slave DNS for many customers. At various times we had to change the names and/or addresses of our servers, as the business grew (e.g. when we acquired other companies, and wanted to migrate the domains they were hosting to our servers). We frequently saw obsolete glue records in our customers' domains years after these changes, and they often found their way into caches so they interfered with other domains we hosted as well. So anything you can do to avoid depending on customers to make changes at their end makes operating a business easier. -- Barry Margolin, bar...@alum.mit.edu Arlington, MA *** PLEASE don't copy me on replies, I'll read them in the group *** ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal
In article glnemv$10n...@sf1.isc.org, Matus UHLAR - fantomas uh...@fantomas.sk wrote: On 27.01.09 08:46, Al Stu wrote: So then you disagree that the following example returns a valid address record for srv1? srv1 300 IN A 1.2.3.4 mx1 300 IN CNAME srv1.xyz.com. @ 300 IN MX 1 mx1.xyz.com. 1) Select Target Host: The MX query for xyz.com delivers mx1.xyz.com which is a CNAME. 2) Get Target Host Address: The A query for mx1.xyz.com delivers the address (A) record of srv1.xyz.com, 1.2.3.4, and also delivers the alias (CNAME) record of mx1.xyz.com. They are two queries. If mx1 would be an A, it would be returned in the first query. Since it's a CNAME, the IP is not returned in the MX query. So what? If the IP isn't in the additional section, the client will do its own A query. There's no requirement that the response to the MX record include the A record. It's nice if it does, since it saves a query, but this is just an optimization. -- Barry Margolin, bar...@alum.mit.edu Arlington, MA *** PLEASE don't copy me on replies, I'll read them in the group *** ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal
On 27.01.09 08:46, Al Stu wrote: So then you disagree that the following example returns a valid address record for srv1? srv1 300 IN A 1.2.3.4 mx1 300 IN CNAME srv1.xyz.com. @ 300 IN MX 1 mx1.xyz.com. 1) Select Target Host: The MX query for xyz.com delivers mx1.xyz.com which is a CNAME. 2) Get Target Host Address: The A query for mx1.xyz.com delivers the address (A) record of srv1.xyz.com, 1.2.3.4, and also delivers the alias (CNAME) record of mx1.xyz.com. In article glnemv$10n...@sf1.isc.org, Matus UHLAR - fantomas uh...@fantomas.sk wrote: They are two queries. If mx1 would be an A, it would be returned in the first query. Since it's a CNAME, the IP is not returned in the MX query. On 27.01.09 23:51, Barry Margolin wrote: So what? If the IP isn't in the additional section, the client will do its own A query. so the client has to do an A query, because A is not returned in the MX query. There's no requirement that the response to the MX record include the A record. It's nice if it does, since it saves a query, but this is just an optimization. exactly. That's what I was trying to explain. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Windows 2000: 640 MB ought to be enough for anybody ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal
I have not copied the entire thread. You've added an additional step in your second paragraph that is prohibited by the section you quoted in the first. The section from the RFC describes a situation where A is queried for and an MX record pointing to B is returned. When B is queried for, an address record MUST be the answer. The situation you have described is that A is queried for resulting in an MX record pointing to B. When B is queried for, a CNAME pointing to C is returned, and that when C is queried an address record is returned. Do you see the difference? The RFCs are quite clear that CNAMEs are not permitted in the RDATA for an MX. If I have in DNS cn IN CNAME realname and I query for cn, the DNS resolver will return realname. BIND also returns the A record for realname. Is this a requirement? If not, then mx IN 10 MX cn will result in: 1) the MX query returning cn, 2) the cn query returning realname, 3) a third (and RFC-breaking) query to get the A for realname. There are only two queries if the resolver returns the A record along with the realname of the CNAME record. -- Barry S. Finkel Computing and Information Systems Division Argonne National Laboratory Phone:+1 (630) 252-7277 9700 South Cass Avenue Facsimile:+1 (630) 252-4601 Building 222, Room D209 Internet: bsfin...@anl.gov Argonne, IL 60439-4828 IBMMAIL: I1004994 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal
On 26.01.09 09:19, bsfin...@anl.gov wrote: If I have in DNS cn IN CNAME realname and I query for cn, the DNS resolver will return realname. BIND also returns the A record for realname. Is this a requirement? If not, then mx IN 10 MX cn will result in: 1) the MX query returning cn, 2) the cn query returning realname, 3) a third (and RFC-breaking) query to get the A for realname. There are only two queries if the resolver returns the A record along with the realname of the CNAME record. according to RFC1035 sect. 3.3.9 MX records cause type A additional section processing for the host specified by EXCHANGE. according to RFC2181 sect 10.3. The domain name used as the value of a NS resource record, or part of the value of a MX resource record must not be an alias. It can also have other RRs, but never a CNAME RR. Additional section processing does not include CNAME records... Thus, if an alias is used as the value of an NS or MX record, no address will be returned with the NS or MX value. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. The box said 'Requires Windows 95 or better', so I bought a Macintosh. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal
Thus, if an alias is used as the value of an NS or MX record, no address will be returned with the NS or MX value. Above statement, belief, perception etc. has already been proven to be a fallacy (see the network trace attached to one of the previous messages). Both the CNAME and A record is in fact returned, unless the CNAME RR points to some other zone such as say smtp.googlemail.com. So within the zone SMTP requirements are in fact met when the MX RR is a CNAME. So there is no need to prevent this nor to label it as illegal. The MX RR CNAME check should be improved to include this case and not throw a message if the MX RR CNAME is resolvable within the zone. - Original Message - From: Matus UHLAR - fantomas uh...@fantomas.sk To: bind-users@lists.isc.org Sent: Monday, January 26, 2009 8:18 AM Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal On 26.01.09 09:19, bsfin...@anl.gov wrote: If I have in DNS cn IN CNAME realname and I query for cn, the DNS resolver will return realname. BIND also returns the A record for realname. Is this a requirement? If not, then mx IN 10 MX cn will result in: 1) the MX query returning cn, 2) the cn query returning realname, 3) a third (and RFC-breaking) query to get the A for realname. There are only two queries if the resolver returns the A record along with the realname of the CNAME record. according to RFC1035 sect. 3.3.9 MX records cause type A additional section processing for the host specified by EXCHANGE. according to RFC2181 sect 10.3. The domain name used as the value of a NS resource record, or part of the value of a MX resource record must not be an alias. It can also have other RRs, but never a CNAME RR. Additional section processing does not include CNAME records... Thus, if an alias is used as the value of an NS or MX record, no address will be returned with the NS or MX value. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. The box said 'Requires Windows 95 or better', so I bought a Macintosh. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal
On Tue, 2009-01-27 at 07:43, Danny Thomas wrote: Al Stu wrote: So within the zone SMTP requirements are in fact met when the MX RR is a CNAME. you might argue the line of it being OK when additional processing includes an A record. In all the time its taken him to type his rants and raves and have his little dummy spit, he could have gone and changed the MX to be a real name, and not bored the rest of us because he cant read modern RFC's. Possible courses of action * disable the check-mx-cname in your config As was pointed out to him days ago, but yet he persists in trolling, I like most I suspect stopped reading his rants days ago. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal
In all the time its taken him to type his rants and raves and have his little dummy spit, he could have gone and changed the MX to be a real name, ... - Noel Butler Wow, such narrow mindedness. I like most I suspect stopped reading his rants days ago. - Noel Butler And yet here you are continuing to proliferate the thread. Thank you! - Original Message - From: Noel Butler To: Danny Thomas Cc: bind-users@lists.isc.org Sent: Monday, January 26, 2009 2:23 PM Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal On Tue, 2009-01-27 at 07:43, Danny Thomas wrote: Al Stu wrote: So within the zone SMTP requirements are in fact met when the MX RR is a CNAME. you might argue the line of it being OK when additional processing includes an A record. In all the time its taken him to type his rants and raves and have his little dummy spit, he could have gone and changed the MX to be a real name, and not bored the rest of us because he cant read modern RFC's. Possible courses of action * disable the check-mx-cname in your config As was pointed out to him days ago, but yet he persists in trolling, I like most I suspect stopped reading his rants days ago. -- ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal
In message 2d378cb064ba4d06880aed8ed81f3...@ahsnbw1, Al Stu writes: Thus, if an alias is used as the value of an NS or MX record, no address will be returned with the NS or MX value. Above statement, belief, perception etc. has already been proven to be a fallacy (see the network trace attached to one of the previous messages). Both the CNAME and A record is in fact returned, unless the CNAME RR points to some other zone such as say smtp.googlemail.com. Please show one vendor that follows a CNAME when processing the *additional* section. AFAIK there is no vendor that does this. Named doesn't. CNAME is followed when processing the *answer* section. So within the zone SMTP requirements are in fact met when the MX RR is a CNAME. So there is no need to prevent this nor to label it as illegal. The MX RR CNAME check should be improved to include this case and not throw a message if the MX RR CNAME is resolvable within the zone. A lot of the reason why people think they can do this is that it doesn't always blow up in their faces when they do it. When there is only one MX record and that name points to a CNAME the MX records are not looked up on the mail exchanger so things don't blow up. Have multiple MX records with different preferences and point those at CNAMEs then thing start blowing up because the higher preference mail exchanger does lookup the MX RRset and does processes it. That is when things blow up. The rules are there to prevent this situation. The message is staying. If you don't want to see it turn it off in named.conf but don't log a bug report complaining that we didn't detect the misconfiguration. Mark - Original Message - From: Matus UHLAR - fantomas uh...@fantomas.sk To: bind-users@lists.isc.org Sent: Monday, January 26, 2009 8:18 AM Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal On 26.01.09 09:19, bsfin...@anl.gov wrote: If I have in DNS cn IN CNAME realname and I query for cn, the DNS resolver will return realname. BIND also returns the A record for realname. Is this a requirement? If not, then mx IN 10 MX cn will result in: 1) the MX query returning cn, 2) the cn query returning realname, 3) a third (and RFC-breaking) query to get the A for realname. There are only two queries if the resolver returns the A record along with the realname of the CNAME record. according to RFC1035 sect. 3.3.9 MX records cause type A additional section processing for the host specified by EXCHANGE. according to RFC2181 sect 10.3. The domain name used as the value of a NS resource record, or part of the value of a MX resource record must not be an alias. It can also have other RRs, but never a CNAME RR. Additional section processing does not include CNAME records... Thus, if an alias is used as the value of an NS or MX record, no address will be returned with the NS or MX value. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. The box said 'Requires Windows 95 or better', so I bought a Macintosh. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal
How about these two? nullmx.domainmanager.com Non-authoritative answer: Name:mta.dewile.net Address: 69.59.189.80 Aliases: nullmx.domainmanager.com smtp.secureserver.net Non-authoritative answer: Name:smtp.where.secureserver.net Address: 208.109.80.149 Aliases: smtp.secureserver.net There are two reasons it does not blow up in peoples face. 1) If it is in the CNAME RR points to an A record in the same zone, both the A record and the CNAME record are returned, thus meeting the A record requirement. 2) SMTP servers are required to accept an alias and look it up. Thus there is no need for this. And no it does not matter if there are multiple MX records with different preferences values. - Original Message - From: Mark Andrews mark_andr...@isc.org To: Al Stu al_...@verizon.net Cc: bind-users@lists.isc.org Sent: Monday, January 26, 2009 2:55 PM Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal In message 2d378cb064ba4d06880aed8ed81f3...@ahsnbw1, Al Stu writes: Thus, if an alias is used as the value of an NS or MX record, no address will be returned with the NS or MX value. Above statement, belief, perception etc. has already been proven to be a fallacy (see the network trace attached to one of the previous messages). Both the CNAME and A record is in fact returned, unless the CNAME RR points to some other zone such as say smtp.googlemail.com. Please show one vendor that follows a CNAME when processing the *additional* section. AFAIK there is no vendor that does this. Named doesn't. CNAME is followed when processing the *answer* section. So within the zone SMTP requirements are in fact met when the MX RR is a CNAME. So there is no need to prevent this nor to label it as illegal. The MX RR CNAME check should be improved to include this case and not throw a message if the MX RR CNAME is resolvable within the zone. A lot of the reason why people think they can do this is that it doesn't always blow up in their faces when they do it. When there is only one MX record and that name points to a CNAME the MX records are not looked up on the mail exchanger so things don't blow up. Have multiple MX records with different preferences and point those at CNAMEs then thing start blowing up because the higher preference mail exchanger does lookup the MX RRset and does processes it. That is when things blow up. The rules are there to prevent this situation. The message is staying. If you don't want to see it turn it off in named.conf but don't log a bug report complaining that we didn't detect the misconfiguration. Mark - Original Message - From: Matus UHLAR - fantomas uh...@fantomas.sk To: bind-users@lists.isc.org Sent: Monday, January 26, 2009 8:18 AM Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal On 26.01.09 09:19, bsfin...@anl.gov wrote: If I have in DNS cn IN CNAME realname and I query for cn, the DNS resolver will return realname. BIND also returns the A record for realname. Is this a requirement? If not, then mx IN 10 MX cn will result in: 1) the MX query returning cn, 2) the cn query returning realname, 3) a third (and RFC-breaking) query to get the A for realname. There are only two queries if the resolver returns the A record along with the realname of the CNAME record. according to RFC1035 sect. 3.3.9 MX records cause type A additional section processing for the host specified by EXCHANGE. according to RFC2181 sect 10.3. The domain name used as the value of a NS resource record, or part of the value of a MX resource record must not be an alias. It can also have other RRs, but never a CNAME RR. Additional section processing does not include CNAME records... Thus, if an alias is used as the value of an NS or MX record, no address will be returned with the NS or MX value. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. The box said 'Requires Windows 95 or better', so I bought a Macintosh. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal
In message 0aa37ce829ba458b9ba2d199a6d96...@ahsnbw1, Al Stu writes: How about these two? nullmx.domainmanager.com Non-authoritative answer: Name:mta.dewile.net Address: 69.59.189.80 Aliases: nullmx.domainmanager.com smtp.secureserver.net Non-authoritative answer: Name:smtp.where.secureserver.net Address: 208.109.80.149 Aliases: smtp.secureserver.net Which just goes to show you don't understand the issue. Ask the correct question and you will see a response which demonstates what people are talking about. If the server was doing what you say it does you would see the CNAME in the additional section. ; DiG 9.3.6-P1 mx secureserver.net @cns2.secureserver.net. +norec ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 21506 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;secureserver.net. IN MX ;; ANSWER SECTION: secureserver.net. 3600IN MX 0 smtp.secureserver.net. ;; AUTHORITY SECTION: secureserver.net. 3600IN NS cns2.secureserver.net. secureserver.net. 3600IN NS cns1.secureserver.net. ;; ADDITIONAL SECTION: cns1.secureserver.net. 3600IN A 208.109.255.100 cns2.secureserver.net. 3600IN A 216.69.185.100 ;; Query time: 181 msec ;; SERVER: 216.69.185.100#53(216.69.185.100) ;; WHEN: Tue Jan 27 12:54:26 2009 ;; MSG SIZE rcvd: 125 There are two reasons it does not blow up in peoples face. 1) If it is in the CNAME RR points to an A record in the same zone, both the A record and the CNAME record are returned, thus meeting the A record requirement. 2) SMTP servers are required to accept an alias and look it up. Thus there is no need for this. And no it does not matter if there are multiple MX records with different preferences values. Which just means you have not ever experienced the problems causes. MTA are not required to look up the addresses of all the mail exchangers in the MX RRset to process the MX RRset. MTA usually learn their name by gethostname() or similar and that name is not a CNAME or there is a misconfiguration. The fact that email still gets delivered in the presence of misconfigurations is good luck rather than good management. Mark - Original Message - From: Mark Andrews mark_andr...@isc.org To: Al Stu al_...@verizon.net Cc: bind-users@lists.isc.org Sent: Monday, January 26, 2009 2:55 PM Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal In message 2d378cb064ba4d06880aed8ed81f3...@ahsnbw1, Al Stu writes: Thus, if an alias is used as the value of an NS or MX record, no address will be returned with the NS or MX value. Above statement, belief, perception etc. has already been proven to be a fallacy (see the network trace attached to one of the previous messages). Both the CNAME and A record is in fact returned, unless the CNAME RR points to some other zone such as say smtp.googlemail.com. Please show one vendor that follows a CNAME when processing the *additional* section. AFAIK there is no vendor that does this. Named doesn't. CNAME is followed when processing the *answer* section. So within the zone SMTP requirements are in fact met when the MX RR is a CNAME. So there is no need to prevent this nor to label it as illegal. The MX RR CNAME check should be improved to include this case and not throw a message if the MX RR CNAME is resolvable within the zone. A lot of the reason why people think they can do this is that it doesn't always blow up in their faces when they do it. When there is only one MX record and that name points to a CNAME the MX records are not looked up on the mail exchanger so things don't blow up. Have multiple MX records with different preferences and point those at CNAMEs then thing start blowing up because the higher preference mail exchanger does lookup the MX RRset and does processes it. That is when things blow up. The rules are there to prevent this situation. The message is staying. If you don't want to see it turn it off in named.conf but don't log a bug report complaining that we didn't detect the misconfiguration. Mark - Original Message - From: Matus UHLAR - fantomas uh...@fantomas.sk To: bind-users@lists.isc.org Sent: Monday, January 26, 2009 8:18 AM Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal On 26.01.09 09:19, bsfin...@anl.gov wrote: If I have in DNS cn IN CNAME realname and I query for cn, the DNS resolver will return realname. BIND also returns the A record for realname. Is this a requirement? If not, then mx IN 10 MX cn will result in: 1) the MX query
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal
On Jan 26, 2009, at 6:17 PM, Mark Andrews wrote: Which just means you have not ever experienced the problems causes. MTA are not required to look up the addresses of all the mail exchangers in the MX RRset to process the MX RRset. MTA usually learn their name by gethostname() or similar and that name is not a CNAME or there is a misconfiguration. The fact that email still gets delivered in the presence of misconfigurations is good luck rather than good management. 100% right. I refuse MX's that are cnamed, and I get emails from customers asking what is up. What is strange, and I can not figure it out, is that the admins of the DNS/email server always tell me this is the first time they have heard of it. Despite me pointing them to RFC on the matter, since it has worked in the past, they think it is my MTA that is wrong. I hate to budge on it, as this is a simple thing to understand and fix, but it seems many other email servers out there will run up and down a DNS server to find any address they can. In the end, they almost always refuse to change their DNS, and I and up making a static route for them. They change the record later, and then it breaks. I have never got why this is such a hard thing for email admins to get right, but it certainly causes me headaches. I personally wish CNAME's would just go away, keep them around, but just stop talking about them, then new to DNS users would not use them. -- Scott ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal
If you refuse a CNAME then it is your SMTP server that is broken. The SMTP RFC's clearly state that SMTP servers are to accept and lookup a CNAME. - Original Message - From: Scott Haneda talkli...@newgeo.com To: Mark Andrews mark_andr...@isc.org Cc: Al Stu al_...@verizon.net; bind-users@lists.isc.org Sent: Monday, January 26, 2009 6:24 PM Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal On Jan 26, 2009, at 6:17 PM, Mark Andrews wrote: Which just means you have not ever experienced the problems causes. MTA are not required to look up the addresses of all the mail exchangers in the MX RRset to process the MX RRset. MTA usually learn their name by gethostname() or similar and that name is not a CNAME or there is a misconfiguration. The fact that email still gets delivered in the presence of misconfigurations is good luck rather than good management. 100% right. I refuse MX's that are cnamed, and I get emails from customers asking what is up. What is strange, and I can not figure it out, is that the admins of the DNS/email server always tell me this is the first time they have heard of it. Despite me pointing them to RFC on the matter, since it has worked in the past, they think it is my MTA that is wrong. I hate to budge on it, as this is a simple thing to understand and fix, but it seems many other email servers out there will run up and down a DNS server to find any address they can. In the end, they almost always refuse to change their DNS, and I and up making a static route for them. They change the record later, and then it breaks. I have never got why this is such a hard thing for email admins to get right, but it certainly causes me headaches. I personally wish CNAME's would just go away, keep them around, but just stop talking about them, then new to DNS users would not use them. -- Scott ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal
On Jan 26, 2009, at 7:54 PM, Al Stu wrote: If you refuse a CNAME then it is your SMTP server that is broken. The SMTP RFC's clearly state that SMTP servers are to accept and lookup a CNAME. [RFC974] explicitly states that MX records shall not point to an alias defined by a CNAME. That is what I was talking about, are you saying this is not correct? As this is what I was under the impression for quite some time. -- Scott ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal
RFC 974: There is one other special case. If the response contains an answer which is a CNAME RR, it indicates that REMOTE is actually an alias for some other domain name. The query should be repeated with the canonical domain name. - Original Message - From: Scott Haneda talkli...@newgeo.com To: Al Stu al_...@verizon.net Cc: bind-users@lists.isc.org Sent: Monday, January 26, 2009 8:09 PM Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal On Jan 26, 2009, at 7:54 PM, Al Stu wrote: If you refuse a CNAME then it is your SMTP server that is broken. The SMTP RFC's clearly state that SMTP servers are to accept and lookup a CNAME. [RFC974] explicitly states that MX records shall not point to an alias defined by a CNAME. That is what I was talking about, are you saying this is not correct? As this is what I was under the impression for quite some time. -- Scott ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal
In message 3c802402a28c4b2390b088242a91f...@ahsnbw1, Al Stu writes: RFC 974: There is one other special case. If the response contains an answer which is a CNAME RR, it indicates that REMOTE is actually an alias for some other domain name. The query should be repeated with the canonical domain name. And that is talking about the response to a MX query. The section from which you quote starts with: Issuing a Query The first step for the mailer at LOCAL is to issue a query for MX RRs for REMOTE. It is strongly urged that this step be taken every time a mailer attempts to send the message. The hope is that changes in the domain database will rapidly be used by mailers, and thus domain administrators will be able to re-route in-transit messages for defective hosts by simply changing their domain databases. and the paragraph after that which you quote is: If the response does not contain an error response, and does not contain aliases, its answer section should be a (possibly zero length) list of MX RRs for domain name REMOTE (or REMOTE's true domain name if REMOTE was a alias). The next section describes how this list is interpreted. So I would suggest that you stop taking text out of context. CNAME - MX is legal MX - CNAME is illegal Mark - Original Message - From: Scott Haneda talkli...@newgeo.com To: Al Stu al_...@verizon.net Cc: bind-users@lists.isc.org Sent: Monday, January 26, 2009 8:09 PM Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal On Jan 26, 2009, at 7:54 PM, Al Stu wrote: If you refuse a CNAME then it is your SMTP server that is broken. The SMTP RFC's clearly state that SMTP servers are to accept and lookup a CNAME. [RFC974] explicitly states that MX records shall not point to an alias defined by a CNAME. That is what I was talking about, are you saying this is not correct? As this is what I was under the impression for quite some time. -- Scott ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal
Yes, the response to an MX query, that is the subject here. And a CNAME is in fact permitted and specified by the RFC's to be accepted as the response to an MX lookup. If the response does not contain an error response, and does not contain aliases See there, alias is permitted. You just keep proving the my case. I am not taking it out of context. It is very explicitly stated. And the context is that of locating the target/remote host by first submitting an MX query, then submitting an A query of the MX query result. The MX query result is permitted to be and alias, which in turn when submitted for an A query results in both the A and CNAME being returned. Thus meeting the SMTP RFC requirements. - Original Message - From: Mark Andrews mark_andr...@isc.org To: Al Stu al_...@verizon.net Cc: bind-users@lists.isc.org Sent: Monday, January 26, 2009 8:41 PM Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal In message 3c802402a28c4b2390b088242a91f...@ahsnbw1, Al Stu writes: RFC 974: There is one other special case. If the response contains an answer which is a CNAME RR, it indicates that REMOTE is actually an alias for some other domain name. The query should be repeated with the canonical domain name. And that is talking about the response to a MX query. The section from which you quote starts with: Issuing a Query The first step for the mailer at LOCAL is to issue a query for MX RRs for REMOTE. It is strongly urged that this step be taken every time a mailer attempts to send the message. The hope is that changes in the domain database will rapidly be used by mailers, and thus domain administrators will be able to re-route in-transit messages for defective hosts by simply changing their domain databases. and the paragraph after that which you quote is: If the response does not contain an error response, and does not contain aliases, its answer section should be a (possibly zero length) list of MX RRs for domain name REMOTE (or REMOTE's true domain name if REMOTE was a alias). The next section describes how this list is interpreted. So I would suggest that you stop taking text out of context. CNAME - MX is legal MX - CNAME is illegal Mark - Original Message - From: Scott Haneda talkli...@newgeo.com To: Al Stu al_...@verizon.net Cc: bind-users@lists.isc.org Sent: Monday, January 26, 2009 8:09 PM Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal On Jan 26, 2009, at 7:54 PM, Al Stu wrote: If you refuse a CNAME then it is your SMTP server that is broken. The SMTP RFC's clearly state that SMTP servers are to accept and lookup a CNAME. [RFC974] explicitly states that MX records shall not point to an alias defined by a CNAME. That is what I was talking about, are you saying this is not correct? As this is what I was under the impression for quite some time. -- Scott ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal
In message b3ba5e37553642e28149093cdee78...@ahsnbw1, Al Stu writes: Yes, the response to an MX query, that is the subject here. And a CNAME is in fact permitted and specified by the RFC's to be accepted as the response to an MX lookup. No one is saying a CNAME is not permitted in response to a MX query. If the response does not contain an error response, and does not contain aliases See there, alias is permitted. You just keep proving the my case. We are saying that when you lookup the address of the mail exchanger that you shouldn't get a CNAME record. MX - CNAME is not permitted. Others have quoted similar text from more recent RFC's. RFC 974 Note that the algorithm to delete irrelevant RRs breaks if LOCAL has a alias and the alias is listed in the MX records for REMOTE. (E.g. REMOTE has an MX of ALIAS, where ALIAS has a CNAME of LOCAL). This can be avoided if aliases are never used in the data section of MX RRs. I am not taking it out of context. It is very explicitly stated. And the context is that of locating the target/remote host by first submitting an MX query, then submitting an A query of the MX query result. The text you quote is ONLY talking about the MX query. There is no then submitting an A query of the MX query result at this point in the RFC. The MX query result is permitted to be and alias, which in turn when submitted for an A query results in both the A and CNAME being returned. Thus meeting the SMTP RFC requirements. - Original Message - From: Mark Andrews mark_andr...@isc.org To: Al Stu al_...@verizon.net Cc: bind-users@lists.isc.org Sent: Monday, January 26, 2009 8:41 PM Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal In message 3c802402a28c4b2390b088242a91f...@ahsnbw1, Al Stu writes: RFC 974: There is one other special case. If the response contains an answer which is a CNAME RR, it indicates that REMOTE is actually an alias for some other domain name. The query should be repeated with the canonical domain name. And that is talking about the response to a MX query. The section from which you quote starts with: Issuing a Query The first step for the mailer at LOCAL is to issue a query for MX RRs for REMOTE. It is strongly urged that this step be taken every time a mailer attempts to send the message. The hope is that changes in the domain database will rapidly be used by mailers, and thus domain administrators will be able to re-route in-transit messages for defective hosts by simply changing their domain databases. and the paragraph after that which you quote is: If the response does not contain an error response, and does not contain aliases, its answer section should be a (possibly zero length) list of MX RRs for domain name REMOTE (or REMOTE's true domain name if REMOTE was a alias). The next section describes how this list is interpreted. So I would suggest that you stop taking text out of context. CNAME - MX is legal MX - CNAME is illegal Mark - Original Message - From: Scott Haneda talkli...@newgeo.com To: Al Stu al_...@verizon.net Cc: bind-users@lists.isc.org Sent: Monday, January 26, 2009 8:09 PM Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal On Jan 26, 2009, at 7:54 PM, Al Stu wrote: If you refuse a CNAME then it is your SMTP server that is broken. The SMTP RFC's clearly state that SMTP servers are to accept and lookup a CNAME. [RFC974] explicitly states that MX records shall not point to an alias defined by a CNAME. That is what I was talking about, are you saying this is not correct? As this is what I was under the impression for quite some time. -- Scott ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal
In article gllr91$2vq...@sf1.isc.org, Scott Haneda talkli...@newgeo.com wrote: I have never got why this is such a hard thing for email admins to get right, but it certainly causes me headaches. I personally wish CNAME's would just go away, keep them around, but just stop talking about them, then new to DNS users would not use them. Suppose you're providing an MX service, but you actually out-source the operation to a third party. You want to give your customers an MX record that points to a name in your domain, so they don't need to know about the third party (and so you have the flexibility to change your out-sourcing without requiring all customers to update their MX record). But the third party also needs the flexibility to change the IP of the server, load balancing, disaster recovery, changing ISPs, etc. So they don't want you to hard-code their IPs into your domain. CNAMEs are the simplest solution to implementing all this. customer.com. IN MX 10 mx.yourdomain.com. mx.yourdomain.com. IN CNAME mx.outsourcer.com. mx.outsourcer.com. IN A ... If the customer changes MX services, they change their MX record. If you change outsourcing companies, you change your CNAME record. And if the outsourcing company re-IPs their server, they change the A record. Everyone can perform their job without having to make any of the downstream customers adjust their records. -- Barry Margolin, bar...@alum.mit.edu Arlington, MA *** PLEASE don't copy me on replies, I'll read them in the group *** ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal
In article glm61r$5l...@sf1.isc.org, Al Stu al_...@verizon.net wrote: Yes, the response to an MX query, that is the subject here. And a CNAME is in fact permitted and specified by the RFC's to be accepted as the response to an MX lookup. No, we're talking about the response to the A query for the name that the MX points to. The section below is talking about the response to the original MX query. E.g. when sending mail to f...@mail.company.com, mail.company.com is allowed to be a CNAME. So you can have: mail.company.com. CNAME company.com. company.com. MX 10 mx.company.com. but you still aren't supposed to have: mx.company.com. CNAME mxserver.company.com. If the response does not contain an error response, and does not contain aliases See there, alias is permitted. You just keep proving the my case. I am not taking it out of context. It is very explicitly stated. And the context is that of locating the target/remote host by first submitting an MX query, then submitting an A query of the MX query result. The MX query result is permitted to be and alias, which in turn when submitted for an A query results in both the A and CNAME being returned. Thus meeting the SMTP RFC requirements. - Original Message - From: Mark Andrews mark_andr...@isc.org To: Al Stu al_...@verizon.net Cc: bind-users@lists.isc.org Sent: Monday, January 26, 2009 8:41 PM Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal In message 3c802402a28c4b2390b088242a91f...@ahsnbw1, Al Stu writes: RFC 974: There is one other special case. If the response contains an answer which is a CNAME RR, it indicates that REMOTE is actually an alias for some other domain name. The query should be repeated with the canonical domain name. And that is talking about the response to a MX query. The section from which you quote starts with: Issuing a Query The first step for the mailer at LOCAL is to issue a query for MX RRs for REMOTE. It is strongly urged that this step be taken every time a mailer attempts to send the message. The hope is that changes in the domain database will rapidly be used by mailers, and thus domain administrators will be able to re-route in-transit messages for defective hosts by simply changing their domain databases. and the paragraph after that which you quote is: If the response does not contain an error response, and does not contain aliases, its answer section should be a (possibly zero length) list of MX RRs for domain name REMOTE (or REMOTE's true domain name if REMOTE was a alias). The next section describes how this list is interpreted. So I would suggest that you stop taking text out of context. CNAME - MX is legal MX - CNAME is illegal Mark - Original Message - From: Scott Haneda talkli...@newgeo.com To: Al Stu al_...@verizon.net Cc: bind-users@lists.isc.org Sent: Monday, January 26, 2009 8:09 PM Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal On Jan 26, 2009, at 7:54 PM, Al Stu wrote: If you refuse a CNAME then it is your SMTP server that is broken. The SMTP RFC's clearly state that SMTP servers are to accept and lookup a CNAME. [RFC974] explicitly states that MX records shall not point to an alias defined by a CNAME. That is what I was talking about, are you saying this is not correct? As this is what I was under the impression for quite some time. -- Scott ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Barry Margolin, bar...@alum.mit.edu Arlington, MA *** PLEASE don't copy me on replies, I'll read them in the group *** ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal
On Jan 26, 2009, at 10:03 PM, Barry Margolin wrote: In article gllr91$2vq...@sf1.isc.org, Scott Haneda talkli...@newgeo.com wrote: 100% right. I refuse MX's that are cnamed, and I get emails from customers asking what is up. What is strange, and I can not figure it out, is that the admins of the DNS/email server always tell me this is the first time they have heard of it. So you're not following the be liberal in what you accept half of the Interoperability Principle, which is intended specifically to avoid problems due to such confusion. Because that worked so well for HTML :) I was thinking about that quote just the other day. To be honest, I think it applies well to social issues, but not technical or engineering/programming ones. The second you accept liberally, that tells the submitter that it is ok. I am hard pressed to think of one case in which liberally accepting data is a good thing. It is that very expression that defines why we have bpisometextpbi Just consider the ramifications of parsing that one simple string, which is now non trivial to parse. What is C worked this way? Just some thoughts I was having the other day. -- Scott ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal
On Jan 26, 2009, at 10:11 PM, Barry Margolin wrote: In article gllr91$2vq...@sf1.isc.org, Scott Haneda talkli...@newgeo.com wrote: I have never got why this is such a hard thing for email admins to get right, but it certainly causes me headaches. I personally wish CNAME's would just go away, keep them around, but just stop talking about them, then new to DNS users would not use them. Suppose you're providing an MX service, but you actually out-source the operation to a third party. You want to give your customers an MX record that points to a name in your domain, so they don't need to know about the third party (and so you have the flexibility to change your out-sourcing without requiring all customers to update their MX record). But the third party also needs the flexibility to change the IP of the server, load balancing, disaster recovery, changing ISPs, etc. So they don't want you to hard-code their IPs into your domain. CNAMEs are the simplest solution to implementing all this. customer.com. IN MX 10 mx.yourdomain.com. mx.yourdomain.com. IN CNAME mx.outsourcer.com. mx.outsourcer.com. IN A ... If the customer changes MX services, they change their MX record. If you change outsourcing companies, you change your CNAME record. And if the outsourcing company re-IPs their server, they change the A record. Everyone can perform their job without having to make any of the downstream customers adjust their records. Totally valid points, I agree with them all. And it is these points that I was talking about when I suggested CNAME's go away. Not really go away, but the above case is clearly one in which the admin knows that they are doing. What my trouble is, is with the mail admins who clearly do not, and then argue about solving it. I better example is servers that do not support greylisting, and bounce on 450 code. This is pretty simple, and obvious as to why you need to try in a transient error like that. Anyway, not saying I disagree with you, I do not, but I was just venting a little. -- Scott ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal
The paragraph you cite regarding LOCAL has a alias and the alias is listed in the MX records for REMOTE... is a peripery issue which is handled by not doing that. No one is saying a CNAME is not permitted in response to a MX query. Well good then, we agree. The MX record data value can be a CNAME. That is what BIND is complaining about, and I in turn saying should be changed/removed. i.e. BIND should not complain about the following, but it does. It says the MX record is illegal. But it is not. srv1 300 IN A 1.2.3.4 mx1 300 IN CNAME srv1.xyz.com. @ 300 IN MX 1 mx1.xyz.com. The MX query for xyz.com delivers mx1.xyz.com which is a CNAME. The A query for mx1.xyz.com delivers the address (A) record of srv1.xyz.com, 1.2.3.4, and the alias (CNAME) record of mx1.xyz.com. *** PLEASE don't copy me on replies, I'll read them in the group *** - Original Message - From: Mark Andrews mark_andr...@isc.org To: Al Stu al_...@verizon.net Cc: bind-users@lists.isc.org Sent: Monday, January 26, 2009 10:03 PM Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal In message b3ba5e37553642e28149093cdee78...@ahsnbw1, Al Stu writes: Yes, the response to an MX query, that is the subject here. And a CNAME is in fact permitted and specified by the RFC's to be accepted as the response to an MX lookup. No one is saying a CNAME is not permitted in response to a MX query. If the response does not contain an error response, and does not contain aliases See there, alias is permitted. You just keep proving the my case. We are saying that when you lookup the address of the mail exchanger that you shouldn't get a CNAME record. MX - CNAME is not permitted. Others have quoted similar text from more recent RFC's. RFC 974 Note that the algorithm to delete irrelevant RRs breaks if LOCAL has a alias and the alias is listed in the MX records for REMOTE. (E.g. REMOTE has an MX of ALIAS, where ALIAS has a CNAME of LOCAL). This can be avoided if aliases are never used in the data section of MX RRs. I am not taking it out of context. It is very explicitly stated. And the context is that of locating the target/remote host by first submitting an MX query, then submitting an A query of the MX query result. The text you quote is ONLY talking about the MX query. There is no then submitting an A query of the MX query result at this point in the RFC. The MX query result is permitted to be and alias, which in turn when submitted for an A query results in both the A and CNAME being returned. Thus meeting the SMTP RFC requirements. - Original Message - From: Mark Andrews mark_andr...@isc.org To: Al Stu al_...@verizon.net Cc: bind-users@lists.isc.org Sent: Monday, January 26, 2009 8:41 PM Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal In message 3c802402a28c4b2390b088242a91f...@ahsnbw1, Al Stu writes: RFC 974: There is one other special case. If the response contains an answer which is a CNAME RR, it indicates that REMOTE is actually an alias for some other domain name. The query should be repeated with the canonical domain name. And that is talking about the response to a MX query. The section from which you quote starts with: Issuing a Query The first step for the mailer at LOCAL is to issue a query for MX RRs for REMOTE. It is strongly urged that this step be taken every time a mailer attempts to send the message. The hope is that changes in the domain database will rapidly be used by mailers, and thus domain administrators will be able to re-route in-transit messages for defective hosts by simply changing their domain databases. and the paragraph after that which you quote is: If the response does not contain an error response, and does not contain aliases, its answer section should be a (possibly zero length) list of MX RRs for domain name REMOTE (or REMOTE's true domain name if REMOTE was a alias). The next section describes how this list is interpreted. So I would suggest that you stop taking text out of context. CNAME - MX is legal MX - CNAME is illegal Mark - Original Message - From: Scott Haneda talkli...@newgeo.com To: Al Stu al_...@verizon.net Cc: bind-users@lists.isc.org Sent: Monday, January 26, 2009 8:09 PM Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal On Jan 26, 2009, at 7:54 PM, Al Stu wrote: If you refuse a CNAME then it is your SMTP server that is broken. The SMTP RFC's clearly state that SMTP servers are to accept and lookup a CNAME. [RFC974] explicitly states that MX records shall not point to an alias defined by a CNAME. That is what I was talking about, are you saying this is not correct? As this is what I was under the impression for quite some time. -- Scott ___ bind-users mailing
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal
In message bc7c01a4-1803-4906-bd90-93037b4ae...@newgeo.com, Scott Haneda writ es: On Jan 26, 2009, at 10:03 PM, Barry Margolin wrote: In article gllr91$2vq...@sf1.isc.org, Scott Haneda talkli...@newgeo.com wrote: 100% right. I refuse MX's that are cnamed, and I get emails from customers asking what is up. What is strange, and I can not figure it out, is that the admins of the DNS/email server always tell me this is the first time they have heard of it. So you're not following the be liberal in what you accept half of the Interoperability Principle, which is intended specifically to avoid problems due to such confusion. Because that worked so well for HTML :) I was thinking about that quote just the other day. To be honest, I think it applies well to social issues, but not technical or engineering/programming ones. The second you accept liberally, that tells the submitter that it is ok. I am hard pressed to think of one case in which liberally accepting data is a good thing. It is that very expression that defines why we have bpisometextpbi Just consider the ramifications of parsing that one simple string, which is now non trivial to parse. What is C worked this way? Just some thoughts I was having the other day. -- Scott ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users Liberal in what you accepts means don't die on arbitary input. You should still reject rubbish. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal
At 22:11 24-01-2009, Al Stu wrote: Some people seem to think RFC 974 creates a standard which prohibits the use of CNAME/alias in MX records. But very much to the contrary RFC 974 demonstrates that CNAME/alias is permitted in MX records. RFC 974 is obsoleted by RFC 2821; the latter is obsoleted by RFC 5321. Quoting Section 5 of that RFC: When a domain name associated with an MX RR is looked up and the associated data field obtained, the data field of that response MUST contain a domain name. That domain name, when queried, MUST return at least one address record (e.g., A or RR) that gives the IP address of the SMTP server to which the message should be directed. Any other response, specifically including a value that will return a CNAME record when queried, lies outside the scope of this Standard. The prohibition on labels in the data that resolve to CNAMEs is discussed in more detail in RFC 2181, Section 10.3. ISC's message that a CNAME/alias in an MX record is illegal is incorrect and just an attempt by ISC to get people to go along with what is only a perceived rather than actual standard/requirement, and should be removed so as not to further the fallacy of this perceived perception of a standard/requirement, as it is neither a standard nor a requirement, and certainly not illegal. Pointing to a CNAME on the right-hand side of an MX record is incorrect and may affect mail delivery. This is not about perceived perception of a requirement (see the MUST return at least one address record in the quoted text). Regards, -sm ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal
RFC 2821 is much more recent and clearly documents in sections 3.5 and 5 that CNAME MX RR are permitted and are to be handled by SMTP MTA's. 3.6 Domains Only resolvable, fully-qualified, domain names (FQDNs) are permitted when domain names are used in SMTP. In other words, names that can be resolved to MX RRs or A RRs (as discussed in section 5) are permitted, as are CNAME RRs whose targets can be resolved, in turn, to MX or A RRs. 5. Address Resolution and Mail Handling The lookup first attempts to locate an MX record associated with the name. If a CNAME record is found instead, the resulting name is processed as if it were the initial name. This is also backed up by the older RFC 974. There is one other special case. If the response contains an answer which is a CNAME RR, it indicates that REMOTE is actually an alias for some other domain name. The query should be repeated with the canonical domain name. So it is clear there should be no problem with using CNAME MX RR for mail systems that conform to these RFC's, and therefore no need for enforcing the use of only A RR, or even outputting an error/warning. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal
At 00:44 25-01-2009, Al Stu wrote: When a domain name associated with an MX RR is looked up and the associated data field obtained, the data field of that response MUST contain a domain name.That domain name, when queried, MUST return at least one address record (e.g., A or RR) that gives the IP address of the SMTP server to which the message should be directed. Correct. And when a that domain name is a CNAME pointing to an A RR the query returns not only the alias but also the real name and the IP address from the A RR. Thus meeting the requirements to return at least one address record (e.t., A or RR). But yet ISC seems to find it necessary to throw a message that it is illegal, when it clearly is not. That's a liberal interpretation of the specifications and it's the opposite of the intent of the quoted paragraph. Implementors are expected to query for an address record only. Any other behavior such as the one described in your second paragraph is undefined. Further reading of that section elaborates on what to do if a CNAME is returned and there is a reference to RFC 2181 for a discussion of the prohibition of CNAMEs on the right-end side. RFC 974 specifies the algorithm to build the list of RRs and discusses about possible issues. It's the same algorithm in RFC 2821 and RFC 5321. The confusion about CNAMEs in MX records stems from the interpretation of the text about how CNAMEs on the left-hand side are handled and that was clarified in the latest revision of the specifications. Regards, -sm ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal
On 25-Jan-2009, at 03:44 , Al Stu wrote: When a domain name associated with an MX RR is looked up and the associated data field obtained, the data field of that response MUST contain a domain name.That domain name, when queried, MUST return at least one address record (e.g., A or RR) that gives the IP address of the SMTP server to which the message should be directed. Correct. And when a that domain name is a CNAME pointing to an A RR the query returns not only the alias but also the real name and the IP address from the A RR. Thus meeting the requirements to return at least one address record (e.t., A or RR). But yet ISC seems to find it necessary to throw a message that it is illegal, when it clearly is not. You've added an additional step in your second paragraph that is prohibited by the section you quoted in the first. The section from the RFC describes a situation where A is queried for and an MX record pointing to B is returned. When B is queried for, an address record MUST be the answer. The situation you have described is that A is queried for resulting in an MX record pointing to B. When B is queried for, a CNAME pointing to C is returned, and that when C is queried an address record is returned. Do you see the difference? The RFCs are quite clear that CNAMEs are not permitted in the RDATA for an MX. PGP.sig Description: This is a digitally signed message part ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal
On Jan 25 2009, Al Stu wrote: RFC 2821 is much more recent and clearly documents in sections 3.5 and 5 that CNAME MX RR are permitted and are to be handled by SMTP MTA's. 3.6 Domains Only resolvable, fully-qualified, domain names (FQDNs) are permitted when domain names are used in SMTP. In other words, names that can be resolved to MX RRs or A RRs (as discussed in section 5) are permitted, as are CNAME RRs whose targets can be resolved, in turn, to MX or A RRs. 5. Address Resolution and Mail Handling The lookup first attempts to locate an MX record associated with the name. If a CNAME record is found instead, the resulting name is processed as if it were the initial name. These clearly refer to the case CNAME record points to MX record, which no-one has any problems with, or at least BIND certainly doesn't. The illegal case is MX record points to CNAME record, and RFC 2821 gives no sanction for that. Section 5.1 in RFC 5321 makes it even more explicit. You can, of course, turn off this particular check in BIND by specifying check-mx-cname ignore; in the options or zone statements. -- Chris Thompson Email: c...@cam.ac.uk ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal
No I do not believe an extra step was added. Take the following example for instance. STMP server smtp.xyz.com. needs to send a message to some...@xyz.com. An MX lookup is performed for domain xyz.com. and the domain name of mx.xyz.com is returned. This is the first sentence: When a domain name associated with an MX RR is looked up and the associated data field obtained, the data field of that response MUST contain a domain name. Now an A lookup is performed for that domain name of mx.xyz.com. and returned are the name srv1.xyz.com with it's address of 1.2.3.4, and the alias name of mx.xyz.com is also included in the result. This is the second sentence: That domain name, when queried, MUST return at least one address record (e.g., A or RR) that gives the IP address of the SMTP server to which the message should be directed. @ 1800 IN A 1.2.3.4 srv1 1800 IN A 1.2.3.4 mx 1800 IN CNAME blah.xyz.com. @ 1800 IN MX 1 mx.xyz.com. Requirements met. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal
Yes, blah was supposed to be srv1. I do receive both the CNAME and A records for the A mx.xyz.com query. See attached capture file. In the capture file three global search and replacements were performed to match the previous example. 1) domain name was replaced with xyz 2) server name was replaced with srv1 3) server ip address was replaced with 1.2.3.4 Requirements are met. - Original Message - From: Matthew Pounsett m...@conundrum.com To: Al Stu al_...@verizon.net Cc: bind-users@lists.isc.org Sent: Sunday, January 25, 2009 9:49 AM Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal
On 25-Jan-2009, at 13:15 , Al Stu wrote: Yes, blah was supposed to be srv1. I do receive both the CNAME and A records for the A mx.xyz.com query. See attached capture file. In the capture file three global search and replacements were performed to match the previous example. 1) domain name was replaced with xyz 2) server name was replaced with srv1 3) server ip address was replaced with 1.2.3.4 Requirements are met. Al, I'm sorry, but you're wrong. If you look closely at what you just typed, you'll see that's three steps.. not the two steps required by the MUST in the RFC. Your attachment didn't make it through the list manager. I suggest you paste in some dig output instead. If you do, you'll notice that the IP address you're receiving is in the ADDITIONAL section of the DNS message, which does not qualify as an ANSWER. I'm going to stop contributing to this thread now.. if you insist on ignoring the pointers people have given you to the text in the RFCs, and insist on reading your own interpretation into it, we cannot stop you. PGP.sig Description: This is a digitally signed message part ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal
No it is only two steps, see the attachment (sent in previous message). Both the CNAME and A record are returned for the mx.xyz.com DNS A request. And this does met the RFC requirements. - Original Message - From: Matthew Pounsett m...@conundrum.com To: Al Stu al_...@verizon.net Cc: bind-users@lists.isc.org Sent: Sunday, January 25, 2009 10:30 AM Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal
Al Stu wrote: ISC’s message that a CNAME/alias in an MX record is illegal is incorrect and just an attempt by ISC to get people to go along with what is only a perceived rather than actual standard/requirement, and should be removed so as not to further the fallacy of this perceived perception of a standard/requirement, as it is neither a standard nor a requirement, and certainly not illegal. If you feel this is a bug in BIND, please send an e-mail to bind-b...@isc.org for consideration. Thanks, AlanC signature.asc Description: OpenPGP digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal
Perhaps one day MX records can be deprecated entirely in favor of SRV. Jabber got it right, and it would solve the e-mail server autodiscovery problem for clients in a generic non-proprietary manner. For example:- _smtp-server._tcp for servers, _smtp-client._tcp for clients. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal
On Jan 25 2009, Chris Hills wrote: Perhaps one day MX records can be deprecated entirely in favor of SRV. Jabber got it right, and it would solve the e-mail server autodiscovery problem for clients in a generic non-proprietary manner. For example:- _smtp-server._tcp for servers, _smtp-client._tcp for clients. But would this satisfy the OP? The RDATA of an SRV record isn't meant to reference a CNAME any more than that of an MX record is. -- Chris Thompson Email: c...@cam.ac.uk ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal
MX records are supposed to be pointed to the name the mail exhanger knows itself as. This will correspond to a A record. If I could work out a way to determine which A records don't correspond to the name by which the mail exchanger knows itself as I'd also have named issue a warning for such A records. Unfortunately there isn't a way to make such a determination. When a CNAME is used you configuration errors reported from MTA's when they try to send email to themselves. This still happens today. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal
In article gli8nu$ja...@sf1.isc.org, Matthew Pounsett m...@conundrum.com wrote: In the example above, when I query for IN A mx.xyz.com? I do not get an address record back (A, )..instead I get a CNAME record. Requirements NOT met. Then there's something wrong with your resolver, since they're supposed to follow CNAME records automatically, and return the requested record type from the canonical name. There isn't even an option in the DNS spec to tell the resolver not to follow CNAMEs. The only way to avoid it is to query for the CNAME explicitly. -- Barry Margolin, bar...@alum.mit.edu Arlington, MA *** PLEASE don't copy me on replies, I'll read them in the group *** ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal
Al: If you read RFC 2181 section 10.3, RFC 1034 section 3.6, RFC 1912 (page 6), the average person would understand that it's strongly discouraged. Perhaps illegal is too strong a word, but the weight of the RFCs and best practices appears to disagree with your assessment that there is no such standard nor requirement prohibiting the use of CNAME/alias in an MX record.. Frank From: bind-users-boun...@lists.isc.org [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Al Stu Sent: Sunday, January 25, 2009 12:11 AM To: bind-users@lists.isc.org Subject: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal BIND 9.6 'named' throws the following message during startup claiming that it is illegal to use a CNAME/alias in the MX record. I beg to differ. There is no such standard nor requirement prohibiting the use of CNAME/alias in an MX record. Message thrown at startup: named[3307]: zone MyDomain.com/IN: MyDomain.com/MX 'MX1.MyDomain.com' is a CNAME (illegal) Additionally in Chapter 6 - BIND Configuration Reference, Zone File, Discussion of MX Records states the MX records must have an associated address record (A or ) - CNAME is not sufficient. Some people seem to think RFC 974 creates a standard which prohibits the use of CNAME/alias in MX records. But very much to the contrary RFC 974 demonstrates that CNAME/alias is permitted in MX records. ISC's message that a CNAME/alias in an MX record is illegal is incorrect and just an attempt by ISC to get people to go along with what is only a perceived rather than actual standard/requirement, and should be removed so as not to further the fallacy of this perceived perception of a standard/requirement, as it is neither a standard nor a requirement, and certainly not illegal. Al Stu ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal
Al Stu wrote: BIND 9.6 ‘named’ throws the following message during startup claiming that it is illegal to use a CNAME/alias in the MX record. I beg to differ. There is no such standard nor requirement prohibiting the use of CNAME/alias in an MX record. Some people seem to think RFC 974 creates a standard which prohibits the use of CNAME/alias in MX records. But very much to the contrary RFC 974 demonstrates that CNAME/alias is permitted in MX records. ISC’s message that a CNAME/alias in an MX record is illegal is incorrect and just an attempt by ISC to get people to go along with what is only a perceived rather than actual standard/requirement, and should be removed so as not to further the fallacy of this perceived perception of a standard/requirement, as it is neither a standard nor a requirement, and certainly not illegal. checking RFCs published within the last 12 years might have been useful RFC2181: Clarifications to the DNS Specification this was published as Standards Track it's true that many RFCs were not advanced but the DNS Extensions Working Group is making an effort http://www.ietf.org/html.charters/dnsext-charter.html Jun 2007 Start of process of reviewing the following RFCs and to move them to Draft Standard status that not only includes rfc2181, but ones defining EDNS0, notify, negative caching, dynamic updates, SRV records etc 10.3. MX and NS records The domain name used as the value of a NS resource record, or part of the value of a MX resource record must not be an alias. Not only is the specification clear on this point, but using an alias in either of these positions neither works as well as might be hoped, nor well fulfills the ambition that may have led to this approach. This domain name must have as its value one or more address records. Currently those will be A records, however in the future other record types giving addressing information may be acceptable. It can also have other RRs, but never a CNAME RR. Searching for either NS or MX records causes additional section processing in which address records associated with the value of the record sought are appended to the answer. This helps avoid needless extra queries that are easily anticipated when the first was made. Additional section processing does not include CNAME records, let alone the address records that may be associated with the canonical name derived from the alias. Thus, if an alias is used as the value of an NS or MX record, no address will be returned with the NS or MX value. This can cause extra queries, and extra network burden, on every query. It is trivial for the DNS administrator to avoid this by resolving the alias and placing the canonical name directly in the affected record just once when it is updated or installed. In some particular hard cases the lack of the additional section address records in the results of a NS lookup can cause the request to fail. Danny ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
