Como diabos é http://to./ um nome de domínio válido?

67

Aparentemente, é um encurtador de URL. Ele resolve muito bem no Chrome e no Firefox. Como isso é um domínio de nível superior válido?

Atualização: para as pessoas que dizem que são travessuras de navegador, por que é que: http://com./ não me leva para: http://www.com/ ?

E os navegadores já lhe enviam uma resposta de algum outro lugar além do que está na barra de endereços? Além de conjuntos de quadros e coisas do tipo, achei que os navegadores tentaram enviar conteúdo apenas a partir do site na barra de endereço para ajudar a se proteger contra phishing.

    
por Chris 03.12.2009 / 19:09

22 respostas

47

Basicamente, alguém conseguiu convencer os proprietários do ccTLD 'a'. (Tonga?) Para atribuir o registro A ao seu próprio endereço IP. Bastante golpe no estranho velho mundo dos encurtadores de URLs.

Normalmente, esses top-levels não teriam endereços IP atribuídos através de um registro padrão A, mas não há nada a dizer que o mesmo não poderia ser feito para .uk, .com, .eu, etc.

Estritamente falando, não há razão para ter o '.' especificado, embora ele deva impedir que seu navegador tente outras combinações como 'to.seudominio.com' primeiro e acelere a resolução do endereço. Ele também pode confundir os navegadores, já que não há ponto, mas o Safari parece funcionar bem com ele.

    
por 03.12.2009 / 19:25
21

"para" (o TLD do país para Tonga) é todo o domínio do site - não há truques do navegador:

$ telnet to 80
Trying 216.74.32.103...
Connected to to.
Escape character is '^]'.
GET / HTTP/1.1
Host: to

HTTP/1.1 200 OK
Date: Thu, 03 Dec 2009 18:34:04 GMT
Server: Apache/1.3.27 (Unix)  (Red-Hat/Linux) mod_perl/1.26
Transfer-Encoding: chunked
Content-Type: text/html; charset=ISO-8859-1

2d7
<!DOCTYPE html
    PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
     "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en-US" xml:lang="en-US">
<head>
<title>TO. -- Get Shorty URL</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
</head>
<body>
<form method="post" action="/" enctype="multipart/form-data">
<table><tr><td>Enter a long URL:</td> <td><input type="text" name="url"  size="50" /></td></tr><tr><td>Enter an optional name:</td> <td><input type="text" name="name"  size="20" /></td></tr><tr><td>&nbsp</td> <td><input type="submit" name="&#39;Witz that URL!" value="&#39;Witz that URL!" /></td></tr></table></form>
</body>
</html>
0

Connection closed by foreign host.

A razão pela qual é uma boa idéia usar o link "é porque alguns navegadores tentam converter" para "em" link "na barra de endereço.

    
por 03.12.2009 / 19:39
15

Qualquer zona DNS pode ter qualquer registro DNS para essa zona em si (em um arquivo de configuração de vinculação, esse registro é rotulado com um @). Na verdade - deixe-me perguntar isso - a zona raiz pode ter um @ para descrever a si mesmo? IE pode @ ter um registro de endereço? Eu não vejo porque não pode. que seria um endereço legal para ter. " link "

A zona "Root" é simplesmente uma zona chamada ".". No momento, essa zona tem um monte de servidores de nomes. Os endereços desses servidores de nomes são distribuídos como um arquivo de texto . Este arquivo de texto ou algo semelhante é inserido manualmente em muitos servidores de nomes recursivos típicos.

Colocando um "." no final de um nome informa ao seu resolvedor local que o nome que você digitou é um " totalmente qualificado " nome de domínio, o que significa que é exatamente e apenas o nome que você deseja procurar. Muitas vezes, usamos nomes não qualificados ou ambíguos como "www" para significar "www.of.the.place.I.work", onde o seu resolvedor de DNS local tem "of.he.place.I.work" como o "dns domínio "ou" domínio de pesquisa ".

Esses servidores de domínio de nível raiz têm uma lista de domínios " de nível superior " que mapeiam aproximadamente para abstrações antigas de como os pesquisadores dos anos 80 pensavam que a Internet seria usada e countries e um domínio de nível superior para" infraestrutura ". Cada um desses domínios de nível superior tem vários servidores de nomes que têm listas de zonas reais nesse domínio. Por isso, uma solicitação de maps.google.com vai primeiro para um servidor de nível raiz que distribui uma lista de servidores de nome que conhecem. com, e quando perguntado, um deles sabe sobre qual servidor de nomes tem registros para google.com e um deles conhece o registro específico para www.google.com.

Portanto, tudo o que você precisa fazer é convencer quem quer que execute o TLD de um país ou organização a inserir um registro de endereço para .zone em vez de apenas google.zone e você é de ouro.

