csh
/
y.st.
forkattu lähteestä y.st./y.st.


			
				
					
						
						
							123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180
							<?xml version="1.0" encoding="utf-8"?>
<!--
                                                                                     
 h       t     t                ::       /     /                     t             / 
 h       t     t                ::      //    //                     t            // 
 h     ttttt ttttt ppppp sssss         //    //  y   y       sssss ttttt         //  
 hhhh    t     t   p   p s            //    //   y   y       s       t          //   
 h  hh   t     t   ppppp sssss       //    //    yyyyy       sssss   t         //    
 h   h   t     t   p         s  ::   /     /         y  ..       s   t    ..   /     
 h   h   t     t   p     sssss  ::   /     /     yyyyy  ..   sssss   t    ..   /     
                                                                                     
	<https://y.st./>
	Copyright © 2016 Alex Yst <mailto:copyright@y.st>

	This program is free software: you can redistribute it and/or modify
	it under the terms of the GNU General Public License as published by
	the Free Software Foundation, either version 3 of the License, or
	(at your option) any later version.

	This program is distributed in the hope that it will be useful,
	but WITHOUT ANY WARRANTY; without even the implied warranty of
	MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
	GNU General Public License for more details.

	You should have received a copy of the GNU General Public License
	along with this program. If not, see <https://www.gnu.org./licenses/>.
-->
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
	<head>
		<base href="https://y.st./en/weblog/2016/02-February/24.xhtml" />
		<title>ICANN&apos;s ridiculous telephone number requirement &lt;https://y.st./en/weblog/2016/02-February/24.xhtml&gt;</title>
		<link rel="icon" type="image/png" href="/link/CC_BY-SA_4.0/y.st./icon.png" />
		<link rel="stylesheet" type="text/css" href="/link/basic.css" />
		<link rel="stylesheet" type="text/css" href="/link/site-specific.css" />
		<script type="text/javascript" src="/script/javascript.js" />
		<meta name="viewport" content="width=device-width" />
	</head>
	<body>
		<nav>
			<p>
				<a href="/en/">Home</a> |
				<a href="/en/a/about.xhtml">About</a> |
				<a href="/en/a/contact.xhtml">Contact</a> |
				<a href="/a/canary.txt">Canary</a> |
				<a href="/en/URI_research/"><abbr title="Uniform Resource Identifier">URI</abbr> research</a> |
				<a href="/en/opinion/">Opinions</a> |
				<a href="/en/coursework/">Coursework</a> |
				<a href="/en/law/">Law</a> |
				<a href="/en/a/links.xhtml">Links</a> |
				<a href="/en/weblog/2016/02-February/24.xhtml.asc">{this page}.asc</a>
			</p>
			<hr/>
			<p>
				Weblog index:
				<a href="/en/weblog/"><abbr title="American Standard Code for Information Interchange">ASCII</abbr> calendars</a> |
				<a href="/en/weblog/index_ol_ascending.xhtml">Ascending list</a> |
				<a href="/en/weblog/index_ol_descending.xhtml">Descending list</a>
			</p>
			<hr/>
			<p>
				Jump to entry:
				<a href="/en/weblog/2015/03-March/07.xhtml">&lt;&lt;First</a>
				<a rel="prev" href="/en/weblog/2016/02-February/23.xhtml">&lt;Previous</a>
				<a rel="next" href="/en/weblog/2016/02-February/25.xhtml">Next&gt;</a>
				<a href="/en/weblog/latest.xhtml">Latest&gt;&gt;</a>
			</p>
			<hr/>
		</nav>
		<header>
			<h1><abbr title="Internet Corporation for Assigned Names and Numbers">ICANN</abbr>&apos;s ridiculous telephone number requirement</h1>
			<p>Day 00354: Wednesday, 2016 February 24</p>
		</header>
<p>
	This morning, I awoke to find that my laptop battery is no longer charging beyond eighty percent.
	I was able to get the battery indicator to show a full charge by restarting <a href="/en/domains/newdawn.local.xhtml">newdawn</a>, but it appears that the full battery indication is a ruse.
	The battery&apos;s charge still no longer lasts for even a full hour.
	My guess is that restarting the machine reset the charge level that the machine thinks is the maximum, but the battery has indeed become damaged.
</p>
<p>
	I finally found a page on the <abbr title="Internet Corporation for Assigned Names and Numbers">ICANN</abbr> website explaining the <a href="https://www.icann.org/news/advisory-2002-05-10-en">requirements for data in whois records</a>.
	It seems that the reason that a telephone number is required while a fax number is only optional is due to <abbr title="Internet Corporation for Assigned Names and Numbers">ICANN</abbr> wording, not registrars assuming that not everyone has a fax number and letting them off the hook on that requirement.
	I figured that it was <abbr title="Internet Corporation for Assigned Names and Numbers">ICANN</abbr> wording, but I never could find the language used.
	For reference, the offensive stipulations that require a telephone number are below:
