About this blog…

I am employed by Netnod as head of engineering, research and development and am among other things chair of the Security and Stability Advisory Committee at ICANN. You can find CV and photos of me at this page.

As I wear so many hats, I find it being necessary to somewhere express my personal view on things. This is the location where that happens. Postings on this blog, or at Facebook, Twitter etc, falls under this policy.

The views expressed on this post are mine and do not necessarily reflect the views of Netnod or any other of the organisations I have connections to.

draft-faltstrom-uri-01.txt

I have just posted a new version of my proposed specification of the URI Resource Record Type. With this, one is supposed to be able to directly look up the URI of something in a domain without having to use the NAPTR Resource Record first. An example is when one want to know the URI for the webpage of the example.com domain. Instead of “guessing” that the URI is https://www.example.com/ one is supposed to look up the URI record for the _http._web.example.com domain name and get back for example https://www.example.com, or rather, get back for example:

 _http._web.example.com. IN URI 10 10 "https://www.example.com/" 

The specifications of the prefixes for the owner (in this example _http and _web) are taken from the IANA registry of ENUM Services. One can find the draft here, and a diff from the -00 version here.

 Title : The Uniform Resource Identifier (URI) DNS Resource Record Author(s) : P. Faltstrom, O. Kolkman Filename : draft-faltstrom-uri-01.txt Pages : 10 Date : 2008-07-13 

[…]

ICANN IDN ccTLD Fast Track Mechanism report announced

