Is DNSSEC the way to go?
Vixie's proposal looks good at first glance, because of its simplicity. Responses to queries such as www.heise.de or www.HEISE.de always come out the same in the DNS, because it ignores case. But a more precise comparison of the different bit representations of upper- and lower-case letters could give a querying server a further indication of whether a response it received had actually come from the queried server.
An upcoming IETF document recommending additional security measures to prevent forgery in the DNS recommends matching the ID field in both the query and the response from the servers as an important criterion. But upper and lower case letters have until now been regarded as interchangeable in the DNS. The suggested comparison when responding would in addition check the correctness of the net addresses of the queried and the responding system, and, on receipt of a response, the address and the port via which it had been sent.
Vixie's proposal is that the 0x20-bit part of the transaction ID sent in a query should be generated randomly and stored by the querying server. In such a case www.Heise.de and www.HeisE.de would supply a different ID in bit format. The responding server would then send back an exactly corresponding bit variant, thus supplying a further criterion for the authenticity of the response. The longer the domain name, the better the protection of transactions using this idea. Vixie commented ironically that www.disney.com would then probably, and unfortunately, be better protected than www.cia.gov. The idea has already been implemented experimentally by Nlnet Labs.
One critic of Vixie's proposal was Peter Koch, a leading figure in the IETF's DNS Operations working group. He thought little of playing around with upper- and lower-case letters in the DNS. Case insensitivity, he said, was one of the cast iron principles of the DNS. Hans-Peter Dittler, managing director of Braintec Network Consulting, warned of possible conflicts with applications on the net that were based on disregarding case.
Koch also pointed out a possible strategic problem: not only Vixie's idea, but also the other documents discussed in Philadelphia for the better protection of DNS servers, were aimed at vulnerabilities for which the IETF had developed DNSSEC. DNSSEC is supposed to safeguard the authenticity of transactions on the net by means of a system of signatures for DNS servers that goes right up to the central root servers. Koch said that if new methods were now to be pursued to obtain additional security in the DNS, people might wonder whether it wasn't time to bury DNSSEC.
Some developers felt that, during its lengthy development period, DNSSEC had prompted the introduction of a great many security measures in the DNS. Other countermeasures had since been found to deal with many of the threat scenarios for which it was originally designed. While political reservations about depositing the master key to the DNS in the USA left many developers unconcerned, they did fear that introducing the new protocol would entail at least initial difficulties, because of its technical complexity. Even for DNSSEC, DNS servers have to be appropriately prepared.
Vixie commented tersely on the charge that DNSSEC would be further undermined by his proposal, saying that he himself had produced a lot of code for DNSSEC, but had no influence on its introduction. He was only trying to do something where he himself could take a hand in things.
On the 71st IETF meeting, see also:
- Developers hope for wider use of the DKIM anti-spam protocol, heise Online news
- Measures sought against VoIP spam, heise Online news
(Monika Ermert) /