</p>
<blockquote>
	<p>
	3.3.1.7 The name, postal address, e-mail address, voice telephone number, and (where available) fax number of the technical contact for the Registered Name; and
</p>
	<p>
	3.3.1.8 The name, postal address, e-mail address, voice telephone number, and (where available) fax number of the administrative contact for the Registered Name.
</p>
</blockquote>
<p>
	A while back, I located a potential back door for registering a domain under one of a few common <abbr title="generic top-level domain">gTLD</abbr>s without having a telephone number and without giving inaccurate information.
	Basically, there&apos;s a registry that appears no to validate the telephone number field, so you can enter &quot;I have no telephone service.&quot;, and they seem to accept it.
	There&apos;s a couple potential issues though, issues that i was aware of even when I first found it.
	Specifically, without attempting to register one of these domains, I can&apos;t be sure that the registry wouldn&apos;t reject the registration sent by the registrar.
	Even though the registrar isn&apos;t validating the data, the registry would still need to accept the input for this back door to even work.
	Second, if someone complained about your whois records, you could have your domain revoked, even if you honestly don&apos;t have a telephone number to provide.
	However, I did a bit more looking today, comparing prices.
	It seems that due to the high prices charged by this registry, it&apos;s really not worth it anyway.
	The <a href="http://www.nic.st/"><code>//st.</code> registry</a>&apos;s prices are lower and they don&apos;t even ask for a telephone number.
</p>
<p>
	I&apos;ve done some thinking about the need to meet the ridiculous telephone number requirement too.
	I&apos;ve come to the conclusion that in regards to my main domain, I need to do everything by the books.
	I cannot give anyone any ammunition to use against me and get my main domain revoked.
	For that reason, it makes perfect sense that I should stick with the <code>//st.</code> registry.
	However, auxiliary domains are lest important.
	If I lose my main domain, I lose my voice and my Internet presence, but if some jerk gets my service-providing domain revoked and I still have a voice, I can and will raise a ruckus and draw attention to the fact that the telephone number requirement is ridiculous and that not everyone has a telephone number to provide.
	However, I doubt that there will actually be any issue if I take two minor precautions.
	First, I would need to get whois privacy, preferably gratis whois privacy provided by a decent registrar as part of the domain registration.
	If gotten through <a href="https://www.gandi.net/">Gandi</a>, the whois records can still reflect my legal name, making me the legal owner, unlike with regular whois privacy.
	Second, I would need to set the telephone number seen by my registrar to be the exact same telephone number shown in the whois records.
	This accomplishes two feats.
	First, the registrar reaches their own privacy system if they try to call.
	Second, if they decide to revoke the whois privacy without my consent, they are exposing the same telephone number that was already exposed.
	If possible, it would be nice to set this telephone number correctly during the initial registration, so I&apos;ll try to figure out what their whois privacy telephone number is before registration.
</p>
<p>
	I realized today that I shouldn&apos;t file a bug report against Gogs.
	When there are two clearnet domains in use to reach the same Gogs instance, it doesn&apos;t matter which domain is used to push to anf pull from repositories.
	The only time it makes a difference is when an onion domain and a clearnet domain are used to reach the same instance.
	However, the onion domain&apos;s ports might not be forwarded correctly to allow both Web access and <abbr title="Secure Shell">SSH</abbr> access.
	There might be only one domain that allows <abbr title="Secure Shell">SSH</abbr> access, so using a dingle domain in the interface instead of using a domain dynamically chosen based on which domain is used to access the Web interface is not a bug.
</p>
<p>
	I received a letter by post today saying that I have been approved for state-issued health insurance coverage.
	There was information included about what to do if I want to have a hearing to contest their decision to cover me, but there was no insurance card included and no information on how to get the insurance card.
	Maybe they will send that later? In any case, coverage has been back dated to the first of December.
</p>
<p>
	Checking in on the spider&apos;s progress, I found that it now estimates that it requires over five more months to complete its work on the current website due to how many pages it has.
	I won&apos;t even be in this house in five months! The spider is going to end up losing months worth of data collection efforts.