Atualmente, os domínios de nível superior a seguir têm registros de endereço (embora nem todos executem servidores da Web)

ac has address 193.223.78.210
ai has address 209.59.119.34
bi has address 196.2.8.205
cm has address 195.24.205.60
dk has address 193.163.102.23
gg has address 87.117.196.80
hk has address 203.119.2.28
io has address 193.223.78.212
je has address 87.117.196.80
ph has address 203.119.4.7
pn has address 80.68.93.100
pw has address 203.199.114.33
sh has address 64.251.31.234
tk has address 217.119.57.22
tm has address 193.223.78.213
to has address 216.74.32.103
uz has address 91.212.89.8
ws has address 63.101.245.10

e o seguinte tem registros mx (assim, o usuário @ TLD. é um endereço potencialmente entregável)

ai mail is handled by 10 mail.offshore.ai.
as mail is handled by 10 dca.relay.gdns.net.
cf mail is handled by 10 mail.intnet.cf.
dj mail is handled by 5 smtp.intnet.dj.
dj mail is handled by 5 relais2.intnet.dj.
dm mail is handled by 10 mail.nic.dm.
gp mail is handled by 20 manta.outremer.com.
gp mail is handled by 5 ns1.nic.gp.
gp mail is handled by 10 ns34259.ovh.net.
gt mail is handled by 10 mail.gt.
hr mail is handled by 10 alpha.carnet.hr.
io mail is handled by 10 mailer2.io.
kh mail is handled by 10 ns1.dns.net.kh.
km mail is handled by 110 bow.snpt.km.
km mail is handled by 100 mail1.comorestelecom.km.
mh mail is handled by 10 imap.pwke.twtelecom.net.
mh mail is handled by 20 mx1.mail.twtelecom.net.
mh mail is handled by 30 mx2.mail.twtelecom.net.
mq mail is handled by 10 mx1-mq.mediaserv.net.
ne mail is handled by 20 bow.rain.fr.
ne mail is handled by 10 bow.intnet.ne.
pa mail is handled by 5 ns.pa.
td mail is handled by 0 mail.intnet.td.
tt mail is handled by 0 66-27-54-138.san.rr.com.
tt mail is handled by 10 66-27-54-142.san.rr.com.
ua mail is handled by 10 mr.kolo.net.
va mail is handled by 20 paul.vatican.va.
va mail is handled by 50 proxy2.urbe.it.
va mail is handled by 90 john.vatican.va.
va mail is handled by 10 lists.vatican.va.
ws mail is handled by 10 mail.worldsite.ws.

(Eu realmente me pergunto sobre o que está acontecendo com "tt" aqui ...)

Então, em teoria, você poderia enviar um email para o pape @ va. e será entregue corretamente ...

Se você usar diferentes servidores-raiz, terá uma visão diferente do que existe na Internet. Todas as resoluções locais que eu fiz foram contra o meu sistema local que está usando " dnscache " que vai diretamente para os servidores raiz . Muitos outros servidores DNS de resolução perguntarão a outro servidor DNS local em vez de perguntar aos servidores raiz.

    
por 03.12.2009 / 21:24
5

Como não é? Não há nenhuma limitação para as "seções" mínimas que um domínio deve ter. É um ccTLD para Tonga como us , eu , uk , me , .... O seguinte ponto significa que é um subdomínio do domínio raiz. De fato, xyz.com é realmente xyz.com. .

Basicamente, o que eles fizeram foi simplesmente adicionar um registro A apontando para um servidor da Web. Eles possuem o servidor de nomes responsável por responder as consultas de to. e todos os seus subdomínios para que possam fazer isso facilmente.

Demonstração do fato:

MehrdadAir:~ Mehrdad$ ping to.
PING to (216.74.32.103): 56 data bytes
Request timeout for icmp_seq 0
^C
--- to ping statistics ---
2 packets transmitted, 0 packets received, 100.0% packet loss
MehrdadAir:~ Mehrdad$ telnet 216.74.32.103 80
Trying 216.74.32.103...
Connected to 216.74.32.103.static.sfo.hosting.com.
Escape character is '^]'.
GET / HTTP/1.0
Host: to.
User-Agent: Mozilla


HTTP/1.1 200 OK
Date: Thu, 03 Dec 2009 18:41:05 GMT
Server: Apache/1.3.27 (Unix)  (Red-Hat/Linux) mod_perl/1.26
Connection: close
Content-Type: text/html; charset=ISO-8859-1

<!DOCTYPE html
    PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
     "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en-US" xml:lang="en-US">
<head>
<title>TO. -- Get Shorty URL</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
</head>
<body>
<form method="post" action="/" enctype="multipart/form-data">
<table><tr><td>Enter a long URL:</td> <td><input type="text" name="url"  size="50" /></td></tr><tr><td>Enter an optional name:</td> <td><input type="text" name="name"  size="20" /></td></tr><tr><td>&nbsp</td> <td><input type="submit" name="&#39;Witz that URL!" value="&#39;Witz that URL!" /></td></tr></table></form>
</body>
</html>
Connection closed by foreign host.

