<<< Chronological >>> Author Index    Subject Index <<< Threads >>>

Re: questions

Hi again Jim, folks,
- Current resolvers do switch to TCP, but I know of clients that
only talk UDP.
Yup, EDNS0 is a solution, but these cut-down UDP-only DNS clients
may well not handle that either.
Before the obvious "well, don't do it" answer is elicited, Mobile
Phones are small and can be nasty environments with a laughable
amount of memory and/or ugly apologies for a networking API.
In such limited clients, a DNS answer with the truncation flag
set is a fact of life. I, for one, would like to use ENUM before
this situation improves (or hell freezes over, whichever comes 1st).

- By no means all DNS servers accept TCP queries. Even if someone
has configured the server to do so, firewalls outside of their
control may well block TCP traffic on port 53 - (it has happened :).

Many thanks for the mention of DNSSEC - Honestly, I simply forgot it.
If I understand your earlier comments, this tends to blow the 512 byte limit
out of the water, so DNSSEC is pretty much incompatible with UDP without
EDNS0 for full (i.e. not stub) resolvers.

I would be surprised if full DNSSEC-capable resolvers turned up in my mobile phone
anytime soon, but maybe they can work with a full resolver that does do DNSSEC.

Now, who's going to tell the IT Department that 53/UDP is not enough?
... and finally, the hard bit - who's going to explain to them why :(?

all the best,
Lawrence

On 25 Nov 2003, at 12:59 pm, Jim Reid wrote:

"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.
<<< Chronological >>> Author    Subject <<< Threads >>>