I have just read RFC2915 (NAPTR RRs). I have noticed
that ENUM uses the regexp field rather than the replacement field. IN NAPTR 100 10 "u" "sip+E2U" "!^.*$!sip:information@tele2.se!" .
But the meaning of this regexp is really a replacement. Is there a
reason why replacement cannot be used? (the RFC actally say that replacement
MUST be a domain name, but I do not understand why).
It's an historical artifact of old DNS requirements for compression of
domain-names. The requirement on us when we designed the NAPTR record was
this:
if and only if the replacement output was strictly a domain-name then that domain-name MUST be in a field that can be compressed using DNS' domain-name compression algorithm.
The problem is that about a year after we designed the NAPTR records format, the DNS group decided to deprecate the use of DNS compression on a per field basis. But we were stuck with the REPLACEMENT field. It still has one good use though. If the simple replacement is in fact put into that field then BIND can easily know to add any relevent records to the additional information section, thus keeping your DNS round trips down.
Now, to your specific example: the reason 'sip:information@tele2.se' is not found in the REPLACEMENT field is that it isn't a valid domain-name, its a URI. The REPLACEMENT field is reserved _ONLY_ for domain-names. The actual record specification sets the type of the REGEXP field as text and the type of the REPLACEMENT field as 'dname'. If you were to actually look at the sequence of bytes in the DNS packet you could readily see the huge difference...
Following the example in draft-ietf-urn-dns-ddds-database-07.txt:
1) I have got a number +49-8141-5359799
2) The AUS would be +4981415359799
3) The First Well Known Rule would yield the First Key 4981415359799
4) In order to use DNS the First Key is converted into a domain-name
"9.9.7.9.5.3.5.1.4.1.8.9.4.e164.arpa."
5) Retrieve Rewrite Rules as NAPTR records using key
6) Apply NAPTR on AUS to produce a new key
7) If matching rule is terminal we have the result,
else goto step 5 with this key
Shouldn't step 4 be part of the First Well Known Rule according to the algorithm diagram of draft-ietf-urn-ddds-05.txt, Page 6?
Not really. I can see where the question comes from though. That diagram is generic for all databases/applications. There is a database specific step where the Key is converted into database specific form. In the Database specification this is the 'Key Format'.
Follwing the example in draft-ietf-urn-dns-ddds-database-07.txt:
1) I have got a number +49-8141-5359799
2) The AUS would be +4981415359799
3) The First Well Known Rule would yield the First Key 4981415359799
4) In order to use DNS the First Key is converted into a domain-name
"9.9.7.9.5.3.5.1.4.1.8.9.4.e164.arpa."
5) Retrieve Rewrite Rules as NAPTR records using key
6) Apply NAPTR on AUS to produce a new key
7) If matching rule is terminal we have the result,
else goto step 5 with this key
If step 4 is not part of the First Well Known Rule, where does it fit into the algorithm diagram?
It is the conversion step from the generic application into the Database specific form. I.e. this ENUM step is actually all part of the "Lookup key in DDDS Database" block in that diagram.
Correct. The DNS Database simply returns requests for Keys in the correct Format according to the existing DNS standards. Thus, the algorithm simply asks for "9.9.7.9.5.3.5.1.4.1.8.9.4.e164.arpa.", it is up to the DNS resolver to handle all DNS specific NS processes and other standard techniques.