PS: Com base no conteúdo deste tópico, estou absolutamente convencido de que o software usado por alguns operadores de Internet (ISPs, ...) não segue as especificações corretamente e apenas acontece de seguir convenções. Provavelmente é por isso que o domínio está quebrado para muitas pessoas.

    
por 03.12.2009 / 19:12
3

É raro que um domínio de nível superior tenha um registro A, mas é perfeitamente legítimo. Pense em como você pode ter "www.foo.com" e "foo.com" ter registros diferentes e aplicá-los até o ccTLD tonganês, .to.

    
por 03.12.2009 / 19:18
3

sim ...

"telnet www.to 80" ... escrevendo "GET /" funciona

"telnet www.to.80" ... escrevendo "GET /" funciona

"telnet para 80" ... não foi possível abrir a conexão

"telnet para 80" ... não foi possível abrir a conexão

então sim, eu acho que o navegador está ajudando. m.

    
por 03.12.2009 / 19:23
3

Parece que alguém comprou o todo. TLD link como Mehrdad disse que você pode adicionar um registro A. Eu acho que eles estão apenas adicionando o. ao final de www.to. para certificar-se de que o que está procurando o endereço procura na raiz do tld. a . no final de todos os domínios deve ser implícito de qualquer maneira o que eu não entendo é porque serverfault.com. devolver um 400 Pedido Ruim?

    
por 03.12.2009 / 19:28
3

Sendo um TLD, também pode ter um registro A apontando para um endereço IP, assim como example.com pode ter um registro A.

Edit: De acordo com alguns testes com o nslookup, parece que o registro A para "to" é diferente daquele para "www.to", embora eu não tenha certeza se isso é uma falha ou não.

    
por 03.12.2009 / 19:26
2

isso não tem nada a ver com navegadores. 'to' tem um Registro de Recurso DNS, simples assim:

$ORIGIN to.
@ SOA to. admin.to. ( ... )
@ A 123.4.5.6
    
por 03.12.2009 / 19:32
2

Nenhum navegador de ajuda é necessário:

$ curl -i "http://to./check"
HTTP/1.1 302 Found
Date: Thu, 03 Dec 2009 18:27:20 GMT
Server: Apache/1.3.27 (Unix)  (Red-Hat/Linux) mod_perl/1.26
Location: http://madmw.tumblr.com/tagged/check <<<=== Actual URL
Transfer-Encoding: chunked
Content-Type: text/plain

Parece que todo o TLD está mapeado para um endereço IP (vs. uma hierarquia do DNS), tente:

$dig to.
...
to.         85265   IN  A   216.74.32.103
...

Mas verifique qualquer outro TLD:

$dig as.
as.         600 IN  SOA dca.tld.gdns.net. hostmaster.gdns.net.as. 56480 10800 1800 604800 21600

Não sei se isso segue as regras da ICANN, mas é apenas uma questão de configurar o DNS para o DNS de todo o TLD de um país.

    
por 03.12.2009 / 19:36
2

Aparentemente, nem todas as entidades DNS em cache estão preparadas para que um TLD tenha um registro A, já que funcionou apenas com 50% dos 2 servidores DNS que eu tentei.

Esses navegadores amigáveis "consertam" o domínio nesse caso para garantir que não ajudem a esclarecer a confusão.

    
por 03.12.2009 / 19:24
2

isso não é novo. dot tk vem oferecendo isso há muito tempo. olha tweak.tk então a guia técnica. eles fazem isso mais legal, link também é abcde.tk, que é até mesmo encurtador!

    
por 03.12.2009 / 20:13
2

Acho que a resposta simples é que o proprietário do servidor da Web

to.

como cabeçalho de host http (adicional) para esse site.

O problema aqui é que alguns servidores DNS podem resolver "para" e "para". (O DNS do Google diz 216.74.32.103) e alguns simplesmente não podem.

    
por 03.12.2009 / 19:40
2

A especificação DNS também permite que um período posterior seja usado para denotar a raiz, por exemplo, "a.b.c" e "a.b.c." são equivalentes, mas o último é mais explícito e é necessário para ser aceito pelos aplicativos. Essa convenção é especialmente importante quando um nome de DPN está sendo encaminhado diretamente. Por exemplo, enquanto ".COM" se tornou a terminologia popular para se referir a esse domínio de nível superior, "COM". seria estritamente e tecnicamente correto ao falar sobre o DNS, pois mostra que "COM" é um nome de domínio de nível superior.

De: ftp://ftp.rfc-editor.org/in-notes/rfc3696.txt

    
por 03.12.2009 / 22:33
1

