Malformed Zone?

[Jonathan Duncan]

Why would this zone entry not be pointing email to "mail.pennypix.net"?

*********************************************

# Zone = pennypix.net
.pennypix.net::ns1.bluesunhosting.com:3600
.pennypix.net::ns2.bluesunhosting.com:3600
#+pennypix.net:198.66.255.206:3600
#+www.pennypix.net:198.66.255.206:3600
Cpennypix.net:domains.smugmug.com:3600
Cwww.pennypix.net:domains.smugmug.com:3600
+mail.pennypix.net:198.66.255.206:3600
@pennypix.net:198.66.255.206:mail.pennypix.net:10:3600

*********************************************

$ dig pennypix.net mx

; <<>> DiG 9.6.0-APPLE-P2 <<>> pennypix.net mx
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22893
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;pennypix.net. IN MX

;; ANSWER SECTION:
pennypix.net. 3600 IN CNAME domains.smugmug.com.
domains.smugmug.com. 222 IN CNAME domains.smugmug.com.edgekey.net.
domains.smugmug.com.edgekey.net. 21404 IN CNAME e1021.c.akamaiedge.net.

;; Query time: 286 msec
;; SERVER: 10.45.200.1#53(10.45.200.1)
;; WHEN: Tue Apr 27 13:43:06 2010
;; MSG SIZE rcvd: 138

[Matthew Dempsky]

Post by Jonathan Duncan
Cpennypix.net:domains.smugmug.com:3600

CNAME records can't coexist at the same name with other records.

[Chris Pugh]

Post by Matthew Dempsky

Post by Jonathan Duncan
Cpennypix.net:domains.smugmug.com:3600

CNAME records can't coexist at the same name with other records.

.. and why do you need them, anyway?

Chris

[Jonathan Duncan]

Post by Chris Pugh

Post by Matthew Dempsky

Post by Jonathan Duncan
Cpennypix.net:domains.smugmug.com:3600

CNAME records can't coexist at the same name with other records.

.. and why do you need them, anyway?

I need them because my client want their domain name pointed to the SmugMug service which does not provide an IP address for their accounts but instead direct incoming traffic based on the name. Similar problem to Google Apps which requires CNAME records for all their MX servers.

Do you know of a better way?

Anyway, that seems to be beside the point. The problem I am having is that mail is not being delivered. The MX record for this Zone does not refer to a CNAME record so it should not be affected by the CNAME records. Should it?

Thanks,
Jonathan

[James Sutherland]

Post by Chris Pugh

Post by Matthew Dempsky

Post by Jonathan Duncan
Cpennypix.net:domains.smugmug.com:3600

CNAME records can't coexist at the same name with other records.

.. and why do you need them, anyway?

I need them because my client want their domain name pointed to the SmugMug service which does not provide an IP address for their accounts but instead direct incoming traffic based on the name.  Similar problem to Google Apps which requires CNAME records for all their MX servers.
Do you know of a better way?
Anyway, that seems to be beside the point.  The problem I am having is that mail is not being delivered.  The MX record for this Zone does not refer to a CNAME record so it should not be affected by the CNAME records.  Should it?

The CNAME records will be directing your email to the Smugmug servers
as well as web and all other traffic. The obvious solution would seem
to be to move the CNAME to be www.pennypix.net, then have a simple
http forwarder redirecting pennypix.net URLs to www.pennypix.net. The
CNAME record takes precedence over your MX records: whatever MX
records you set will be ignored (and indeed shouldn't be there in the
first place).

If you really, really need it to be pennypix.net rather than
www.pennypix.net, you could try adding A records pointing to the IP
addresses you get for e1021.c.edgekey.net - you'll lose all the CDN
advantages of the Akamai hosting Smugmug use, but it will probably
still work even though you're forcing the traffic to go to the wrong
edge node for most users. Obviously this should be a last resort
though! (If they didn't use Akamai, it would be fine as long as they
don't change IP addresses, but of course Akamai's whole raison d'etre
is that their hostnames resolve 'intelligently' to the nearest edge
node...)

