request for help w/ ATT and terminology

P.S. if your network is all in one cage, it can't be that difficult
to just renumber it all into AT&T address space.

Oh, come on, let's not be naive. It's perfectly possible to have a common
situation where it would be exceedingly difficult to do this. Anything
that gets wired in by IP address, particularly on remote computers, would
make this a killer. That could include things such as firewall rules/ACL's,
recursion DNS server addresses, VPN adapters, VoIP equipment with stacks too
stupid to do DNS, etc.

... JG

I'll admit that fixing up /etc/resolv.conf and whatever the Windows equivalent
is can be a pain - but for the rest of it, if you bought gear that's too
stupid to do DNS, I have to agree with Leigh's comment: "Caveat emptor".

You don't always want to rely on the DNS for things like firewalls and
ACLs. DNS responses can be spoofed, the servers may not be available,
etc. (For some reason, I'm assuming that DNSsec isn't being used...)

    --Steve Bellovin, http://www.cs.columbia.edu/~smb

All of the arguments of whether AT&T should do it or would do
it aside, my guesses are that it is either (a) the people he is
talking to really don't understand him, (b) do understand
but don't know how to get it done, or (c) AT&T only does
things like that for customers buying such-and-such level
of service or better. It would be nice if he could find out
which it is.

I do know "they[0]" will do this, since they are doing it
for us (look up who is originating 206.220.216.0/21 in the
BGP and to whom it is assigned at ARIN).

[0] For a company the size of AT&T/Cingular/SBC and the
varied business units therein, it may very well be that
he is dealing with a completely different company than we
are.

B¼information contained in this e-mail message is confidential, intended
only for the use of the individual or entity named above. If the reader
of this e-mail is not the intended recipient, or the employee or agent
responsible to deliver it to the intended recipient, you are hereby
notified that any review, dissemination, distribution or copying of this
communication is strictly prohibited. If you have received this e-mail
in error, please contact postmaster@globalstar.com

Been there, done that, plus enough other "stupid DNS tricks" and "stupid
/etc/host tricks" to get me a fair supply of stories best told over a
pitcher of Guinness down at the Undergroud..

*Choosing* to hardcode rather than use DNS is one thing. *Having* to hardcode
because the gear is "too stupid" (as Joe Greco put it) is however "Caveat
emptor" no matter how you slice it...

> You don't always want to rely on the DNS for things like firewalls
> and ACLs. DNS responses can be spoofed, the servers may not be
> available, etc. (For some reason, I'm assuming that DNSsec isn't
> being used...)

Been there, done that, plus enough other "stupid DNS tricks" and
"stupid /etc/host tricks" to get me a fair supply of stories best
told over a pitcher of Guinness down at the Undergroud..

I prefer nice, hoppy ales to Guiness, but either works for stories..

*Choosing* to hardcode rather than use DNS is one thing. *Having* to
hardcode because the gear is "too stupid" (as Joe Greco put it) is
however "Caveat emptor" no matter how you slice it...

Mostly. I could make a strong case that some security gear shouldn't
let you do the wrong thing. (OTOH, my preferred interface would do the
DNS look-up at config time, and ask you to confirm the retrieved
addresses.) You can even do that look-up on a protected net in some
cases.

    --Steve Bellovin, Steven M. Bellovin