</p>
<p>
	Still worrying about the effects of invalid and missing <abbr title="Server Name Indication">SNI</abbr> host names, I decided to look into how to get the <a href="apt:apache2">Apache Web Server</a> to reject requests that do not make use of <abbr title="Server Name Indication">SNI</abbr>.
	I found that <a href="https://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI">Apache rejects requests in which the <abbr title="Server Name Indication">SNI</abbr> host name does not match the host name specified in the Host header</a>.
	I tested this information out and found it to be accurate.
	Even domains with trailing dots work as expected as long as the <abbr title="Server Name Indication">SNI</abbr> host name isn&apos;t malformed.
	For example, if the <abbr title="Server Name Indication">SNI</abbr> host name is <code>example.com</code>, it will function in combination with Host headers reading <code>example.com</code> or <code>example.com.</code>, but not with <code>Host</code> headers reading <code>example.net</code>.
	Furthermore, there is a way to set up Apache to require that Web browser use <abbr title="Server Name Indication">SNI</abbr> by setting the <a href="https://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslstrictsnivhostcheck"><code>SSLStrictSNIVHostCheck</code> directive</a> to <code>on</code>.
	However, my experiments showed that this directive is ignored unless multiple virtual hosts exist on the same <abbr title="Internet Protocol">IP</abbr> address/port combination.
	Basically, if you use the <code>VirtualDocumentRoot</code> directive to dynamically set up sites like I do, you&apos;ll need to set up a second dummy <code>VirtualHost</code> in order to make the <code>SSLStrictSNIVHostCheck</code> directive have any effect.
	That worked out okay though, as I decided to also block clients that fail to send a Host header.
	I configured the dummy <code>VirtualHost</code> to take connections in which there was no Host header, showing a default site.
	After doing some further thinking though, I decided to allow clients without <abbr title="Server Name Indication">SNI</abbr> support to access the real website.
	The thing is, lack of <abbr title="Server Name Indication">SNI</abbr> support causes the Web server to potentially send the incorrect <abbr title="Transport Layer Security">TLS</abbr> certificate.
	This will either cause the Web browser to complain (seems to be common in graphical clients) or the Web browser will ignore the fact that the wrong certificate was sent (seems to be common in text-based clients).
	Why should I care? The client is causing the problem itself and the issue doesn&apos;t even effect me.
	It&apos;s not the same as when a client sends invalid <abbr title="Server Name Indication">SNI</abbr> host names and I have to avoid producing <abbr title="Uniform Resource Identifier">URI</abbr>s without trailing dots on the domains to avoid issues.
	However, I left the block on clients without Host headers.
	When a client doesn&apos;t send Host headers, it causes every website hosted at the same <abbr title="Internet Protocol">IP</abbr> address/port combination to return the same content.
	This is probably worse that the invalid <abbr title="Server Name Indication">SNI</abbr> host name issue and such clients need to be updated or dropped from use.
	Though I feel that I made the right decision in allowing <abbr title="Server Name Indication">SNI</abbr>-unaware clients to retrieve websites from my server, what initially got me thinking about doing so was the fact that I know a certain someone that prefers not to be mentioned by name used Links to retrieve pages.
	Links sends Host headers as it should, but doesn&apos;t send <abbr title="Server Name Indication">SNI</abbr> host names, likely because it doesn&apos;t discriminate against certificates that other Web browsers do.
	If Links suddenly stopped working on my website, it might be seen as some sort of attack on him/her, but that was not at all my goal.
</p>
<p>
	<a href="http://ronsor.net/">Ronsor</a> has set up an actual home page now, complete with a few other non-<abbr title="Rich Site Summary">RSS</abbr> pages.
	The site makes use of frames, which is a bit cumbersome, but it&apos;s much better than the single link to a dead site that was there before, is available at <code>/</code> unlike his <abbr title="Rich Site Summary">RSS</abbr> feed, and is easy to navigate.
</p>
		<hr/>
		<p>
			Copyright © 2016 Alex Yst;
			You may modify and/or redistribute this document under the terms of the <a rel="license" href="/license/gpl-3.0-standalone.xhtml"><abbr title="GNU&apos;s Not Unix">GNU</abbr> <abbr title="General Public License version Three or later">GPLv3+</abbr></a>.
			If for some reason you would prefer to modify and/or distribute this document under other free copyleft terms, please ask me via email.
			My address is in the source comments near the top of this document.
			This license also applies to embedded content such as images.
			For more information on that, see <a href="/en/a/licensing.xhtml">licensing</a>.
		</p>
		<p>
			<abbr title="World Wide Web Consortium">W3C</abbr> standards are important.
			This document conforms to the <a href="https://validator.w3.org./nu/?doc=https%3A%2F%2Fy.st.%2Fen%2Fweblog%2F2016%2F02-February%2F24.xhtml"><abbr title="Extensible Hypertext Markup Language">XHTML</abbr> 5.1</a> specification and uses style sheets that conform to the <a href="http://jigsaw.w3.org./css-validator/validator?uri=https%3A%2F%2Fy.st.%2Fen%2Fweblog%2F2016%2F02-February%2F24.xhtml"><abbr title="Cascading Style Sheets">CSS</abbr>3</a> specification.
		</p>
	</body>
</html>