[Jonathan Duncan]

Post by James Sutherland

Post by Jonathan Duncan

Post by Chris Pugh

Post by Matthew Dempsky

Post by Jonathan Duncan
Cpennypix.net:domains.smugmug.com:3600

CNAME records can't coexist at the same name with other records.

.. and why do you need them, anyway?

I need them because my client want their domain name pointed to the SmugMug service which does not provide an IP address for their accounts but instead direct incoming traffic based on the name. Similar problem to Google Apps which requires CNAME records for all their MX servers.
Do you know of a better way?
Anyway, that seems to be beside the point. The problem I am having is that mail is not being delivered. The MX record for this Zone does not refer to a CNAME record so it should not be affected by the CNAME records. Should it?

The CNAME records will be directing your email to the Smugmug servers
as well as web and all other traffic. The obvious solution would seem
to be to move the CNAME to be www.pennypix.net, then have a simple
http forwarder redirecting pennypix.net URLs to www.pennypix.net. The
CNAME record takes precedence over your MX records: whatever MX
records you set will be ignored (and indeed shouldn't be there in the
first place).
If you really, really need it to be pennypix.net rather than
www.pennypix.net, you could try adding A records pointing to the IP
addresses you get for e1021.c.edgekey.net - you'll lose all the CDN
advantages of the Akamai hosting Smugmug use, but it will probably
still work even though you're forcing the traffic to go to the wrong
edge node for most users. Obviously this should be a last resort
though! (If they didn't use Akamai, it would be fine as long as they
don't change IP addresses, but of course Akamai's whole raison d'etre
is that their hostnames resolve 'intelligently' to the nearest edge
node...)

Chris actually pointed me to a SmugMug article that listed an IP so that I could use A records instead, thank goodness.

Just for my education, why would the CNAME record and the MX record clash? I know that Matthew said, "CNAME records can't coexist at the same name with other records." Why is this? The A record "+pennypix.net" is the same name as "@pennypix.net" but they do not clash. What is different about CNAME records?

Cpennypix.net:domains.smugmug.com:3600
@pennypix.net:198.66.255.206:mail.pennypix.net:10:3600

Thank you,
Jonathan

[Jonathan Duncan]

Post by Jonathan Duncan
Just for my education, why would the CNAME record and the MX record
clash? I know that Matthew said, "CNAME records can't coexist at
the same name with other records." Why is this? The A record
clash. What is different about CNAME records?

The short answer is "because the RFC says so".
A CNAME isn't just a subsitute for an A record; it substitutes for all
records--when a resolver is looking for a record of type X for the
name foo, and it sees a CNAME for foo pointing to bar (possibly
already cached, from earlier when it was looking for a Y record for
foo), then it looks for a record of type X for bar instead. If foo
also had its own X record, the resolver wouldn't be able to use its
cached knowledge; it would have to check with foo's server
specifically about the X record. So this requirement saves on network
traffic and resolution time.

Good to know. Thanks for the lesson. One more reason not to use CNAME's.

Jonathan

[Paul Jarc]

Post by Jonathan Duncan
Just for my education, why would the CNAME record and the MX record
clash? I know that Matthew said, "CNAME records can't coexist at
the same name with other records." Why is this? The A record
clash. What is different about CNAME records?

The short answer is "because the RFC says so".

A CNAME isn't just a subsitute for an A record; it substitutes for all
records--when a resolver is looking for a record of type X for the
name foo, and it sees a CNAME for foo pointing to bar (possibly
already cached, from earlier when it was looking for a Y record for
foo), then it looks for a record of type X for bar instead. If foo
also had its own X record, the resolver wouldn't be able to use its
cached knowledge; it would have to check with foo's server
specifically about the X record. So this requirement saves on network
traffic and resolution time.


paul