Today ICANN announced the Draft Final Report of Recommendations for IDN ccTLD Fast Track Mechanism. I have been a member of the group that have worked on this, and my task has been to help with the technical requirements. You can see the report as PDF here. Part of the review of a request include a technical review, and the technical review is to look at the following:

  • The label itself is in accordance with and complies with IDNA2008 protocol
  • No characters other than identified in Unicode as Letters or [combining] marks are used
  • No characters are used that map out as compatibility equivalents and only strings that are NFC-compliant
  • No leading or trailing digits (in any script) are used.
  • No joiners or other invisible characters are used
  • There is no mixing of scripts
  • The proposed string is valid both for IDNA2003 and IDNA2008
  • No names that are shorter than three characters in ASCII, nor names shorter then two characters in non-ASCII are used
  • It is demonstrated that the language and script chosen for the Language table for an IDN-ccTLD, is an “official” language in Territory, regardless of the The TLD proposed in combination with the language table being used when operational together with the Language Table does not create rendering problems in URLs, Email addresses etc., when in use. […]

  • www.google.com, what is happening?

    When looking up www.google.com in DNS, some new things happens. Have a look at this. Unfortunately I do not know what it was before this. How many people will get problems?

     # dig www.google.com a ;; Truncated, retrying in TCP mode. ; <> DiG 9.4.1-P1 <> www.google.com a ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60013 ;; flags: qr rd ra; QUERY: 1, ANSWER: 29, AUTHORITY: 7, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.google.com. IN A ;; ANSWER SECTION: www.google.com. 513241 IN CNAME www.l.google.com. www.l.google.com. 300 IN A 64.233.161.99 www.l.google.com. 300 IN A 64.233.183.147 www.l.google.com. 300 IN A 74.125.19.147 www.l.google.com. 300 IN A 64.233.169.104 www.l.google.com. 300 IN A 209.85.171.103 www.l.google.com. 300 IN A 64.233.169.147 www.l.google.com. 300 IN A 209.85.135.103 www.l.google.com. 300 IN A 209.85.135.99 www.l.google.com. 300 IN A 72.14.235.104 www.l.google.com. 300 IN A 150.101.98.219 www.l.google.com. 300 IN A 209.85.195.99 www.l.google.com. 300 IN A 150.101.98.216 www.l.google.com. 300 IN A 64.233.189.99 www.l.google.com. 300 IN A 72.14.235.147 www.l.google.com. 300 IN A 209.85.129.99 www.l.google.com. 300 IN A 209.85.165.103 www.l.google.com. 300 IN A 74.125.45.99 www.l.google.com. 300 IN A 209.85.171.104 www.l.google.com. 300 IN A 64.233.167.104 www.l.google.com. 300 IN A 66.102.9.99 www.l.google.com. 300 IN A 66.249.89.104 www.l.google.com. 300 IN A 64.233.167.99 www.l.google.com. 300 IN A 66.249.93.147 www.l.google.com. 300 IN A 209.85.153.104 www.l.google.com. 300 IN A 209.85.193.103 www.l.google.com. 300 IN A 74.125.45.147 www.l.google.com. 300 IN A 66.249.91.104 www.l.google.com. 300 IN A 209.85.193.99 ;; AUTHORITY SECTION: l.google.com. 20107 IN NS g.l.google.com. l.google.com. 20107 IN NS d.l.google.com. l.google.com. 20107 IN NS c.l.google.com. l.google.com. 20107 IN NS a.l.google.com. l.google.com. 20107 IN NS b.l.google.com. l.google.com. 20107 IN NS e.l.google.com. l.google.com. 20107 IN NS f.l.google.com. ;; Query time: 11 msec ;; SERVER: 85.30.129.39#53(85.30.129.39) ;; WHEN: Sat Jun 14 10:10:21 2008 ;; MSG SIZE rcvd: 612 

    Updated: It seems to be one of the nameservers for the l.google.com domain that is releasing what I would call too many records. Yes, I have been in contact with friends at Google. Things are under control.

     # dig @d.l.google.com www.l.google.com a ; <> DiG 9.4.1-P1 <> @d.l.google.com www.l.google.com a ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57906 ;; flags: qr aa rd; QUERY: 1, ANSWER: 28, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;www.l.google.com. IN A ;; ANSWER SECTION: www.l.google.com. 300 IN A 209.85.165.104 www.l.google.com. 300 IN A 66.249.93.147 www.l.google.com. 300 IN A 64.233.167.104 www.l.google.com. 300 IN A 209.85.175.104 www.l.google.com. 300 IN A 72.14.235.99 www.l.google.com. 300 IN A 150.101.98.214 www.l.google.com. 300 IN A 209.85.165.99 www.l.google.com. 300 IN A 64.233.169.147 www.l.google.com. 300 IN A 209.85.193.103 www.l.google.com. 300 IN A 150.101.98.210 www.l.google.com. 300 IN A 150.101.98.218 www.l.google.com. 300 IN A 150.101.98.217 www.l.google.com. 300 IN A 64.233.183.104 www.l.google.com. 300 IN A 66.249.91.99 www.l.google.com. 300 IN A 72.14.205.103 www.l.google.com. 300 IN A 66.249.93.99 www.l.google.com. 300 IN A 209.85.195.99 www.l.google.com. 300 IN A 150.101.98.219 www.l.google.com. 300 IN A 150.101.98.211 www.l.google.com. 300 IN A 209.85.173.104 www.l.google.com. 300 IN A 209.85.165.147 www.l.google.com. 300 IN A 74.125.45.99 www.l.google.com. 300 IN A 150.101.98.215 www.l.google.com. 300 IN A 64.233.169.103 www.l.google.com. 300 IN A 72.14.215.99 www.l.google.com. 300 IN A 64.233.161.104 www.l.google.com. 300 IN A 209.85.129.99 www.l.google.com. 300 IN A 209.85.171.147 ;; Query time: 44 msec ;; SERVER: 66.249.93.9#53(66.249.93.9) ;; WHEN: Sat Jun 14 10:42:19 2008 ;; MSG SIZE rcvd: 482 # dig @c.l.google.com www.l.google.com a ; <> DiG 9.4.1-P1 <> @c.l.google.com www.l.google.com a ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34378 ;; flags: qr aa; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.l.google.com. IN A ;; ANSWER SECTION: www.l.google.com. 300 IN A 64.233.183.104 www.l.google.com. 300 IN A 64.233.183.147 www.l.google.com. 300 IN A 64.233.183.99 ;; Query time: 111 msec ;; SERVER: 64.233.161.9#53(64.233.161.9) ;; WHEN: Sat Jun 14 10:42:47 2008 ;; MSG SIZE rcvd: 82 

    […]

    The brain of the Internet is ready for IP version 6

    Computer Sweden writes in an article that the brain of the Internet is ready for IP version 6. I think the headline is hilarious. DNS root servers being the brain of the Internet? Well, well. The good thing is that the article, specifically including the answers by my friend Patrik are excellent. Correct, but in Swedish. Like if it was encrypted. Sort of… […]

    Frobbit! respond to open consultation on new model for .SE ccTLD

    The .SE Registry hav had some proposals for considerations since Dec 2007 regarding a new registry/registrar model for .SE. It is a bit hard to find the proposal in English, but you can find them here on the .SE website. They are available in Swedish as well. Note that if you respond in English you have until Feb 13 to respond, while we that respond in Swedish had yesterday (Feb 4) as the last day. On the other hand, we swedish speaking people got the documents weeks before the english versions where released. Frobbit! has responded to the proposals of course, and those of you that understand Swedish can read on the Frobbit! blog what Frobbit! think, and you can of course also see the full response here. In short, the Frobbit! response include the following main points:

  • Keep the in Sweden used term Ombud for the english term Registrar.
  • One does not have to talk about Accredited Registrar, as a Registrar can only be Registrar if they have a signed agreement with .SE. Because of that, it is enough to say Registrar (or Ombud, see above). This might be specifically important as the term accredited have various formal meanings in Sweden.
  • .SE should not in the agreement define whether the Registrar can use a Reseller or not. It sounds like if some Registrars do not understand they have an agreement with .SE and because of that responsible to .SE for what happens — regardless of whether they deal with registrants directly or indirectly.
  • The agreement proposal itself is confusing. Many things where repeated, some other unnecessary, and because of that Frobbit! wrote a counter proposal.
  • The agreement must be reciprocal, which Frobbit! do not believe the proposal was. .SE had only three(!) things they had to promise to do, while the registrar had tons of requirements on them (such as responding to communication in time etc).
  • Frobbit! believe the release of domain names that are becoming available on the market should be released with a sunrise like process (but short, about an hour) instead of the race that is used today. […]

  • No more Domain Tasting?

    ICANN board at a board meeting last week made a decision that definitely will help stopping domain name tasting. The interesting points are 5) Proposals to Address Domain Tasting and 6) Compliance Report on Network Solutions’ Domain Reservation Activities and the decision was: THEREFORE, the Board resolves (2008.01.04) to encourage ICANN’s budgetary process to include fees for all domains added, including domains added during the AGP, and encourages community discussion involved in developing the ICANN budget, subject to both Board approval and registrar approval of this fee. A voice vote was taken of all Board Members present and the motion was approved by a vote of 13-0. Bruce Tonkin abstained from voting on this item. I think this is an important step towards killing any kind of domain name tasting. As you can see in the minutes from the ICANN board meeting, we have been discussing this a lot in SSAC lately. Updated: Here is the press release from ICANN about it. […]

    SSAC report #25 on Fast Flux

    SSAC has released a report on Fast Flux that might be interesting to read for people that are trying to make it easier to find bad guys on the net. Fast flux implies rapid modification of IP addresses associated with a system that hosts a malicious activity, or hosts a domain name that is used for such activities. All to try to make it harder to find and close the services in question. The report ends with the following: Fast flux hosting is a serious and mounting problem that affects name services in all GTLDs. SSAC encourages ICANN, registries and registrars to consider the practices mentioned in this Advisory, to establish best practices to mitigate fast flux hosting, and to consider incorporating such practices in future accreditation agreements. […]

    DNS film

    My friend Desiree was responsible for some events in London yesterday where the 25th anniversary of DNS was remembered. Unfortunately I could not come to the meeting, although she invited me. I am sorry for that but I had soo much to do in Stockholm today, and travelling from London to Stockholm was problematic. She writes in her blog about a film she has made about DNS. Of course, she has put the film on YouTube. You can even see some Swedish in there! Well done Desiree! […]

    AAAA glue to the root zone

    The other day it was announced that AAAA glue (IPv6 addresses for the root DNS servers) will be added to the root zone. Although I was not a formal member of SSAC at the time of writing this report (I am a member now), I was involved in the discussions around the report that is quoted in the report, and I completely agree with the conclusions that include: On the basis of the above findings, the committees conclude that changing the DNS priming response to include IPv6 address records will have minimal impact on name server implementations and intermediate systems used in production networks. What can be worth reading is the part of the report that is a test of home gateways and routers whether they can handle various features that are related to IPv6 deployment. A test that btw has been continued by .SE regarding DNSSEC features. The message from IANA reads:

     On 4 February 2008, IANA will add AAAA records for the IPv6 addresses of the four root servers whose operators have requested it. A technical analysis of inserting IPv6 records into the root has been done by a joint working group of ICANN's Root Server System Advisory Committee and Security and Stability Advisory Committee, a report of which can be found at https://www.icann.org/committees/security/ sac018.pdf. Network operators should take whatever steps they feel appropriate to prepare for the inclusion of AAAA records in response to root queries. More information will be posted to the IANA web site during January. Regards, Barbara Roseman IANA General OperationsManager ICANN 

    Updated: Some people have asked me what is really happening operationally. We will get AAAA records for the hostnames of the servers that are authoritative for the root zone. This implies DNS clients that want to issue DNS queries to those servers will start use IPv6 transport. Of course those DNS servers at that time will also respond to those queries. This implies two things. First of all, one can for the first time for real use IPv6 transport only for resolution of DNS queries. Secondly, resolvers that think they have IPv6 connectivity (to the now published IPv6 addresses) that in reality do not have it might get delays in resolution of DNS queries. They have to wait for a timeout and then fall back to IPv4 transport. […]

    ENUM, history and the future

    I am now in Amsterdam at the 3rd ENUM day hosted by SIDN. My presentation will be about history of ENUM, and of course some thinking on the future of ENUM. You can find my presentation here. […]