Hi,
Would anyone happen to know a contact at ATT wireless that would be able to
help diagnose a DNS issue? we are seeing the DNS record for boston.com
intermittantly resolve to the wrong IP address, but I am having trouble
getting through to the correct people through normal support.
Thanks
Mike
I wish you the best of luck.
While you're at it, I've been also trying to complain about them using
RFC1918 (172.16.) address space for the DNS servers they assign to their
datacard subscribers. Causes all sorts of problems with people trying to
VPN in as the same IP range is used by me.
Why they don't use public IP space belonging to them for DNS servers, I do
not know.
-Paul
they have the same addresses used in multiple VRF's? so much simpler
for them to manage...
I'm sure they use carrier grade NAT, yes.
However, nothing would prevent them from using a unique public IP assigned
to them for their DNS servers like others do.
Using RFC1918 space for a routed destination of an ISP service (DNS) is
particularly problematic for many VPN client configurations with corporate
address range overlap.
-Paul
I'm sure they use carrier grade NAT, yes.
I'm sure it's not 'carrier grade', but it does play one on tv...
However, nothing would prevent them from using a unique public IP assigned
to them for their DNS servers like others do.
sure. they could do lots of things.
Using RFC1918 space for a routed destination of an ISP service (DNS) is
particularly problematic for many VPN client configurations with corporate
address range overlap.
of course, but you aren't supposed to be doing that on their network
anyway... so says the nice man from sprint 4 nanogs ago.
-chris
(yes, I realize that people use the 'wireless' network for all manner
of things that the 'wireless carriers' are not always happy about, but
hell, they do give out 'internet protocol' connections, they ought to
expect people to 'use' them, eh?)
That, and if you are tunneling in, it's good practice to forward over
any DNS traffic as well (or all, depending on the application).
That way, if you have internal names or special resolvers setup,
you'll hit that as well.
Cheers,
jof
Which is why enterprises generally shouldn't use RFC1918 IPs for
servers when clients are located on networks not controlled by the
same entity. Servers that serve multiple administration domains (such
as VPN users on AT&T - or on some random home Linksys box) probably
shouldn't be addressed using addresses that conceivably could be used
at the other end. But I'm probably fighting a losing battle saying
that...
It's why at my last enterprise net admin jobs, I refused to establish
a site-to-site VPN session with organizations using RFC1918 space as
part of the tunnel definition (it's amazing how few organizations
wanted to use global IPs for inter-domain routing, but most came
around, although I had to loan IP addresses to several so they could
static NAT their servers behind them). It's simple: If I wouldn't
accept IPs in that range over a public BGP peering, I didn't want it
over a private static route either. I couldn't control what you did
for RFC1918, nor could you control what I did - so I exposed public
IPs, and expected you to do the same. 
RFC1918 and VPN becomes non-scalable fast when you connect to lots of
different organizations - it doesn't take long before two
organizations you connect to both want to use 172.16.0.x/24 or
10.0.0.x/24 or 192.168.0.0/24, or similar). The same logic goes for
VPN clients - if one end is potentially using RFC1918, the other end
better not use it. Since you can usually only control one end of the
VPN for road-warrior VPN, it's best to make that end not use RFC1918.
Otherwise you may find you need to route 192.168.x.y, but that just so
happens to be the user's default gateway, name server, printer, or
other key device. Of course having another set of NAT addresses for
CGN will solve everything (yes, that's sarcastic, but I can predict
how they'll be used to "solve" this type of problem).
Just because "it usually works" doesn't mean using RFC1918 addresses
for left and/or right subnets in a VPN is a good idea.
And, then there is this case where AT&T DSL is moving towards 10.x.x.x
in the access network and they are guiding customers to move off that
network in their LANs
http://www.broadbandreports.com/forum/r27139468-Uverse-wants-me-to-change-my-network-address-
NET NET, ipv4 is getting more unreliable every day. Probably should
consider IPv6 more strongly.
And, getting AT&T to change their infrastructure is an exercise in
futility. Your time is better spent changing your VPN to tunnel all
traffic, including DNS, and / or moving to use an alternate DNS
server.
CB
I've worked at places that do some combination of all public, all private and a mix..
Usually the places that work best have all public as they avoid mtu and other issues that arise. I expect the enterprise world to start coming around in the years to come to understand how they have damaged networking for the companies.
- Jared
RFC1918 and VPN becomes non-scalable fast when you connect to lots of
different organizations - it doesn't take long before two
organizations you connect to both want to use 172.16.0.x/24 or
10.0.0.x/24 or 192.168.0.0/24, or similar). The same logic goes for
VPN clients - if one end is potentially using RFC1918, the other end
better not use it. Since you can usually only control one end of the
VPN for road-warrior VPN, it's best to make that end not use RFC1918.
Otherwise you may find you need to route 192.168.x.y, but that just so
happens to be the user's default gateway, name server, printer, or
other key device. Of course having another set of NAT addresses for
CGN will solve everything (yes, that's sarcastic, but I can predict
how they'll be used to "solve" this type of problem).Just because "it usually works" doesn't mean using RFC1918 addresses
for left and/or right subnets in a VPN is a good idea.
My workplace solves this by just NATing again. It isn't the best
solution but it does work. Put aside a 10.0.0.0/16 and whenever you
have a NATed network you want to connect a VPN to on the edge just
static NAT the addresses to make them unique again. Their 172.16.x.x
becomes your 10.2.x.x.
I dunno about 'not scalable'. I guess if your connecting to thousands
of networks it won't work well, but for a a few hundred it works well
enough.
I'm sorry you don't like it, and I know IPv6 will wash all this away
soon enough, but where I'm working we have no plans to implement IPv6,
or require our vendors/partners to readdress their networks to get a
VPN up.
Just because there are no plans, this doesn't mean you shouldn't bring it up.
Even if its a "radar"/"future" issue for their networking team, it does raise
the profile in the asks with others.
- Jared
Let it be known that I hate NAT with the burning passion of a million
suns. But I'm the junior in my workplace, and this is the advice of
the head honchos. I can easily see both sides of this. I would say
with a few implementations, (maybe 25 or fewer) NATing isn't that
difficult.
Granted we both know that NAT breaks basically everything and makes
troubleshooting a TON MORE FUN. But plenty of people out there (my
workplace included) would argue this till the cows come home.
Let it be known that I hate NAT with the burning passion of a million
suns. But I'm the junior in my workplace, and this is the advice of
the head honchos. I can easily see both sides of this. I would say
with a few implementations, (maybe 25 or fewer) NATing isn't that
difficult.Granted we both know that NAT breaks basically everything and makes
troubleshooting a TON MORE FUN. But plenty of people out there (my
workplace included) would argue this till the cows come home.
Yep... While this environment would benefit greatly from deploying IPv6 on both sides of the connection, the reality is that NAT is easy enough and works well enough for the implementor that they will leave it's various pain points for the people that have to deal with it after implementation and they won't select IPv6 as a solution because it would involve slightly more pain up front.
However, the networks on both sides of these equations will have to face IPv6 in the relatively near future anyway, unless they aren't actually talking to the internet in which case, it doesn't really matter what addresses or protocols they use.
Owen