In message <0a3601c5c824$3253fcb0$0500a8c0(_at_)china(_dot_)huawei(_dot_)com>,
"Spencer Dawkins"
writes:
OK, as much fun as this is...
GPRS relies heavily on a tunneling mechanism (called GTP) for cellular
mobility. It's IP based.
The DNS that users know ANYTHING about is used INSIDE the tunnel - if a GPRS
user types www.yahoo.com, that's INSIDE the tunnel.
.gprs is used OUTSIDE the tunnel, to find GGSNs for SGSNs, etc.
.gprs is not an alt-root, it's not even the DNS for a "walled garden" that
any GPRS user will ever see directly, unless you think that SGSNs are "DNS
users". It is ONLY used for GPRS infrastructure devices to find each other
inside a GPRS infrastructure IP network.
Some number of GPRS operators ALSO operate DNS for end users in a walled
garden, but that has nothing to do with .gprs. It would be a serious concern
if GPRS end users could send untunneled packets directly to GPRS
infrastructure devices, because, sadly, it's very rare that GPRS operators
use IPsec to secure the operation of the GPRS infrastructure.
And exactly how does abusing the DNS stop people from sending them
packets? In the security world, we have a phrae for this: security
through obscurity. It's not a compliment....
I see absolutely no technical justification for .gprs in this
application. And yes, I understand what it's for. I also think that
Neustar should know better. My working assumption is that after
"creating new facts on the ground", to quote a phrase from Middle East
politics, the GSMA folk will start marketing walled garden content to
their users under that domain. (Not that any other generic TLD has
really caught on, but that doesn't stop folks from trying.) There are
also the usual issues of leakage (hint: how do resolvers learn where
the real root servers live?), confusion if one of operators needs yet
another pseudo-TLD, and what answers a DNSSEC should give for this
tree's root.
It's a bad idea, no matter what the excuse. .local can cause trouble,
but at least it has some justification. I see no valid reason for this
stunt.
--Steven M. Bellovin, http://www.cs.columbia.edu/~smb
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf