In message <0a3601c5c824$3253fcb0$0500a8c0@xxxxxxxxxxxxxxxx>, "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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf