e07@nikhefh.nikhef.nl (Eric Wassenaar) (01/16/91)
RFC1034, 3.6.2 Aliases and canonical names, page 15, states: "Domain names in RRs which point to another name should always point at the primary name and not the alias." This means that in records like $ORIGIN your.domain. foo IN NS bar.your.domain. foo IN MX 10 bar.your.domain. 'bar.your.domain' must NOT be a CNAME, but must have an A record. An exception may be the CNAME record itself. In foo IN CNAME bar.your.domain. 'bar.your.domain' MAY be a CNAME. Queries for 'foo.your.domain' must be restarted using 'bar.your.domain' (with robustness to avoid loops) as stated in the same paragraph. Conforming the abovementioned restriction, in $ORIGIN x.y.z.in-addr.arpa. n IN PTR bar.your.domain. 'bar.your.domain' must NOT be a CNAME (see the example in the same paragraph). But since PTR records are not followed, it can do no real harm to specify anything you like (which is actually done in practice already). In fact, PTR records may point at other PTR records, as suggested in RFC1101 to define network names, such as in constructions like $ORIGIN x.y.z.in-addr.arpa. 0 IN PTR netname.your.domain. $ORIGIN your.domain. netname IN PTR 0.x.y.z.in-addr.arpa. Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155 Internet: e07@nikhef.nl
davecb@yunexus.YorkU.CA (David Collier-Brown) (01/16/91)
e07@nikhefh.nikhef.nl (Eric Wassenaar) writes: | RFC1034, 3.6.2 Aliases and canonical names, page 15, states: | "Domain names in RRs which point to another name should always | point at the primary name and not the alias." | This means that in records like | $ORIGIN your.domain. | foo IN NS bar.your.domain. | foo IN MX 10 bar.your.domain. | 'bar.your.domain' must NOT be a CNAME, but must have an A record. Interesting... I've requested the exact opposite of our network manager in at least one case: mailhub.yorku.ca (a CNAME) is the target of an MX record (cox.yorku.ca) because the machine that ``is'' mailhub at any given time is the machine from which cox will get its mail. Cox is **not** MX'd to nexus, despite the fact that cox mounts nexus' disk. Cox mounts the disk of the mailhub of its department, whichever machine that might be. This is in compliance with the ``write once'' rule, which says that one has a single, authoritative source of any piece of information, and others refer to it, not to a private copy. (Note that ``single'' can be weakened in the case of a replicated, distributed database like the DNS) The write-once rule is not part of the broader internet mindset: it's origin is Multics... I can see the advantages of not allowing an arbitrary number of levels of indirection in the DNS, for at least the avoidance of loops. However, breaking this rule is neither detected nor diagnosed, which makes it statistically probably that someone else has broken it, hopefully for an equally justifiable reason. I wonder if the community can comment: 1) do MX->CNAME->A record chains break any application using MX records? 2) does any application or service-provider detect RR->RR loops? 3) does any application break trying to follow RR->RR loops? I can comment on (3): berzerkley sendmail breaks on MX->MX, without even a loop. It evaluates the first MX and stops there. I'd also like to know about other reasons than loops for this restriction. As you might guess, I'd argue for weakening the requirement to ``no RR record can point to an RR record of the same type'', claiming that the other existing constraints prevent a loop of multiple types of RR records (eg, CNAME->MX->CNAME is impossible). --dave -- David Collier-Brown, | davecb@Nexus.YorkU.CA | lethe!dave 72 Abitibi Ave., | Willowdale, Ontario, | Even cannibals don't usually eat their CANADA. 416-223-8968 | friends.
rickert@mp.cs.niu.edu (Neil Rickert) (01/18/91)
In article <20520@yunexus.YorkU.CA> davecb@yunexus.YorkU.CA (David Collier-Brown) writes: >e07@nikhefh.nikhef.nl (Eric Wassenaar) writes: >| RFC1034, 3.6.2 Aliases and canonical names, page 15, states: >| "Domain names in RRs which point to another name should always >| point at the primary name and not the alias." > > I've requested the exact opposite of our network manager in at least one >case: mailhub.yorku.ca (a CNAME) is the target of an MX record > > I wonder if the community can comment: > 1) do MX->CNAME->A record chains break any application > using MX records? Sendmail, and perhaps other mailers, break on this under certain circumstances. The problem occurs when the MX record is not the best preference. Assume that the host named in the A-record has mail for the MX address. It attempts to send to the best preference MX record, but fails because the host is down. It next tries to send to the second preference. Before doing so, it compares the name with its own host name to be sure it is not sending to itself. Because the name on the MX is the name of the CNAME record, and not of the A record, it does not recognize the name as its own. It therefore tries sending to itself, discovers the problem, aborts and bounces the mail. I believe the problem is not in sendmail, but in the MX -> CNAME. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940
kre@cs.mu.OZ.AU (Robert Elz) (01/18/91)
davecb@yunexus.YorkU.CA (David Collier-Brown) writes: >I can comment on (3): berzerkley sendmail breaks on MX->MX, without even >a loop. It evaluates the first MX and stops there. Sendmail is NOT broken here ... the RFC is very precise on this point, and its right. This permits A MX B and B MX A to allow mail to be swapped between two hosts. Don't break it. Any mailer that follows chains of MX records is VERY VERY broken. The illegality of CNAMES anywhere but in the LHS of their own CNAME record is also very clear - violating this will do less damage, and will typically be supported, but be aware that things can go wrong, and if they do, its your fault - its you who has violated the rules. Certainly if you have any secondary servers running BIND they're likely to suffer somewhat - BIND likes to bitch noisily when it detects a CNAME that is used someplace else (but for some reason, not in the primary server...) kre
sra@LCS.MIT.EDU (Rob Austein) (01/19/91)
Date: 17 Jan 91 21:03:09 GMT
From: Neil Rickert <rickert@cs.niu.edu>
... It next tries to send to the second preference. Before doing so, it
compares the name with its own host name to be sure it is not sending to
itself. Because the name on the MX is the name of the CNAME record, and not
of the A record, it does not recognize the name as its own. It therefore
tries sending to itself, discovers the problem, aborts and bounces the mail.
I believe the problem is not in sendmail, but in the MX -> CNAME.
Sorry, but this is dead wrong. There is no technical difficulty
involved in checking both the source and the target of the CNAME. If
sendmail doesn't do this, sendmail is broken. TOPS-20 MMAILR got this
right years ago.
--Rob Austein <sra@lcs.mit.edu>davecb@yunexus.YorkU.CA (David Collier-Brown) (01/19/91)
davecb@yunexus.YorkU.CA (David Collier-Brown) writes: | >I can comment on (3): berzerkley sendmail breaks on MX->MX, without even | >a loop. It evaluates the first MX and stops there. kre@cs.mu.OZ.AU (Robert Elz) writes: | Sendmail is NOT broken here ... the RFC is very precise on this | point, and its right. This permits A MX B and B MX A to allow | mail to be swapped between two hosts. Don't break it. | Any mailer that follows chains of MX records is VERY VERY broken. I'm well aware of that. I said that the expression ``breaks'' mailers, not that the mailer was broken. In other words, that isn't supported, for a defensable reason in that case... It wasn't a flame, it was a question! --dave -- David Collier-Brown, | davecb@Nexus.YorkU.CA | lethe!dave 72 Abitibi Ave., | Willowdale, Ontario, | Even cannibals don't usually eat their CANADA. 416-223-8968 | friends.