Re: DNS goofups galore...
"Henning P. Schmiedehausen" <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] (James Antill) writes: > > >"Henning P. Schmiedehausen" <[EMAIL PROTECTED]> writes: > > >> % telnet mail.bar.org smtp > >> 220 mail.foo.org ESMTP ready > >> > >> > >> This kills loop detection. Yes, it is done this way =%-) and it breaks > >> if done wrong. > > > This is humour, yeh ? > > No. This was a comment on the "loop detection" claim. [snip ... domain example] > No. This is a misconfiguration. Yes, RFC821 is a bit rusty but as far > as I know, nothing has superseded it yet. And Section 3.7 states > clearly: > > Whenever domain names are used in SMTP only the official names are > used, the use of nicknames or aliases is not allowed. _In_ SMTP, that doesn't say anything about MX records to me and even if it does it's very old and needs to change. > And the 220 Message is defined as > > 220 So... you should have the reverse for the ip address after the 220. Which most people do (but not all, mainly due to there not being enough ips). [snip CNAME lesson] The question was, why can't you use CNAMEs. You said 'because of loop detection'. I said 'But that doesn't work anyway, because you can have to names pointing at one machine without a CNAME record ... and that needs to, and currently does, work'. > Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer > INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [EMAIL PROTECTED] Let me put it this way... tanstaafl.de. IN MX 50 mail.hometree.net. tanstaafl.de. IN MX 10 mail.intermeta.de. intermeta.de. IN MX 50 mail.hometree.net. intermeta.de. IN MX 10 mail.intermeta.de. mail.hometree.net. IN A194.231.17.49 mail.intermeta.de. IN A212.34.181.3 49.17.231.194.in-addr.arpa. IN PTR limes.hometree.net. 3.181.34.212.in-addr.arpa. IN PTR babsi.intermeta.de. -- # James Antill -- [EMAIL PROTECTED] :0: * ^From: .*james@and\.org /dev/null - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: DNS goofups galore...
"Henning P. Schmiedehausen" [EMAIL PROTECTED] writes: [EMAIL PROTECTED] (James Antill) writes: "Henning P. Schmiedehausen" [EMAIL PROTECTED] writes: % telnet mail.bar.org smtp 220 mail.foo.org ESMTP ready This kills loop detection. Yes, it is done this way =%-) and it breaks if done wrong. This is humour, yeh ? No. This was a comment on the "loop detection" claim. [snip ... domain example] No. This is a misconfiguration. Yes, RFC821 is a bit rusty but as far as I know, nothing has superseded it yet. And Section 3.7 states clearly: Whenever domain names are used in SMTP only the official names are used, the use of nicknames or aliases is not allowed. _In_ SMTP, that doesn't say anything about MX records to me and even if it does it's very old and needs to change. And the 220 Message is defined as 220 domain So... you should have the reverse for the ip address after the 220. Which most people do (but not all, mainly due to there not being enough ips). [snip CNAME lesson] The question was, why can't you use CNAMEs. You said 'because of loop detection'. I said 'But that doesn't work anyway, because you can have to names pointing at one machine without a CNAME record ... and that needs to, and currently does, work'. Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [EMAIL PROTECTED] Let me put it this way... tanstaafl.de. IN MX 50 mail.hometree.net. tanstaafl.de. IN MX 10 mail.intermeta.de. intermeta.de. IN MX 50 mail.hometree.net. intermeta.de. IN MX 10 mail.intermeta.de. mail.hometree.net. IN A194.231.17.49 mail.intermeta.de. IN A212.34.181.3 49.17.231.194.in-addr.arpa. IN PTR limes.hometree.net. 3.181.34.212.in-addr.arpa. IN PTR babsi.intermeta.de. -- # James Antill -- [EMAIL PROTECTED] :0: * ^From: .*james@and\.org /dev/null - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: DNS goofups galore...
[EMAIL PROTECTED] (Kai Henningsen) writes: >[EMAIL PROTECTED] (Henning P. Schmiedehausen) wrote on 12.02.01 in ><968mjv$l9t$[EMAIL PROTECTED]>: >> [EMAIL PROTECTED] (Jan Gyselinck) writes: >> >> >There's not really something wrong with MX's pointing to CNAME's. It's >> >just that some mailservers could (can?) not handle this. So if you want to >> >be able to receive mail from all kinds of mailservers, don't use CNAME's >> >for MX's. >> >> No. It breaks a basic assumption set in stone in RFC821. It has >> nothing to do with mailer software. >May I point out that RFC 821 does not mention either CNAME or MX anywhere. RFC 974 is about the "DOMAIN NAME SYSTEM". RFC 821 mentions DOMAINS: 3.7. DOMAINS >So don't tell us about stuff set in stone in RFC XYZ, when it's plain >you've never looked at that RFC. Says who? RFC974 is a clarification of how to interpret Domain Name System contents in a mail context. RFC821 makes a clear statement about Domains in section 3.7: [...] Whenever domain names are used in SMTP only the official names are used, the use of nicknames or aliases is not allowed. [...] and in RFC974 it is stated: [...] In addition to mail information, the servers store certain other types of RR's which mailers may encounter or choose to use. These are: the canonical name (CNAME) RR, which simply states that the domain name queried for is actually an alias for another domain name, which is the proper, or canonical, name; [...] [...] In my understanding (and I assume that you're familiar with both as you've chosen to insult me by suggesting that I've not read this stuff), this means clearly: "YOU MUST NOT USE AN ALIAS WHENEVER DOMAINS ARE USED IN SMTP". (RFC821) and "THIS NAME IS AN ALIAS FOR ANOTHER DOMAIN NAME, WHICH IS THE PROPER, CANONICAL NAME". This boils down for me to "YOU MUST NOT USE A CNAME ANYWHERE IN SMTP". and "ANYWHERE" also states for me "in the 220 greeting". Any further questions? Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [EMAIL PROTECTED] Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [EMAIL PROTECTED] D-91054 Buckenhof Fax.: 09131 / 50654-20 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: DNS goofups galore...
[EMAIL PROTECTED] (James Antill) writes: >"Henning P. Schmiedehausen" <[EMAIL PROTECTED]> writes: >> % telnet mail.bar.org smtp >> 220 mail.foo.org ESMTP ready >> >> >> This kills loop detection. Yes, it is done this way =%-) and it breaks >> if done wrong. > This is humour, yeh ? No. > I would be supprised if even sendmail assumed braindamage like the >above. > For instance something that is pretty common is... >foo.example.com. IN A 4.4.4.4 >foo.example.com. IN MX 10 mail.example.com. >foo.example.com. IN MX 20 backup-mx1.example.com. >; This is really mail.example.org. >backup-mx1.example.com. IN A 1.2.3.4 No. This is a misconfiguration. Yes, RFC821 is a bit rusty but as far as I know, nothing has superseded it yet. And Section 3.7 states clearly: Whenever domain names are used in SMTP only the official names are used, the use of nicknames or aliases is not allowed. And the 220 Message is defined as 220 On sendmail, this is enforced by the "k" flag in the mailer definition. >...another is to have "farms" of mail servers (the A record for the MX >has multiple entries). > If it "broke" as you said, then a lot of mail wouldn't be being routed. You're correct. A lot of mail isn't routed or just routed because the mailers believe in the "be liberal in what you accept" policy. Or plainly non-RFC-compliant. There is a concept behind CNAMEs just like behind IP Fragmentation and the NT domains. Noone stated that it is a _SANE_ concept but it is now here and we have to live with it. CNAMES ARE NOT ALIASES. A CNAME is a reference. It states "the canonical name of "" is podunk.org". You write it as xxx IN CNAME podunk.org. SMTP requests that you use the canonical name in the 220 greeting, according to RFC 821. Everything else is misconfiguration. Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [EMAIL PROTECTED] Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [EMAIL PROTECTED] D-91054 Buckenhof Fax.: 09131 / 50654-20 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: DNS goofups galore...
[EMAIL PROTECTED] (James Antill) writes: "Henning P. Schmiedehausen" [EMAIL PROTECTED] writes: % telnet mail.bar.org smtp 220 mail.foo.org ESMTP ready This kills loop detection. Yes, it is done this way =%-) and it breaks if done wrong. This is humour, yeh ? No. I would be supprised if even sendmail assumed braindamage like the above. For instance something that is pretty common is... foo.example.com. IN A 4.4.4.4 foo.example.com. IN MX 10 mail.example.com. foo.example.com. IN MX 20 backup-mx1.example.com. ; This is really mail.example.org. backup-mx1.example.com. IN A 1.2.3.4 No. This is a misconfiguration. Yes, RFC821 is a bit rusty but as far as I know, nothing has superseded it yet. And Section 3.7 states clearly: Whenever domain names are used in SMTP only the official names are used, the use of nicknames or aliases is not allowed. And the 220 Message is defined as 220 domain On sendmail, this is enforced by the "k" flag in the mailer definition. ...another is to have "farms" of mail servers (the A record for the MX has multiple entries). If it "broke" as you said, then a lot of mail wouldn't be being routed. You're correct. A lot of mail isn't routed or just routed because the mailers believe in the "be liberal in what you accept" policy. Or plainly non-RFC-compliant. There is a concept behind CNAMEs just like behind IP Fragmentation and the NT domains. Noone stated that it is a _SANE_ concept but it is now here and we have to live with it. CNAMES ARE NOT ALIASES. A CNAME is a reference. It states "the canonical name of "" is podunk.org". You write it as xxx IN CNAME podunk.org. SMTP requests that you use the canonical name in the 220 greeting, according to RFC 821. Everything else is misconfiguration. Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [EMAIL PROTECTED] Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [EMAIL PROTECTED] D-91054 Buckenhof Fax.: 09131 / 50654-20 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: DNS goofups galore...
[EMAIL PROTECTED] (Kai Henningsen) writes: [EMAIL PROTECTED] (Henning P. Schmiedehausen) wrote on 12.02.01 in 968mjv$l9t$[EMAIL PROTECTED]: [EMAIL PROTECTED] (Jan Gyselinck) writes: There's not really something wrong with MX's pointing to CNAME's. It's just that some mailservers could (can?) not handle this. So if you want to be able to receive mail from all kinds of mailservers, don't use CNAME's for MX's. No. It breaks a basic assumption set in stone in RFC821. It has nothing to do with mailer software. May I point out that RFC 821 does not mention either CNAME or MX anywhere. RFC 974 is about the "DOMAIN NAME SYSTEM". RFC 821 mentions DOMAINS: 3.7. DOMAINS So don't tell us about stuff set in stone in RFC XYZ, when it's plain you've never looked at that RFC. Says who? RFC974 is a clarification of how to interpret Domain Name System contents in a mail context. RFC821 makes a clear statement about Domains in section 3.7: [...] Whenever domain names are used in SMTP only the official names are used, the use of nicknames or aliases is not allowed. [...] and in RFC974 it is stated: [...] In addition to mail information, the servers store certain other types of RR's which mailers may encounter or choose to use. These are: the canonical name (CNAME) RR, which simply states that the domain name queried for is actually an alias for another domain name, which is the proper, or canonical, name; [...] [...] In my understanding (and I assume that you're familiar with both as you've chosen to insult me by suggesting that I've not read this stuff), this means clearly: "YOU MUST NOT USE AN ALIAS WHENEVER DOMAINS ARE USED IN SMTP". (RFC821) and "THIS NAME IS AN ALIAS FOR ANOTHER DOMAIN NAME, WHICH IS THE PROPER, CANONICAL NAME". This boils down for me to "YOU MUST NOT USE A CNAME ANYWHERE IN SMTP". and "ANYWHERE" also states for me "in the 220 greeting". Any further questions? Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [EMAIL PROTECTED] Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [EMAIL PROTECTED] D-91054 Buckenhof Fax.: 09131 / 50654-20 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: DNS goofups galore...
[EMAIL PROTECTED] (Henning P. Schmiedehausen) wrote on 12.02.01 in <968mjv$l9t$[EMAIL PROTECTED]>: > [EMAIL PROTECTED] (Jan Gyselinck) writes: > > >There's not really something wrong with MX's pointing to CNAME's. It's > >just that some mailservers could (can?) not handle this. So if you want to > >be able to receive mail from all kinds of mailservers, don't use CNAME's > >for MX's. > > No. It breaks a basic assumption set in stone in RFC821. It has > nothing to do with mailer software. May I point out that RFC 821 does not mention either CNAME or MX anywhere. The successor (which is currently finished and waiting for publication as RFC 2821) mentions both, but does not say if MX->CNAME is allowed or forbidden. (And it says it's tightened up from RFC 974.) Incidentally, it's also silent on the name vs. address MX question. Looking at 974 and RFCs referenced from there might help to find ammunition. But note that this is significantly later than 821. So don't tell us about stuff set in stone in RFC XYZ, when it's plain you've never looked at that RFC. MfG Kai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://vger.kernel.org/lkml/
Re: DNS goofups galore...
"Henning P. Schmiedehausen" <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] (H. Peter Anvin) writes: > > >> In other words, you do a lookup, you start with a primary lookup > >> and then possibly a second lookup to resolve an MX or CNAME. It's only > >> the MX that points to a CNAME that results in yet another lookup. An > >> MX pointing to a CNAME is almost (almost, but not quite) as bad as a > >> CNAME pointing to a CNAME. > >> > > >There is no reducibility problem for MX -> CNAME, unlike the CNAME -> > >CNAME case. > > >Please explain how there is any different between an CNAME or MX pointing > >to an A record in a different SOA versus an MX pointing to a CNAME > >pointing to an A record where at least one pair is local (same SOA). > > CNAME is the "canonical name" of a host. Not an alias. There is good > decriptions for the problem with this in the bat book. Basically it > breaks if your mailer expects one host on the other side (mail.foo.org) > and suddently the host reports as mail.bar.org). The sender is > allowed to assume that the name reported after the "220" greeting > matches the name in the MX. This is impossible with a CNAME: > > mail.foo.org. IN A 1.2.3.4 > mail.bar.org. IN CNAME mail.foo.org. > bar.org.IN MX 10 mail.bar.org. > > % telnet mail.bar.org smtp > 220 mail.foo.org ESMTP ready > > > This kills loop detection. Yes, it is done this way =%-) and it breaks > if done wrong. This is humour, yeh ? I would be supprised if even sendmail assumed braindamage like the above. For instance something that is pretty common is... foo.example.com. IN A 4.4.4.4 foo.example.com. IN MX 10 mail.example.com. foo.example.com. IN MX 20 backup-mx1.example.com. ; This is really mail.example.org. backup-mx1.example.com. IN A 1.2.3.4 ...another is to have "farms" of mail servers (the A record for the MX has multiple entries). If it "broke" as you said, then a lot of mail wouldn't be being routed. -- # James Antill -- [EMAIL PROTECTED] :0: * ^From: .*james@and\.org /dev/null - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://vger.kernel.org/lkml/
Re: DNS goofups galore...
[EMAIL PROTECTED] (H. Peter Anvin) writes: >> In other words, you do a lookup, you start with a primary lookup >> and then possibly a second lookup to resolve an MX or CNAME. It's only >> the MX that points to a CNAME that results in yet another lookup. An >> MX pointing to a CNAME is almost (almost, but not quite) as bad as a >> CNAME pointing to a CNAME. >> >There is no reducibility problem for MX -> CNAME, unlike the CNAME -> >CNAME case. >Please explain how there is any different between an CNAME or MX pointing >to an A record in a different SOA versus an MX pointing to a CNAME >pointing to an A record where at least one pair is local (same SOA). CNAME is the "canonical name" of a host. Not an alias. There is good decriptions for the problem with this in the bat book. Basically it breaks if your mailer expects one host on the other side (mail.foo.org) and suddently the host reports as mail.bar.org). The sender is allowed to assume that the name reported after the "220" greeting matches the name in the MX. This is impossible with a CNAME: mail.foo.org. IN A 1.2.3.4 mail.bar.org. IN CNAME mail.foo.org. bar.org.IN MX 10 mail.bar.org. % telnet mail.bar.org smtp 220 mail.foo.org ESMTP ready This kills loop detection. Yes, it is done this way =%-) and it breaks if done wrong. Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [EMAIL PROTECTED] Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [EMAIL PROTECTED] D-91054 Buckenhof Fax.: 09131 / 50654-20 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: DNS goofups galore...
[EMAIL PROTECTED] (Jan Gyselinck) writes: >There's not really something wrong with MX's pointing to CNAME's. It's just that >some mailservers could (can?) not handle this. So if you want to be able to receive >mail from all kinds of mailservers, don't use CNAME's for MX's. No. It breaks a basic assumption set in stone in RFC821. It has nothing to do with mailer software. Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [EMAIL PROTECTED] Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [EMAIL PROTECTED] D-91054 Buckenhof Fax.: 09131 / 50654-20 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: DNS goofups galore...
[EMAIL PROTECTED] (H. Peter Anvin) writes: In other words, you do a lookup, you start with a primary lookup and then possibly a second lookup to resolve an MX or CNAME. It's only the MX that points to a CNAME that results in yet another lookup. An MX pointing to a CNAME is almost (almost, but not quite) as bad as a CNAME pointing to a CNAME. There is no reducibility problem for MX - CNAME, unlike the CNAME - CNAME case. Please explain how there is any different between an CNAME or MX pointing to an A record in a different SOA versus an MX pointing to a CNAME pointing to an A record where at least one pair is local (same SOA). CNAME is the "canonical name" of a host. Not an alias. There is good decriptions for the problem with this in the bat book. Basically it breaks if your mailer expects one host on the other side (mail.foo.org) and suddently the host reports as mail.bar.org). The sender is allowed to assume that the name reported after the "220" greeting matches the name in the MX. This is impossible with a CNAME: mail.foo.org. IN A 1.2.3.4 mail.bar.org. IN CNAME mail.foo.org. bar.org.IN MX 10 mail.bar.org. % telnet mail.bar.org smtp 220 mail.foo.org ESMTP ready This kills loop detection. Yes, it is done this way =%-) and it breaks if done wrong. Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [EMAIL PROTECTED] Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [EMAIL PROTECTED] D-91054 Buckenhof Fax.: 09131 / 50654-20 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: DNS goofups galore...
[EMAIL PROTECTED] (Jan Gyselinck) writes: There's not really something wrong with MX's pointing to CNAME's. It's just that some mailservers could (can?) not handle this. So if you want to be able to receive mail from all kinds of mailservers, don't use CNAME's for MX's. No. It breaks a basic assumption set in stone in RFC821. It has nothing to do with mailer software. Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [EMAIL PROTECTED] Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [EMAIL PROTECTED] D-91054 Buckenhof Fax.: 09131 / 50654-20 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: DNS goofups galore...
[EMAIL PROTECTED] (Henning P. Schmiedehausen) wrote on 12.02.01 in 968mjv$l9t$[EMAIL PROTECTED]: [EMAIL PROTECTED] (Jan Gyselinck) writes: There's not really something wrong with MX's pointing to CNAME's. It's just that some mailservers could (can?) not handle this. So if you want to be able to receive mail from all kinds of mailservers, don't use CNAME's for MX's. No. It breaks a basic assumption set in stone in RFC821. It has nothing to do with mailer software. May I point out that RFC 821 does not mention either CNAME or MX anywhere. The successor (which is currently finished and waiting for publication as RFC 2821) mentions both, but does not say if MX-CNAME is allowed or forbidden. (And it says it's tightened up from RFC 974.) Incidentally, it's also silent on the name vs. address MX question. Looking at 974 and RFCs referenced from there might help to find ammunition. But note that this is significantly later than 821. So don't tell us about stuff set in stone in RFC XYZ, when it's plain you've never looked at that RFC. MfG Kai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://vger.kernel.org/lkml/
Re: DNS goofups galore...
On Thu, Feb 08, 2001 at 02:58:30PM -0800, H. Peter Anvin wrote: > Followup to: <[EMAIL PROTECTED]> > By author:Gerhard Mack <[EMAIL PROTECTED]> > In newsgroup: linux.dev.kernel > > > > Thanklfully bind 9 barfs if you even try this sort of thing. > > > > Personally I find it puzzling what's wrong with MX -> CNAME at all; it > seems like a useful setup without the pitfalls that either NS -> CNAME > or CNAME -> CNAME can cause (NS -> CNAME can trivially result in > irreducible situations; CNAME -> CNAME would require a link maximum > count which could result in obscure breakage.) > > -hpa There's not really something wrong with MX's pointing to CNAME's. It's just that some mailservers could (can?) not handle this. So if you want to be able to receive mail from all kinds of mailservers, don't use CNAME's for MX's. Regards Jan Gyselinck - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: DNS goofups galore...
On Fri, Feb 09, 2001 at 01:50:04AM +, Aaron Denney wrote: > Michael H. Warfield <[EMAIL PROTECTED]> wrote: > > But, wait a minute. CNAME -> CNAME is a "must not". > Cite the RFC please. 1034 says > # Domain names in RRs which point at another name should always point at > # the primary name and not the alias. > and > # domain software should not fail when presented with CNAME > # chains or loops; CNAME chains should be followed and CNAME loops > # signalled as an error. > and > #- The answer to the query, possibly preface by one or more CNAME > # RRs that specify aliases encountered on the way to an answer. > and > # Multiple levels of > # aliases should be avoided due to their lack of efficiency, but should > # not be signalled as an error. > It's fairly clear that CNAMEs to CNAMEs are discouraged, but legal. Hmmm... Looks like I have had that just about backwards (par for the course). RFC 1912 (Common DNS Errors) makes it pretty clear that other RRs should not point at CNAMEs and that would include CNAMEs pointing at CNAMEs. It quotes your same section, 3.6.2, of rfc 1034 for justifying that. ] Don't use CNAMEs in combination with RRs which point to other names ] like MX, CNAME, PTR and NS. (PTR is an exception if you want to ] implement classless in-addr delegation.) For example, this is ] strongly discouraged: ] ] podunk.xx. IN MX mailhost ] mailhostIN CNAME mary ] maryIN A 1.2.3.4 ] ] [RFC 1034] in section 3.6.2 says this should not be done, and [RFC ] 974] explicitly states that MX records shall not point to an alias ] defined by a CNAME. This results in unnecessary indirection in ] accessing the data, and DNS resolvers and servers need to work more ] to get the answer. If you really want to do this, you can accomplish ] the same thing by using a preprocessor such as m4 on your host files. That pretty explicity states that MX records should not (and, according to RFC 974, must not) point to CNAMES. ] Also, having chained records such as CNAMEs pointing to CNAMEs may ] make administration issues easier, but is known to tickle bugs in ] some resolvers that fail to check loops correctly. As a result some ] hosts may not be able to resolve such names. That's a pretty strong recommendation to NOT point CNAMEs to CNAMEs. It's not a "must not", but it points out a seeming ambiguity in RFC 1034. The very passage you quote: > # Domain names in RRs which point at another name should always point at > # the primary name and not the alias. Doesn't that say that a domain name in a RR should always point at the primary name. Doesn't that imply (and thus semi contradict the rest of that section about loops) that CNAMEs should not point to CNAMEs? That would appear to make rfc 1034 look ambiguous. Section 3.6.2 says that RRs should always point to primary names but then goes on to discuss CNAME loops and states that multiple levels of aliases should not be signaled as an error. But then we are down to semantics and the semantics of the RFCs are defined. Should and should not are recommendations, not requirements. Must and must not are requirements. On that point, I must cede the field and admit that both CNAME -> MX and CNAME -> CNAME would appear to fall under the former and not the later. But MX -> CNAME would appear to be explicitly prohibited under RFC 974. > -- > Aaron Denney > -><- > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: DNS goofups galore...
Michael H. Warfield <[EMAIL PROTECTED]> wrote: > But, wait a minute. CNAME -> CNAME is a "must not". Cite the RFC please. 1034 says # Domain names in RRs which point at another name should always point at # the primary name and not the alias. and # domain software should not fail when presented with CNAME # chains or loops; CNAME chains should be followed and CNAME loops # signalled as an error. and #- The answer to the query, possibly preface by one or more CNAME # RRs that specify aliases encountered on the way to an answer. and # Multiple levels of # aliases should be avoided due to their lack of efficiency, but should # not be signalled as an error. It's fairly clear that CNAMEs to CNAMEs are discouraged, but legal. -- Aaron Denney -><- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: DNS goofups galore...
On Thu, Feb 08, 2001, Michael H. Warfield <[EMAIL PROTECTED]> wrote: > But, wait a minute. CNAME -> CNAME is a "must not". MX -> CNAME > is a "should not". The "should not" leaves it to be implimentation > dependent and not an outright ban. Sooo... Actually, I had this conversation recently. I checked a variety of places and I couldn't find an RFC that said CNAME -> CNAME is a "must not". In fact I found this snippet in rfc1912 which seems to imply that it is legal: Also, having chained records such as CNAMEs pointing to CNAMEs may make administration issues easier, but is known to tickle bugs in some resolvers that fail to check loops correctly. As a result some hosts may not be able to resolve such names. *shrug* JE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: DNS goofups galore...
On Thu, Feb 08, 2001 at 04:11:39PM -0800, H. Peter Anvin wrote: > "Michael H. Warfield" wrote: > > > > > Please explain how there is any different between an CNAME or MX pointing > > > to an A record in a different SOA versus an MX pointing to a CNAME > > > pointing to an A record where at least one pair is local (same SOA). > > > > Ah! But now you are placing conditions on it (that at least one > > pair is local). That is the very fine distinction that makes up the > > "not quite" in the "almost" above and the difference between the "should > > not" vs the "must not" in the specifications. You basically can't qualify > > it by saying "you can do this, but only if one pair is in the same SOA". > No. My point is that potential for inefficiency is not a valid reason > for banning something outright. This should be an administrative > decision, nothing more. But, wait a minute. CNAME -> CNAME is a "must not". MX -> CNAME is a "should not". The "should not" leaves it to be implimentation dependent and not an outright ban. Sooo... I personally have no problem with Bind 9.x prohibiting an MX -> CNAME, but that's an implimentation issue. In case people have tuned in late, there have been some rather radical swings in Bind policy since Bind 4.x. Bind 8.x decided to ENFORCE (with a vengence) the character set policies dictated by RFC. This was (so they claimed) to protect poorly coded programs that were prone to blowing chunks and doing Chernobyl imitations on getting illegal characters in host names. Of course that also caused zones with underscores in names (more common than what you would think) to crap all over themselves when unsuspecting (i.e. failure to read warnings) admins upgraded. Bind 9.0 went back to the old 4.9 policy on characters (allow what can be entered and poorly coded programs are on their own) but started enforcing a requirement for a TTL directive and making the SOA TTL field the true minimum TTL that it was defined as (instead of a default like Bind 8 and 4 and previous used it as). I figured I was all set, since I, of course, had upgraded all MY zone files already. Imagine my surprise when 9.0 would not even load because OVER HALF of the 200+ zones I'm responsible for or host did NOT have the $TTL directive! It was assholes and elbows for a not so brief but really intense time while I updated those $@$%#@ zone files! You don't like the Bind enforcement of the DNS policy, bitch to the ISC bunch. They can be swayed (all too often, it appears). If enough DNS administrators really want to go against the "should not", maybe they will make it configurable (Actually, I didn't think it really outright prohibited it in the first place, but... Oh well...) There are lots of other things in the DNS that need to be killed DEAD with a stake through the heart like CNAME with other data (what is THAT suppose to mean). I run into lookups on sites with CNAMES and A records for a host! I suppose one can come up with a hierachial reason for doing such byzantine things, but do you REALLY want to? In applying the KISS principle (admitedly an oxymoron when it comes to DNS) I can see some people wanting to ban MX -> CNAME in general if, for no other reason, than to insure that you will do it only if you have really STRONG reasons for doing it. > -hpa > -- > <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! > "Unix gives you enough rope to shoot yourself in the foot." > http://www.zytor.com/~hpa/puzzle.txt Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: DNS goofups galore...
"Michael H. Warfield" wrote: > > > Please explain how there is any different between an CNAME or MX pointing > > to an A record in a different SOA versus an MX pointing to a CNAME > > pointing to an A record where at least one pair is local (same SOA). > > Ah! But now you are placing conditions on it (that at least one > pair is local). That is the very fine distinction that makes up the > "not quite" in the "almost" above and the difference between the "should > not" vs the "must not" in the specifications. You basically can't qualify > it by saying "you can do this, but only if one pair is in the same SOA". > No. My point is that potential for inefficiency is not a valid reason for banning something outright. This should be an administrative decision, nothing more. -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: DNS goofups galore...
On Thu, Feb 08, 2001 at 04:01:30PM -0800, H. Peter Anvin wrote: > > > Wouldn't that be true for any CNAME anyway? > > That's the point... > > In other words, you do a lookup, you start with a primary lookup > > and then possibly a second lookup to resolve an MX or CNAME. It's only > > the MX that points to a CNAME that results in yet another lookup. An > > MX pointing to a CNAME is almost (almost, but not quite) as bad as a > > CNAME pointing to a CNAME. > There is no reducibility problem for MX -> CNAME, unlike the CNAME -> > CNAME case. > Please explain how there is any different between an CNAME or MX pointing > to an A record in a different SOA versus an MX pointing to a CNAME > pointing to an A record where at least one pair is local (same SOA). Ah! But now you are placing conditions on it (that at least one pair is local). That is the very fine distinction that makes up the "not quite" in the "almost" above and the difference between the "should not" vs the "must not" in the specifications. You basically can't qualify it by saying "you can do this, but only if one pair is in the same SOA". > -hpa Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: DNS goofups galore...
> > > Wouldn't that be true for any CNAME anyway? > > That's the point... > > In other words, you do a lookup, you start with a primary lookup > and then possibly a second lookup to resolve an MX or CNAME. It's only > the MX that points to a CNAME that results in yet another lookup. An > MX pointing to a CNAME is almost (almost, but not quite) as bad as a > CNAME pointing to a CNAME. > There is no reducibility problem for MX -> CNAME, unlike the CNAME -> CNAME case. Please explain how there is any different between an CNAME or MX pointing to an A record in a different SOA versus an MX pointing to a CNAME pointing to an A record where at least one pair is local (same SOA). -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: DNS goofups galore...
On Thu, Feb 08, 2001 at 03:47:17PM -0800, H. Peter Anvin wrote: > "Michael H. Warfield" wrote: > > > > On Thu, Feb 08, 2001 at 02:58:30PM -0800, H. Peter Anvin wrote: > > > Followup to: <[EMAIL PROTECTED]> > > > By author:Gerhard Mack <[EMAIL PROTECTED]> > > > In newsgroup: linux.dev.kernel > > > > > > > > Thanklfully bind 9 barfs if you even try this sort of thing. > > > > > > > > > Personally I find it puzzling what's wrong with MX -> CNAME at all; it > > > seems like a useful setup without the pitfalls that either NS -> CNAME > > > or CNAME -> CNAME can cause (NS -> CNAME can trivially result in > > > irreducible situations; CNAME -> CNAME would require a link maximum > > > count which could result in obscure breakage.) > > > > It generally forces another DNS lookup. If you do a resolve on > > a name of type=ANY it returns any MX records and A records. If you then > > do a resolve on the MX records, you then get a CNAME and then have to > > add an additional lookup for the CNAME. If you have a lot of MX records > > and not all the servers are "up" that can add up to a significant > > increase in DNS traffic. > > > Wouldn't that be true for any CNAME anyway? That's the point... In other words, you do a lookup, you start with a primary lookup and then possibly a second lookup to resolve an MX or CNAME. It's only the MX that points to a CNAME that results in yet another lookup. An MX pointing to a CNAME is almost (almost, but not quite) as bad as a CNAME pointing to a CNAME. > -hpa > -- > <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! > "Unix gives you enough rope to shoot yourself in the foot." > http://www.zytor.com/~hpa/puzzle.txt Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: DNS goofups galore...
"Michael H. Warfield" wrote: > > On Thu, Feb 08, 2001 at 02:58:30PM -0800, H. Peter Anvin wrote: > > Followup to: <[EMAIL PROTECTED]> > > By author:Gerhard Mack <[EMAIL PROTECTED]> > > In newsgroup: linux.dev.kernel > > > > > > Thanklfully bind 9 barfs if you even try this sort of thing. > > > > > > Personally I find it puzzling what's wrong with MX -> CNAME at all; it > > seems like a useful setup without the pitfalls that either NS -> CNAME > > or CNAME -> CNAME can cause (NS -> CNAME can trivially result in > > irreducible situations; CNAME -> CNAME would require a link maximum > > count which could result in obscure breakage.) > > It generally forces another DNS lookup. If you do a resolve on > a name of type=ANY it returns any MX records and A records. If you then > do a resolve on the MX records, you then get a CNAME and then have to > add an additional lookup for the CNAME. If you have a lot of MX records > and not all the servers are "up" that can add up to a significant > increase in DNS traffic. > Wouldn't that be true for any CNAME anyway? -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: DNS goofups galore...
On Thu, Feb 08, 2001 at 02:58:30PM -0800, H. Peter Anvin wrote: > Followup to: <[EMAIL PROTECTED]> > By author:Gerhard Mack <[EMAIL PROTECTED]> > In newsgroup: linux.dev.kernel > > > > Thanklfully bind 9 barfs if you even try this sort of thing. > > > Personally I find it puzzling what's wrong with MX -> CNAME at all; it > seems like a useful setup without the pitfalls that either NS -> CNAME > or CNAME -> CNAME can cause (NS -> CNAME can trivially result in > irreducible situations; CNAME -> CNAME would require a link maximum > count which could result in obscure breakage.) It generally forces another DNS lookup. If you do a resolve on a name of type=ANY it returns any MX records and A records. If you then do a resolve on the MX records, you then get a CNAME and then have to add an additional lookup for the CNAME. If you have a lot of MX records and not all the servers are "up" that can add up to a significant increase in DNS traffic. > -hpa > -- > <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! > "Unix gives you enough rope to shoot yourself in the foot." > http://www.zytor.com/~hpa/puzzle.txt Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: DNS goofups galore...
Followup to: <[EMAIL PROTECTED]> By author:Gerhard Mack <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > Thanklfully bind 9 barfs if you even try this sort of thing. > Personally I find it puzzling what's wrong with MX -> CNAME at all; it seems like a useful setup without the pitfalls that either NS -> CNAME or CNAME -> CNAME can cause (NS -> CNAME can trivially result in irreducible situations; CNAME -> CNAME would require a link maximum count which could result in obscure breakage.) -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: DNS goofups galore...
Thanklfully bind 9 barfs if you even try this sort of thing. Gerhard On Thu, 8 Feb 2001, Henning P. Schmiedehausen wrote: > [EMAIL PROTECTED] (Matti Aarnio) writes: > > >NSes and MXes must ALWAYS point to NAMEs with A//A6 records for > >them, specifically those names MUST NOT be CNAMEs. With NSes the > > NS: must not > MX: should not > > ...stickler for details. ;-) > Henning > > -- > Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer > INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [EMAIL PROTECTED] > > Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [EMAIL PROTECTED] > D-91054 Buckenhof Fax.: 09131 / 50654-20 > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ > -- Gerhard Mack [EMAIL PROTECTED] <>< As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: DNS goofups galore...
[EMAIL PROTECTED] (Matti Aarnio) writes: >NSes and MXes must ALWAYS point to NAMEs with A//A6 records for >them, specifically those names MUST NOT be CNAMEs. With NSes the NS: must not MX: should not ...stickler for details. ;-) Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [EMAIL PROTECTED] Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [EMAIL PROTECTED] D-91054 Buckenhof Fax.: 09131 / 50654-20 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: DNS goofups galore...
Hello Matti , On Thu, 8 Feb 2001, Matti Aarnio wrote: ...snip... > Answer to the self-education question above: > > The NAME fields in usual BIND systems get appended the current $ORIGIN > string value when the data in the field does not end with a dot: > > Wrong: IN MX 10 11.22.33.44 > "Right": IN MX 10 11.22.33.44. s/"Right"/Wrong/ (in the forward file) Right: IN MX 10 mymail.mydomain.com. Right:mymail.mydomain.com. IN A11.22.33.44 (in a in-addr.arpa file) Right:44IN PTR mymail.mydomain.com. > The second appears at DNS lookup as "IN MX 10 11.22.33.44", which > is the intention aiming to use quite common misfeatures of system > libraries. THERE IS NO GUARANTEE OF IT WORKING AT NON-UNIX SYSTEMS! > Indeed there is no guarantee of it working at UNIX systems either! True ! .Hth , JimL ++ | James W. Laferriere | System Techniques | Give me VMS | | NetworkEngineer | 25416 22nd So | Give me Linux | | [EMAIL PROTECTED] | DesMoines WA 98198 | only on AXP | ++ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: DNS goofups galore...
Hello Matti , On Thu, 8 Feb 2001, Matti Aarnio wrote: ...snip... Answer to the self-education question above: The NAME fields in usual BIND systems get appended the current $ORIGIN string value when the data in the field does not end with a dot: Wrong: IN MX 10 11.22.33.44 "Right": IN MX 10 11.22.33.44. s/"Right"/Wrong/ (in the forward file) Right: IN MX 10 mymail.mydomain.com. Right:mymail.mydomain.com. IN A11.22.33.44 (in a in-addr.arpa file) Right:44IN PTR mymail.mydomain.com. The second appears at DNS lookup as "IN MX 10 11.22.33.44", which is the intention aiming to use quite common misfeatures of system libraries. THERE IS NO GUARANTEE OF IT WORKING AT NON-UNIX SYSTEMS! Indeed there is no guarantee of it working at UNIX systems either! True ! .Hth , JimL ++ | James W. Laferriere | System Techniques | Give me VMS | | NetworkEngineer | 25416 22nd So | Give me Linux | | [EMAIL PROTECTED] | DesMoines WA 98198 | only on AXP | ++ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: DNS goofups galore...
[EMAIL PROTECTED] (Matti Aarnio) writes: NSes and MXes must ALWAYS point to NAMEs with A//A6 records for them, specifically those names MUST NOT be CNAMEs. With NSes the NS: must not MX: should not ...stickler for details. ;-) Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [EMAIL PROTECTED] Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [EMAIL PROTECTED] D-91054 Buckenhof Fax.: 09131 / 50654-20 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: DNS goofups galore...
Thanklfully bind 9 barfs if you even try this sort of thing. Gerhard On Thu, 8 Feb 2001, Henning P. Schmiedehausen wrote: [EMAIL PROTECTED] (Matti Aarnio) writes: NSes and MXes must ALWAYS point to NAMEs with A//A6 records for them, specifically those names MUST NOT be CNAMEs. With NSes the NS: must not MX: should not ...stickler for details. ;-) Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [EMAIL PROTECTED] Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [EMAIL PROTECTED] D-91054 Buckenhof Fax.: 09131 / 50654-20 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ -- Gerhard Mack [EMAIL PROTECTED] As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: DNS goofups galore...
Followup to: [EMAIL PROTECTED] By author:Gerhard Mack [EMAIL PROTECTED] In newsgroup: linux.dev.kernel Thanklfully bind 9 barfs if you even try this sort of thing. Personally I find it puzzling what's wrong with MX - CNAME at all; it seems like a useful setup without the pitfalls that either NS - CNAME or CNAME - CNAME can cause (NS - CNAME can trivially result in irreducible situations; CNAME - CNAME would require a link maximum count which could result in obscure breakage.) -hpa -- [EMAIL PROTECTED] at work, [EMAIL PROTECTED] in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: DNS goofups galore...
On Thu, Feb 08, 2001 at 02:58:30PM -0800, H. Peter Anvin wrote: Followup to: [EMAIL PROTECTED] By author:Gerhard Mack [EMAIL PROTECTED] In newsgroup: linux.dev.kernel Thanklfully bind 9 barfs if you even try this sort of thing. Personally I find it puzzling what's wrong with MX - CNAME at all; it seems like a useful setup without the pitfalls that either NS - CNAME or CNAME - CNAME can cause (NS - CNAME can trivially result in irreducible situations; CNAME - CNAME would require a link maximum count which could result in obscure breakage.) It generally forces another DNS lookup. If you do a resolve on a name of type=ANY it returns any MX records and A records. If you then do a resolve on the MX records, you then get a CNAME and then have to add an additional lookup for the CNAME. If you have a lot of MX records and not all the servers are "up" that can add up to a significant increase in DNS traffic. -hpa -- [EMAIL PROTECTED] at work, [EMAIL PROTECTED] in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: DNS goofups galore...
"Michael H. Warfield" wrote: On Thu, Feb 08, 2001 at 02:58:30PM -0800, H. Peter Anvin wrote: Followup to: [EMAIL PROTECTED] By author:Gerhard Mack [EMAIL PROTECTED] In newsgroup: linux.dev.kernel Thanklfully bind 9 barfs if you even try this sort of thing. Personally I find it puzzling what's wrong with MX - CNAME at all; it seems like a useful setup without the pitfalls that either NS - CNAME or CNAME - CNAME can cause (NS - CNAME can trivially result in irreducible situations; CNAME - CNAME would require a link maximum count which could result in obscure breakage.) It generally forces another DNS lookup. If you do a resolve on a name of type=ANY it returns any MX records and A records. If you then do a resolve on the MX records, you then get a CNAME and then have to add an additional lookup for the CNAME. If you have a lot of MX records and not all the servers are "up" that can add up to a significant increase in DNS traffic. Wouldn't that be true for any CNAME anyway? -hpa -- [EMAIL PROTECTED] at work, [EMAIL PROTECTED] in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: DNS goofups galore...
On Thu, Feb 08, 2001 at 03:47:17PM -0800, H. Peter Anvin wrote: "Michael H. Warfield" wrote: On Thu, Feb 08, 2001 at 02:58:30PM -0800, H. Peter Anvin wrote: Followup to: [EMAIL PROTECTED] By author:Gerhard Mack [EMAIL PROTECTED] In newsgroup: linux.dev.kernel Thanklfully bind 9 barfs if you even try this sort of thing. Personally I find it puzzling what's wrong with MX - CNAME at all; it seems like a useful setup without the pitfalls that either NS - CNAME or CNAME - CNAME can cause (NS - CNAME can trivially result in irreducible situations; CNAME - CNAME would require a link maximum count which could result in obscure breakage.) It generally forces another DNS lookup. If you do a resolve on a name of type=ANY it returns any MX records and A records. If you then do a resolve on the MX records, you then get a CNAME and then have to add an additional lookup for the CNAME. If you have a lot of MX records and not all the servers are "up" that can add up to a significant increase in DNS traffic. Wouldn't that be true for any CNAME anyway? That's the point... In other words, you do a lookup, you start with a primary lookup and then possibly a second lookup to resolve an MX or CNAME. It's only the MX that points to a CNAME that results in yet another lookup. An MX pointing to a CNAME is almost (almost, but not quite) as bad as a CNAME pointing to a CNAME. -hpa -- [EMAIL PROTECTED] at work, [EMAIL PROTECTED] in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: DNS goofups galore...
Wouldn't that be true for any CNAME anyway? That's the point... In other words, you do a lookup, you start with a primary lookup and then possibly a second lookup to resolve an MX or CNAME. It's only the MX that points to a CNAME that results in yet another lookup. An MX pointing to a CNAME is almost (almost, but not quite) as bad as a CNAME pointing to a CNAME. There is no reducibility problem for MX - CNAME, unlike the CNAME - CNAME case. Please explain how there is any different between an CNAME or MX pointing to an A record in a different SOA versus an MX pointing to a CNAME pointing to an A record where at least one pair is local (same SOA). -hpa -- [EMAIL PROTECTED] at work, [EMAIL PROTECTED] in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: DNS goofups galore...
On Thu, Feb 08, 2001 at 04:01:30PM -0800, H. Peter Anvin wrote: Wouldn't that be true for any CNAME anyway? That's the point... In other words, you do a lookup, you start with a primary lookup and then possibly a second lookup to resolve an MX or CNAME. It's only the MX that points to a CNAME that results in yet another lookup. An MX pointing to a CNAME is almost (almost, but not quite) as bad as a CNAME pointing to a CNAME. There is no reducibility problem for MX - CNAME, unlike the CNAME - CNAME case. Please explain how there is any different between an CNAME or MX pointing to an A record in a different SOA versus an MX pointing to a CNAME pointing to an A record where at least one pair is local (same SOA). Ah! But now you are placing conditions on it (that at least one pair is local). That is the very fine distinction that makes up the "not quite" in the "almost" above and the difference between the "should not" vs the "must not" in the specifications. You basically can't qualify it by saying "you can do this, but only if one pair is in the same SOA". -hpa Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: DNS goofups galore...
"Michael H. Warfield" wrote: Please explain how there is any different between an CNAME or MX pointing to an A record in a different SOA versus an MX pointing to a CNAME pointing to an A record where at least one pair is local (same SOA). Ah! But now you are placing conditions on it (that at least one pair is local). That is the very fine distinction that makes up the "not quite" in the "almost" above and the difference between the "should not" vs the "must not" in the specifications. You basically can't qualify it by saying "you can do this, but only if one pair is in the same SOA". No. My point is that potential for inefficiency is not a valid reason for banning something outright. This should be an administrative decision, nothing more. -hpa -- [EMAIL PROTECTED] at work, [EMAIL PROTECTED] in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: DNS goofups galore...
On Thu, Feb 08, 2001 at 04:11:39PM -0800, H. Peter Anvin wrote: "Michael H. Warfield" wrote: Please explain how there is any different between an CNAME or MX pointing to an A record in a different SOA versus an MX pointing to a CNAME pointing to an A record where at least one pair is local (same SOA). Ah! But now you are placing conditions on it (that at least one pair is local). That is the very fine distinction that makes up the "not quite" in the "almost" above and the difference between the "should not" vs the "must not" in the specifications. You basically can't qualify it by saying "you can do this, but only if one pair is in the same SOA". No. My point is that potential for inefficiency is not a valid reason for banning something outright. This should be an administrative decision, nothing more. But, wait a minute. CNAME - CNAME is a "must not". MX - CNAME is a "should not". The "should not" leaves it to be implimentation dependent and not an outright ban. Sooo... I personally have no problem with Bind 9.x prohibiting an MX - CNAME, but that's an implimentation issue. In case people have tuned in late, there have been some rather radical swings in Bind policy since Bind 4.x. Bind 8.x decided to ENFORCE (with a vengence) the character set policies dictated by RFC. This was (so they claimed) to protect poorly coded programs that were prone to blowing chunks and doing Chernobyl imitations on getting illegal characters in host names. Of course that also caused zones with underscores in names (more common than what you would think) to crap all over themselves when unsuspecting (i.e. failure to read warnings) admins upgraded. Bind 9.0 went back to the old 4.9 policy on characters (allow what can be entered and poorly coded programs are on their own) but started enforcing a requirement for a TTL directive and making the SOA TTL field the true minimum TTL that it was defined as (instead of a default like Bind 8 and 4 and previous used it as). I figured I was all set, since I, of course, had upgraded all MY zone files already. Imagine my surprise when 9.0 would not even load because OVER HALF of the 200+ zones I'm responsible for or host did NOT have the $TTL directive! It was assholes and elbows for a not so brief but really intense time while I updated those $@$%#@ zone files! You don't like the Bind enforcement of the DNS policy, bitch to the ISC bunch. They can be swayed (all too often, it appears). If enough DNS administrators really want to go against the "should not", maybe they will make it configurable (Actually, I didn't think it really outright prohibited it in the first place, but... Oh well...) There are lots of other things in the DNS that need to be killed DEAD with a stake through the heart like CNAME with other data (what is THAT suppose to mean). I run into lookups on sites with CNAMES and A records for a host! I suppose one can come up with a hierachial reason for doing such byzantine things, but do you REALLY want to? In applying the KISS principle (admitedly an oxymoron when it comes to DNS) I can see some people wanting to ban MX - CNAME in general if, for no other reason, than to insure that you will do it only if you have really STRONG reasons for doing it. -hpa -- [EMAIL PROTECTED] at work, [EMAIL PROTECTED] in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: DNS goofups galore...
Michael H. Warfield [EMAIL PROTECTED] wrote: But, wait a minute. CNAME - CNAME is a "must not". Cite the RFC please. 1034 says # Domain names in RRs which point at another name should always point at # the primary name and not the alias. and # domain software should not fail when presented with CNAME # chains or loops; CNAME chains should be followed and CNAME loops # signalled as an error. and #- The answer to the query, possibly preface by one or more CNAME # RRs that specify aliases encountered on the way to an answer. and # Multiple levels of # aliases should be avoided due to their lack of efficiency, but should # not be signalled as an error. It's fairly clear that CNAMEs to CNAMEs are discouraged, but legal. -- Aaron Denney -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: DNS goofups galore...
On Fri, Feb 09, 2001 at 01:50:04AM +, Aaron Denney wrote: Michael H. Warfield [EMAIL PROTECTED] wrote: But, wait a minute. CNAME - CNAME is a "must not". Cite the RFC please. 1034 says # Domain names in RRs which point at another name should always point at # the primary name and not the alias. and # domain software should not fail when presented with CNAME # chains or loops; CNAME chains should be followed and CNAME loops # signalled as an error. and #- The answer to the query, possibly preface by one or more CNAME # RRs that specify aliases encountered on the way to an answer. and # Multiple levels of # aliases should be avoided due to their lack of efficiency, but should # not be signalled as an error. It's fairly clear that CNAMEs to CNAMEs are discouraged, but legal. Hmmm... Looks like I have had that just about backwards (par for the course). RFC 1912 (Common DNS Errors) makes it pretty clear that other RRs should not point at CNAMEs and that would include CNAMEs pointing at CNAMEs. It quotes your same section, 3.6.2, of rfc 1034 for justifying that. ] Don't use CNAMEs in combination with RRs which point to other names ] like MX, CNAME, PTR and NS. (PTR is an exception if you want to ] implement classless in-addr delegation.) For example, this is ] strongly discouraged: ] ] podunk.xx. IN MX mailhost ] mailhostIN CNAME mary ] maryIN A 1.2.3.4 ] ] [RFC 1034] in section 3.6.2 says this should not be done, and [RFC ] 974] explicitly states that MX records shall not point to an alias ] defined by a CNAME. This results in unnecessary indirection in ] accessing the data, and DNS resolvers and servers need to work more ] to get the answer. If you really want to do this, you can accomplish ] the same thing by using a preprocessor such as m4 on your host files. That pretty explicity states that MX records should not (and, according to RFC 974, must not) point to CNAMES. ] Also, having chained records such as CNAMEs pointing to CNAMEs may ] make administration issues easier, but is known to tickle bugs in ] some resolvers that fail to check loops correctly. As a result some ] hosts may not be able to resolve such names. That's a pretty strong recommendation to NOT point CNAMEs to CNAMEs. It's not a "must not", but it points out a seeming ambiguity in RFC 1034. The very passage you quote: # Domain names in RRs which point at another name should always point at # the primary name and not the alias. Doesn't that say that a domain name in a RR should always point at the primary name. Doesn't that imply (and thus semi contradict the rest of that section about loops) that CNAMEs should not point to CNAMEs? That would appear to make rfc 1034 look ambiguous. Section 3.6.2 says that RRs should always point to primary names but then goes on to discuss CNAME loops and states that multiple levels of aliases should not be signaled as an error. But then we are down to semantics and the semantics of the RFCs are defined. Should and should not are recommendations, not requirements. Must and must not are requirements. On that point, I must cede the field and admit that both CNAME - MX and CNAME - CNAME would appear to fall under the former and not the later. But MX - CNAME would appear to be explicitly prohibited under RFC 974. -- Aaron Denney -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: DNS goofups galore...
On Thu, Feb 08, 2001 at 02:58:30PM -0800, H. Peter Anvin wrote: Followup to: [EMAIL PROTECTED] By author:Gerhard Mack [EMAIL PROTECTED] In newsgroup: linux.dev.kernel Thanklfully bind 9 barfs if you even try this sort of thing. Personally I find it puzzling what's wrong with MX - CNAME at all; it seems like a useful setup without the pitfalls that either NS - CNAME or CNAME - CNAME can cause (NS - CNAME can trivially result in irreducible situations; CNAME - CNAME would require a link maximum count which could result in obscure breakage.) -hpa There's not really something wrong with MX's pointing to CNAME's. It's just that some mailservers could (can?) not handle this. So if you want to be able to receive mail from all kinds of mailservers, don't use CNAME's for MX's. Regards Jan Gyselinck - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/