Comcast changes naming convention

Bill Mullen moonmullen at attbi.com
Fri May 2 15:56:52 EDT 2003


On Fri, 2 May 2003 pll at lanminds.com wrote:

> In a message dated: Fri, 02 May 2003 11:32:36 EDT Jack Hodgson said:
> 
> >As I said, I am only an egg... but as I understand it, I could use the
> >mac-address-based-hostname to make an entry in a DNS (CNAME???)  that
> >would automatically direct connections to the current IP, regardless
> >how often it changes. But now I need to fall back to the "script on my
> >client always checking the current IP and updating the DNS" method.
> >That works OK, but it's less elegant, it seems to me.
> 
> Oh, I didn't quite grasp what you talking about.  Well, before, no, you
> didn't really need to script it since your IP was tied to the MAC, it
> *didn't* change withouta lot of effort on their part.  Which means that
> you could probably easily run a DNS server with a domain entry for your
> IP address without much worry.  However, when it did change, you'd have
> to manually update the DNS record.
> 
> Now, since this name change has made it easier for them to change to IP
> more frequently, sure, you run the risk of needing to change your DNS
> records more frequently, but that shouldn't be a big deal.  I'd rather
> have that scripted my self anyway :)

While our hostnames haven't yet changed on my local branch of Comcast's
ever-more-dense shrubbery <g>, the old system was extremely convenient
from an end-user perspective; while the underlying IP address would change
from time to time - very rarely, IME - the hostname would remain constant,
and as long as one referenced one's system by this name in DNS, attbi
could change the IP all they wanted and one wouldn't need to update
anything (and yes, it was therefore done with CNAMEs, and possibly an MX
record). This not only allowed one to set up an MX record for one's domain
which pointed directly to the attbi hostname (as you don't want to use
CNAME aliases in MX records), but allowed that IP address to survive a
reverse lookup by always resolving to the same hostname as was used in the
MX record. Not that doing that was kosher under the AUL, but it worked. :)

As some SMTP servers will bounce mail from systems that do not resolve
properly back to their hostname in this fashion (which is why CNAMEs are
discouraged), those using dyndns can be at somewhat of a disadvantage. If
Comcast's own mail servers will in fact relay all of one's outbound mail -
specifically, when that mail contains a From: header that doesn't end in
@attbi.com/comcast.net - *after* this apparently inevitable conversion,
then I, for one, can live with that; there are ways, by combining services
such as ZoneEdit's "MailForward", the several mailboxes that Comcast
provides (and any others to which you have access), and fetchmail to make
largely unnecessary the direct reception of inbound mail for the vast bulk
of users who maintain their own personal/SOHO domains (and is what they
don't want you doing anyway). If they won't relay all of your outbound
mail when using their SMTP, however, then Houston, we have a problem. ;)

I'm guessing that the main benefit to Comcast of their new approach is
that all the hostname=>IP mappings are now static, and therefore can be
uncoupled from the DHCP process, simplifying administration. It's worth
noting that since this new hostname pattern is based on the IP (and
therefore predictable), it would seem that a script that determined the
current IP, calculated the hostname from that and then updated CNAMEs/MXes
on the dyndns host with the new hostname (rather than A records with the
raw IP address) would work around this RL problem nicely - if and only if
the dyndns host will in fact accept "named" updates of this sort.

-- 
Bill Mullen   moon at lunarhub.com   MA, USA   RLU #270075   MDK 8.1 & 9.0
"If evil be spoken of you and it be true, correct yourself; if it be a
lie, laugh at it." -- Epictetus



More information about the gnhlug-discuss mailing list