Como foi indicado. "para." é uma maneira válida de especificar um nome completo do host. Nenhuma outra parte do seu nome DNS "típico" é necessária.

Se você observar essa captura de tela de "cavar para.", verá que "para". tem um registro de 216.74.32.103 :

Eu estou supondo que Tonga decidiu permitir isso em troca de algo (frio, dinheiro vivo, possivelmente?)

    
por 03.12.2009 / 19:40
1

Qualquer chance de que tenha algo a ver com o OpenDNS. No meu computador de casa usando o OpenDNS nslookup retorna um endereço IP. No meu trabalho os computadores através da VPN não resolvem e o link não faz nada.

Poderia ser um bug com o OpenDNS ... isso parece estar agindo de forma semelhante à sua funcionalidade de atalho, onde você insere algo como 'mail' como atalho e ' link 'como o site, e quando você digita' e-mail 'da sua rede definida, o leva para' link '. Possivelmente alguém definiu sua rede como 0.0.0.0 e criou 'to' como um atalho? Se for esse o caso, seria uma grande oportunidade para explorar os usuários do OpenDNS!

    
por 03.12.2009 / 19:36
1

Talvez uma pergunta ainda mais intrigante seja: por que eles não encurtam os links para

 http://go.to/S50kahUN

em vez de

 http://www.to/S50kahUN
    
por 03.12.2009 / 22:39
1

Então a questão é por que isso não funcionaria? E a resposta é que depois que a Verisign decidiu introduzir um curinga no .com. Alguns anos atrás, os desenvolvedores do bind introduziram o conceito de uma zona 'somente delegação'. Em uma zona somente de delegação, qualquer registro A que não seja cola inferior para um registro NS não será aceito pelo resolvedor e o cliente receberá um NXDOMAIN.

Então, do ponto de vista estrito do protocolo, tudo bem para o "para". Nome DNS para ter um registro A, na prática, não funcionará para clientes de alguns ISPs.

Você pode colocar:

zone "com." { type delegation-only; };

no seu named.conf para ativar isso apenas para o .com. domínio, ou você pode ativá-lo para todos os TLDs, mas excluir alguns deles adicionando às opções {} bloquear algo como:

root-delegation-only exclude { "de"; "to"; };

Há uma longa lista de domínios "aceitos" aqui que são comumente permitidos, como "to", mas dependendo de como BOFHish você está se sentindo, você pode limitar isso mais.

O link moveu-se desde a primeira vez que o anotei, e novamente desde que escrevi esta resposta pela primeira vez, mas acho que é para isto que eu apontei: link

    
por 10.12.2009 / 09:58
0

Aviso: eu sei apenas o suficiente sobre DNS para ser perigoso. Mas aqui está o que eu sei:

. é o domínio raiz; to é um abaixo disso

Isso faz mais sentido (e funciona!):

link

Então, basicamente, estamos omitindo a parte www e o navegador está inferindo isso?

Visão geral básica do DNS: link

    
por 03.12.2009 / 19:13
0

Fazendo um whois no TO. nome de domínio rende que é de propriedade da IANA:

Domain Name: TO
   Registrar: INTERNET ASSIGNED NUMBERS AUTHORITY (2)
   Whois Server: whois.iana.org
   Referral URL: http://www.iana.org
   Name Server: AUTH02.NS.UU.NET
   Name Server: COLO.TO
   Name Server: NS-TO.RIPE.NET
   Name Server: NS1.IAFRICA.COM
   Name Server: TONIC.TO
   Status: clientDeleteProhibited
   Status: clientTransferProhibited
   Status: clientUpdateProhibited
   Status: serverDeleteProhibited
   Status: serverTransferProhibited
   Status: serverUpdateProhibited
   Updated Date: 23-oct-2008
   Creation Date: 18-dec-1995
   Expiration Date: 31-dec-2099
    
por 16.12.2009 / 16:11
0

Algumas capturas de tela mostram que http://to./ produz um site diferente de http://www.to./ :


http://to./ versus http://www.to./ (clique para ampliar)

Os endereços IP também são diferentes: 216.74.32.103 versus 74.54.218.210 hoje.

Então: se alguém está vendo o mesmo para as duas URLs, então o navegador está realmente bagunçando e provavelmente está mostrando www.to para ambos.

http://www.to./ provavelmente não precisa do ponto final para dizer aos navegadores para não tentar nada extravagante e, portanto, é o mesmo que http://www.to , em que www provavelmente foi registrado como domínio de segundo nível por outra empresa não relacionada.

    
por 13.12.2009 / 18:40
-3

Eles possuem www.to, portanto, www.www.to aponta para o mesmo URL. O navegador muda para www.to na solicitação.

    
por 03.12.2009 / 19:16