Re: Thailand Internet firewall?

[Mark Smith]

On Wed, 5 May 2010 09:45:06 +
"Dobbins, Roland"  wrote:

> 
> On May 5, 2010, at 4:39 PM, Mikael Abrahamsson wrote:
> 
> >  I was also under the impression that it wasn't by IP but that they could 
> > block specific youtube videos etc.
> 
> They use a combination of IP blocking, DNS poisoning, and transparent HTTP 
> proxy-based URL filtering.
> 

I like to call them 'translucent proxies'.

> ---
> Roland Dobbins  // 
> 
> Injustice is relatively easy to bear; what stings is justice.
> 
> -- H.L. Mencken
> 
> 
> 
> 

DNS for RFC3180 GLOP reverse zone ?

[L. Gabriel Somlo]

Does anyone know what's going on with DNS for 233.IN-ADDR.ARPA ?

I get:

233.IN-ADDR.ARPA.   86400   IN  NS  FLAG.EP.NET.
233.IN-ADDR.ARPA.   86400   IN  NS  NIC.NEAR.NET.
233.IN-ADDR.ARPA.   86400   IN  NS  STRUL.STUPI.SE.
233.IN-ADDR.ARPA.   86400   IN  NS  NS.ISI.EDU.
;; Received 138 bytes from 192.228.79.201#53(b.root-servers.net) in 91 ms

Of these, only FLAG.EP.NET actually seems to work;

NIC.NEAR.NET no longer seems to exist

STRUL.STUPI.SE returns SERVFAIL

NS.ISI.EDU returns REFUSED

I also tried to send email to hostmas...@ep.net to have a delegation
updated, but got a bounce...

I wonder if DNS for GLOP/RFC3180 is still expected to work/be supported,
or should I just give up :)

Thanks,
--Gabriel

Re: Internationalized domain names in the root

[Geoff Adams]

