Re: questions

[Jim Reid <]

>>>>> "lwc" == Conroy, Lawrence (SMTP) lwc@localhost writes:

    lwc> Yes, one can add anything - it's a domain. Strictly, there
    lwc> are a couple of issues in practice.  (i) ENUM domains I've
    lwc> seen "out there" tend to have more than one NAPTR.  Making a
    lwc> request for NAPTRs can return an answer that's several
    lwc> hundred bytes long. If there are other Resource Record types
    lwc> (such as TXT) then the answer can grow beyond 500
    lwc> octets. This can be a problem as ALL the resource records
    lwc> won't fit into a UDP answer, so it may be truncated.

Truncation shouldn't be an issue. When a DNS response is bigger than
the maximum 512-byte UDP payload (not 500!), the server sets a header
bit in the answer and truncates the reply to 512 bytes. The client
doing the lookup then repeats the query, this time over TCP instead of
UDP, to get all the data. This is how the DNS works today.

So not data gets lost. However there's the overhead and extra latency
from making a second query plus the additional overheads of setting up
and tearing down a TCP connection. This is best avoided. It's also
very unpleasant for name servers to handle 10s or 100s of short-lived
TCP connections every second. So response truncation should be avoided
if at all possible.

One way round that is EDNS0: an extension to the DNS protocol that
allows the client and server to negotiate bigger UDP payloads. When
ENUM goes into production usage it's likely to require DNSSEC so that
the authenticity and integrity of DNS responses can be verified. This
will mean cryptographic keys and signatures in the responses, making
them bigger than 512 bytes anyway. So EDNS0 is probably going to be
essential for ENUM if truncation is to be avoided. Even without
DNSSEC, the set of NAPTR records for some E.164 number is likely to be
bigger than 512 bytes anyway, as you alluded to. So perhaps the IETF
needs an RFC to mandate or strongly recommend the use of EDNS0 by ENUM
resolvers.