On July 1 Sweden starts as the presidency of the EU. The main site for the presidency is https://www.se2009.eu/. A new site will be presented on June 1 according to information on the web site. The Czech Republic announced they are signing the website for their presidency with DNSSEC, and of course Sweden must do something as well. Already earlier, the domainname (regeringen.se) for the government is signed with DNSSEC, so adding DNSSEC would be no problem if the parent zone (.EU) was using DNSSEC. They do not. But, the Swedish Government has https://www.eu2009.se, and that domain name is in .SE, and can be signed, and not only that, also available over IPv6. I think it is excellent that the Swedish Government this way is showing that they are early, push for new technologies, and demonstrate they are not nervous over new things. Yes, many people, myself included, helped, but most of the work was done by people at Regeringskansliet. You know who you are. Thanks! The Swedish Government even saw this so natural that they decided to not even issue a press release or anything. Of course one should use DNSSEC and IPv6 when possible. was the reaction I got when being in contact with staff. I must say that is a pretty good reaction. Now I only hope many people read this blog, and get to know about this, because I personally still think this is pretty cool. […]
Today I held a presentation [PDF] about the current status of Internationalized Domain Names. This presentation is a complement to the documents I have in another corner of my website. For people following the discussion, this is nothing new, but for newcomers the presentation might be of some help to get up to speed. The presentation was hosted by Acreo and I thank specifically Tove Madsen for arranging it. […]
At last we are done with RFC 5507 – Design Choices When Expanding the DNS. I started working on this while being on the Internet Architecture Board in May 2004. Now almost 5 years later, it is finally released.
A new Request for Comments is now available in online RFC libraries.
Title: Design Choices When Expanding the DNS Author: P. Faltstrom, Ed., R. Austein, Ed., P. Koch, Ed. Status: Informational Date: April 2009 Mailbox: email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org Pages: 18 Characters: 44045 Updates/Obsoletes/SeeAlso: None
I-D Tag: draft-iab-dns-choices-08.txt
This note discusses how to extend the DNS with new data for a new application. DNS extension discussions too often focus on reuse of the TXT Resource Record Type. This document lists different mechanisms to extend the DNS, and concludes that the use of a new DNS Resource Record Type is the best solution. This memo provides information for the Internet community.
This document is a product of the Internet Architecture Board.
INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
I want to hereby congratulate the .SE registry for a successful move to the epp protocol on March 9. Sure, I have my personal view on what could be done different, but overall, it ended up being a smooth transition. Some thing to think about for others that make this move (some things .SE did right, some things could have been better etc, so this is not a list of complaints on .SE, just a list…):
Ensure that there is a test server that can be used, always. When developing software that uses epp, one really have a need for a server to test against, so that operations one does end up being against the real registry.
Think about in detail what objects to do transfer of and not. Specifically the objects that relate to each other such as domain and contact. When a domain is transferred, what happens with the contact object? Unfortunately different registries using epp have chosen different designs, so possibly the RFCs have to be updated and clarified how this is to work.
Specify in great detail what requirements there are on attributes for the various objects. And of course give back proper response codes when some attribute values are not according to the requirements. Honestly, the largest problems when creating epp software has to do with more or less guessing how things fit together. It is extremely hard to come up with good examples on data to test on, so many things might fail when testing, but work when doing things for real (believe it or not) simply because syntax for telephone number, social security number might be wrong, or IP addresses tested with are RFC1918 ones etc.
The really interesting part have though been to see how epp ties for real in with DNS and specifically DNSSEC. This is where my main interest is. I have rewritten all key management software I have been using to use epp instead of the email interface the registry used before. And it works (not so strange). Next problem of course is that the registries that can use epp are not (always) the same organisations that run DNS. How are DNS operators to communicate with the registrars? Use epp there as well, or something simplified? Dynamic updates I am testing using http as the access mechanism, tying it together with DNSSEC so that the zones are resigned after they are updated. But the overall architecture is complicated, and I am happy I have spent so much time thinking about it. And actually doing things. I dislike myself people just talking, and not doing, so having things working make me very happy. Now it is time to start working with plain DNS operators, and think about what to do next. […]
You will in this article in Ny Teknik (in Swedish) see some examples of phishing in the real world. The pictures are from Egypt. Now we see some similar examples regarding domain names of course, but it also shows that phishing is nothing new just because of Internet, domain names, or more specifically, International Domain Names. […]
My friend Frederico Neves of the .BR ccTLD registry just reported that they are now moving forward with NSEC3 (a DNSSEC extension) in .BR top level domain. This is excellent news, and my hat is off for all the hard work Fred and his colleagues have done the last couple of years.
Since 1200 GMT today .com.br is signed using NSEC3. This is a 1.4M delegations zone and it's using opt-out with a 100 names gap. As expected the zone size increase is minimal and the average response size doubled because of the large (~60%) DO bit presence. This ends our initial DNSSEC deployment effort. Now all .br delegations have DNSSEC available. 61 zones using NSEC and 2 using NSEC3. The sec3.br testbed will be phased-out in 90 days, Regards, Fred % dig @a.dns.br com.br ds +dnssec +multi +short 19740 7 1 A8BDED281324F283E9933BF048C8230A4B32B2A6 DS 5 2 86400 20090122120001 20090115120001 33498 br. BIsqRqjTADBDI/uhpZrGvoesrHAnRbbliqqBb/BmQqk39cXfppv4xx0F BP3im2LjNkMgXBFlXr0ELpnG0xIJEE670BMMHG9h5Xh5rnUIBZLEV8UN SjvuWA/m/WIiNxTHjO5pglhZpapScCwOQCsRjTg/xN3POhl3qUAe4okg Jta/333mbNGv5eH95GozvCCd % dig @a.dns.br port53.com.br ds +dnssec +multi +short 28004 5 1 0307C113CFEB7CB04C25E759C942AA4D32887AA6 DS 7 3 86400 20090122123002 20090115123002 19740 com.br. bl8bvZW36lMm4Fp3agcO9xDpmZtTB8i0czXCTAL3B8PMYE0XzwClUZEc YYP972EHzp10FBFXYK5hilOJl935LZUFz8e0tceCMqIKz1J7Q2lFCq9e 6BKTTRoxcAjtgOeZEH8td9gicPJDKHJ7AHvEcy/tto0drqd9Ue5kATsJ K00=
I wrote earlier today about registry policies. It ended up being posted on CircleID. As you can see, there have been some comments, including some written by me. […]
Back from the holidays I must admit I was thinking quite a bit on what is good policy for a registry? Of course I have my own personal favorites that I can not walk away from easily, but instead of thinking for too long, I decided to write down now immediately what is in my head. The main reasons for this are two: the decision by ICANN to change the rules for change in policy regarding the Add Grace Periods. What is Add Grace Period you might ask? ICANN writes: A grace period is a specified number of calendar days following a gTLD registry operation in which the operation may be reversed and a credit may be issued to a Registrar.. In short, it is a time period after registering a domain name when that registration can be revoked, and no charges will apply. This has sometimes been called tasting and is something I personally feel is bad, very bad, for the registrant. Might sound weird because the whole idea behind grace periods is that the registrant should be able to change its mind. But the bad thing is that this of course is used by people making money in various pay per click mechanisms, or trading of domain names. They register a domain name, use it for a day (or whatever the grace period is) and if no revenue is connected with the domain name, it is given back. When the domain name is given back, another registrar doing the same thing is immediately registering the domain name again. Because of this, almost all thinkable domain names are of course in use all the time, without anyone paying for it. And on top of that, the large number of transactions (registrations + deletions) make it non-trivial to ensure DNS is working properly. So tasting is bad, and it is a good thing ICANN is moving towards a more strict add grace period. But why so complicated rules? Why not just say that any registrar that register a domain name in a registry have to pay for it. Many ccTLDs have that policy and it is the only way to get rid of tasting. .ORG have experience in this, and other registries/TLDs as well. Sure, it might look bad in the numbers as the number of registrations might look like if they are going down, but I claim that the number of paid registrations goes up. So to conclude, I think ICANN will still have a too relaxed policy after this change in policy (but I welcome the policy as it is better than the old one). Second thing that irritates me a bit is the decision to move forward with addition of new TLDs. I can see a reason for IDN versions of existing TLDs, and I can see a reason for many sponsored TLDs, but to open the door completely for any TLD, as long as one pays. I am sorry, but that is just plain wrong. And one can see in the comments to the policy proposal that everyone is not completely happy. My technical explanation is simple. The DNS is designed to be a hierarchal namespace. Not flat. And every step to make DNS more flat will create problems. What problems one might ask? Several, and I will not explain them here. But let me try to turn the question around, simply because I do not understand why I am to argue why I do not want new TLDs. I think the ones that really want new TLDs should explain why. “Just because” is not good enough. The two favorite other things that I have to mention, because even in Sweden people start asking about them. Although we have them implemented in .SE and it shows it is a good thing. First, that the list of domain names that will be available a certain date and time is published beforehand. Excellent, because that limits the amount of hammering on DNS and whois servers. It also makes it possible for newspapers to see what high value domain names have forgot to pay the bill. Best way to make people pay (print a notice about it in the newspaper). Secondly, the ability for people to register a domain name without delegating it. That even makes it possible to implement DNSSEC (with NSEC) without being afraid of integrity issues with zone walking. I can see that TLDs that have not implemented these two policies this way are the ones most against DNSSEC, while the ones that have better policy (like .SE) have less problems with DNSSEC. What could be improved in many TLDs though (including .SE) is the sunrise that happens every time a domain name is made available. But more about that in a different post. […]
The fifth week of conferences since October has just ended. I am sitting at O’Hare airport waiting for my flight to Copenhagen. Copenhagen in a part of the world that seems to be covered in snow. Early, far too early. And the conferences are not over for 2008 yet. One more…in India, and a few short meetings in Stockholm and New York. Then I will have a long vacation. The conferences have been covering everything from deep technical discussions on the new protocols to high level policy and international political discussions. But the things discussed are very similar. IPv6, or rather, IPv4 is discussed. When will we run out? What does that imply? What can we do about it? Do you use IPv6 yet? Can we not just tell everyone to use IPv6? Of course we can not tell people to use IPv6! People use whatever they use to access their Google, theirFacebook, their Internet. But the question is not whether they will do that. The question is whether your Internet is the same as my Internet. Will they be the same? People discuss too much I think how many customers can access one service. What we can do to support all the one-to-many architectures out there. Like Spotify that I like so much. More people should do many-to-many applications. In reality only Apple tries to do that. P2P services of today is sort of cheating. So they do not count. Domain names are also interesting to people. Or rather, interesting to the people that make money on the domain name market. When did you hear anyone asking for a new top level domain? I thought so. At the same time ICANN, responsible for these kind of discussions, have started a process of adding new top level domains. Potentially many of them. If ICANN continue to create TLDs on request to the one that pays, is not ICANN very similar to what good old Network Solutions was once upon a time before the IAHC process started? Of course there is a big difference in accountability and stakeholder participation, but it is also because of that I think ICANN should focus on accountability in the process of renewal of the organisation. And finally DNSSEC. This interesting technology that is the only today known mechanism that protects us against many not only known, but also used, attacks against the DNS. NTIA has a Notice of Inquiry open that is to be responded to Monday November
23 24, i.e. today. Many organisations either has already responded or will respond. And of course there are both good responses like the one from Internet Architecture Board, and surprising ones (I am not pointing at any particular, I leave that as an exercise to the reader). DNSSEC is needed, now. But we should not do anything in panic. Fast but not hastily as my friend Daniel Karrenberg said. The overall issue with these discussions is I think that there are too many that are conservative. That live in what for me is a day of yesterday. The future is here. It’s just not evenly distributed yet. as William Gibson said. That is so true. SAS Airbus at ORD, November 23 2008 […]
One can read (in Swedish) that PTS (Swedish Post and Telecom agency has signed their zone with DNSSEC. This is a good thing of course, and I hope we will see more organisations follow along the same path. Specifically public services. […]