On 5 May 2010, at 2:16 PM, Jorge Amodio wrote:
> On Wed, May 5, 2010 at 11:34 AM, David Conrad  wrote:
>> Perhaps a bit off-topic, but some folks might get support calls...
>> 
>> http://وزارة-الأتصالات.مصر/
>> 
>> (that's Arabic for .)
> 
> Great progress and interesting addition to the root, only issue is
> that after all the work with IDNs you land on a page written in
> english (web browser lang does not matter, name resolves to the same
> IP as the original URL). Hope they soon take advantage of the new name

The page shows up in Arabic for me in all three of Safari (in which the URL bar 
also shows the Arabic name), Chrome and Firefox (in both of which the URL bar 
shows the encoded US-ASCII characters for the domain name). I tested using the 
Mac versions of these three browsers, and English is set as my preferred 
language. Arabic doesn't appear until much farther down on the list.

The Safari experience looks nicer, but I suppose it leaves its users more 
susceptible to maliciously-constructed domain names that look similar to 
well-known ones. I wonder if they've addressed that issue in some way. I 
haven't been checking recently.

- Geoff

Re: Internationalized domain names in the root

[Jorge Amodio]

Hi Geoff,

yes, as I reported through other channels today the new IDN based URL
started landing on the Arabic version of the page. Kudos for the folks
in Egypt that are now taking advantage of the new ccTLD.

I noticed testing with IE8, Chrome, FFox and Safari, that Safari is
the only one that keeps showing the original URL in Arabic in the
navigation toolbar, all the others switch to the ASCII encoded one.

I guess there is more work/configuration to be done on the client side.

Cheers
Jorge

On Thu, May 6, 2010 at 1:45 PM, Geoff Adams  wrote:
> On 5 May 2010, at 2:16 PM, Jorge Amodio wrote:
>> On Wed, May 5, 2010 at 11:34 AM, David Conrad  wrote:
>>> Perhaps a bit off-topic, but some folks might get support calls...
>>>
>>> http://وزارة-الأتصالات.مصر/
>>>
>>> (that's Arabic for .)
>>
>> Great progress and interesting addition to the root, only issue is
>> that after all the work with IDNs you land on a page written in
>> english (web browser lang does not matter, name resolves to the same
>> IP as the original URL). Hope they soon take advantage of the new name
>
> The page shows up in Arabic for me in all three of Safari (in which the URL 
> bar also shows the Arabic name), Chrome and Firefox (in both of which the URL 
> bar shows the encoded US-ASCII characters for the domain name). I tested 
> using the Mac versions of these three browsers, and English is set as my 
> preferred language. Arabic doesn't appear until much farther down on the list.
>
> The Safari experience looks nicer, but I suppose it leaves its users more 
> susceptible to maliciously-constructed domain names that look similar to 
> well-known ones. I wonder if they've addressed that issue in some way. I 
> haven't been checking recently.
>
> - Geoff
>

Re: Internationalized domain names in the root

[JC Dill]

Geoff Adams wrote:

On 5 May 2010, at 2:16 PM, Jorge Amodio wrote:
  

On Wed, May 5, 2010 at 11:34 AM, David Conrad  wrote:


Perhaps a bit off-topic, but some folks might get support calls...

http://وزارة-الأتصالات.مصر/

(that's Arabic for .)
  

Great progress and interesting addition to the root, only issue is
that after all the work with IDNs you land on a page written in
english (web browser lang does not matter, name resolves to the same
IP as the original URL). Hope they soon take advantage of the new name



The page shows up in Arabic for me in all three of Safari 


When I first checked this site yesterday, I saw a page in English[1].  
The same page is in Arabic today, in the same browsers that displayed 
English when I checked yesterday.  I assume the server admin waited 
until the domain went live before implementing language display 
selection based on the URL used to reach the site, and now it's working 
correctly. 


[1]  Such as I see when I use this URL instead:  http://www.mcit.gov.eg/

jc

Re: DNS for RFC3180 GLOP reverse zone ?

[Antonio Querubin]

On Thu, 6 May 2010, L. Gabriel Somlo wrote:


Does anyone know what's going on with DNS for 233.IN-ADDR.ARPA ?



Of these, only FLAG.EP.NET actually seems to work;

NIC.NEAR.NET no longer seems to exist

STRUL.STUPI.SE returns SERVFAIL

NS.ISI.EDU returns REFUSED

I also tried to send email to hostmas...@ep.net to have a delegation
updated, but got a bounce...

I wonder if DNS for GLOP/RFC3180 is still expected to work/be supported,
or should I just give up :)


I think this has been broken for a while now.  But if you ever figure out 
who can delegate the zones let me know :)


Antonio Querubin
808-545-5282 x3003
e-mail/xmpp:  t...@lava.net

Re: Internationalized domain names in the root

[Zaid Ali]

I agree Safari experience looks much nicer and yes whole host of potential
malice to arise. Firefox shows punycode

 http://xn--4gbrim.xnrmckbbajlc6dj7bxne2c.xn--wgbh1c/ar/default.aspx

Now if I understood arabic only and was travelling or happen to use Firefox
which showed punycode how would I trust it? If it was directly translated to
latin characters I could trust it with verification from someone I know who
understands english. I would not trust puny code because an end user does
not know what it means, I think there is potential for a lot of issues here.

Zaid  


On 5/6/10 11:45 AM, "Geoff Adams"  wrote:

> On 5 May 2010, at 2:16 PM, Jorge Amodio wrote:
>> On Wed, May 5, 2010 at 11:34 AM, David Conrad  wrote:
>>> Perhaps a bit off-topic, but some folks might get support calls...
>>> 
>>> http://وزارة-الأتصالات.مصر/
>>> 
>>> (that's Arabic for .)
>> 
>> Great progress and interesting addition to the root, only issue is
>> that after all the work with IDNs you land on a page written in
>> english (web browser lang does not matter, name resolves to the same
>> IP as the original URL). Hope they soon take advantage of the new name
> 
> The page shows up in Arabic for me in all three of Safari (in which the URL
> bar also shows the Arabic name), Chrome and Firefox (in both of which the URL
> bar shows the encoded US-ASCII characters for the domain name). I tested using
> the Mac versions of these three browsers, and English is set as my preferred
> language. Arabic doesn't appear until much farther down on the list.
> 
> The Safari experience looks nicer, but I suppose it leaves its users more
> susceptible to maliciously-constructed domain names that look similar to
> well-known ones. I wonder if they've addressed that issue in some way. I
> haven't been checking recently.
> 
> - Geoff

Re: Internationalized domain names in the root

[Bill Stewart]

I'm getting three different behaviours from Firefox
- I have the page open in a tab.  The tab header is in Arabic script.
(And the page itself renders fine in Arabic.)
- When I go to that tab, the main Firefox window title shows boxes
(i.e. "don't have the font for this.")
- When I go to that tab, the Address Bar shows ugly punycode xn-format junk.


-- 

 Thanks; Bill

Note that this isn't my regular email account - It's still experimental so far.
And Google probably logs and indexes everything you send it.

Re: Internationalized domain names in the root

[Joe Abley]

On 2010-05-06, at 22:27, Zaid Ali wrote:

> Now if I understood arabic only and was travelling or happen to use Firefox
> which showed punycode how would I trust it?

I agree, that seems like nonsense.

The answer for non-Arabic-speakers who are concerned about whether an Arabic 
URL is a phishing site is presumably just not to follow any Arabic URLs. 
They're surely intended for people that don't have that problem.


Joe

Re: DNS for RFC3180 GLOP reverse zone ?

[James Hess]

On Thu, May 6, 2010 at 1:12 PM, L. Gabriel Somlo  wrote: ..
> I wonder if DNS for GLOP/RFC3180 is still expected to work/be supported,
> or should I just give up :)   > Thanks,

I am not sure,  but I believe  as a best practice,  RFC3180   is
considered basically defunct at this point, it's obvious that at least
the RDNS is neglected.   The problem is that it relied on mapping bits
from the AS number into the IP address bitspace.

Now that AS numbers have been extended to 4 bytes in length, and RIRs
are even about to stop differentiating between them  when allocating
AS numbers, or allowing anyone to request and be sure of getting a new
 16-bit ASN.

It seems that it will be impossible for the scheme to be followed in IPv4.
A  more sensible  BCP  at this point would be to designate  the entire
223/8  to IRRs,  like was suggested by the BCP for  64512 -- 65535,
since most ASNs are not using GLOP addressing.

Mapping ASN bits onto multicast IP ranges is convenient but wasteful
too,  once you consider >2^16 ASNs.

--
-J

Re: DNS for RFC3180 GLOP reverse zone ?

[Pekka Savola]

On Thu, 6 May 2010, James Hess wrote:

Now that AS numbers have been extended to 4 bytes in length, and RIRs
are even about to stop differentiating between them  when allocating
AS numbers, or allowing anyone to request and be sure of getting a new
16-bit ASN.


Then you may be interested to see this Last Call:
http://www.ietf.org/mail-archive/web/mboned/current/msg01021.html
(draft-ietf-mboned-ipv4-uni-based-mcast)


It seems that it will be impossible for the scheme to be followed in IPv4.
A  more sensible  BCP  at this point would be to designate  the entire
223/8  to IRRs,  like was suggested by the BCP for  64512 -- 65535,
since most ASNs are not using GLOP addressing.


Uhh. Take away the numbers from those who have already started using 
them?  Are you serious?


There were multiple attempts to the private etc. ASN parts of 233/8 to 
RIRs but these have failed (lack of interest?).  The current situation 
(RFC5771) is that this has been designated as "AD-HOC Block III" and 
is assignable from IANA.


The curious minds may also want to take a look at:
http://tools.ietf.org/html/draft-ietf-mboned-addrarch-06

(Comments welcome, this has been waiting the completion of 
abovementioned draft.)


--
Pekka Savola "You each name yourselves king, yet the
Netcore Oykingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings