<<< Chronological >>> | Author Index Subject Index | <<< Threads >>> |
Re: questions
- Date: Tue, 25 Nov 2003 14:46:02 +0000
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) [email protected] 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.
- Post To The List:
- Follow-Ups:
- Re: questions
- From: Jim Reid
- Re: questions
- References:
- Re: questions
- From: Jim Reid
- Re: questions
<<< Chronological >>> | Author Subject | <<< Threads >>> |