Subject: [Enum] A note for the Implementers Draft

From: Richard Shockey <[email-masked]>
Date: Thu, 15 Sep 2005 13:45:22 -0400

Larry did you make any note of the use of RFC 2671 to permit the use in 
DNS of larger than 512 Octets in the UDP response.

I was not aware of this ..we have always speculated that some NAPTR 
responses might exceed 512 and throw the transaction into TCP.

Is this something that all ENUM requestors and responders MUST be able 
to support?

-- 

Richard Shockey, Director - Member of Technical Staff
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:57141(at)fwd.pulver.com
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683
Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or 
<mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: lconroy <[email-masked]>
Date: Fri, 16 Sep 2005 11:14:25 +0100

Hi Richard, folks,
  Lawrence here.
Experiences has had a description of the size issue, and several  
recommendations on support for TCP and EDNS0. It's still there, as  
section 6.

NOTE WELL:
The conclusions in the existing section 6 are that ENUM-involve  
clients and servers, plus recursive resolvers AND middle boxes,  
SHOULD support TCP transport for requests/responses and UDP requests/ 
responses with EDNS0 set.

Personally, I would be happy to make this a MUST (at least for EDNS0)  
for all DNS entities that are used for ENUM queries.
IMHO, everyone will need EDNS0 if/when we ever get DNSSEC deployed.

Do any of the group have comments on this?

all the best,
   Lawrence

On 15 Sep 2005, at 18:45, Richard Shockey wrote:
> Larry did you make any note of the use of RFC 2671 to permit the  
> use in DNS of larger than 512 Octets in the UDP response.
>
> Is this something that all ENUM requestors and responders MUST be  
> able to support?
>
> --

---

From: Jim Reid <[email-masked]>
Date: Sat, 17 Sep 2005 22:52:07 +0100

On Sep 16, 2005, at 11:14, lconroy wrote:
> Personally, I would be happy to make this a MUST (at least for  
> EDNS0) for all DNS entities that are used for ENUM queries.

I agree. The draft should recommend that clients use EDNS0 whenever  
possible. This is a far better option than having truncated 512-byte  
UDP responses followed by TCP retries. Any name server that gets lots  
of queries -- hundreds per second or more -- would not be happy to  
keep a TCP protocol control block  for each of these "transactions"  
if they went over TCP.

> IMHO, everyone will need EDNS0 if/when we ever get DNSSEC deployed.

This isn't a matter of opinion Lawrence. It's a matter of fact. Apart  
from explicitly querying for DNSSEC-related RRtypes, DNS clients --  
resolving name servers or stub resolvers -- will only get those  
RRtypes if they indicate that they are DNSSEC-aware. This is done by  
setting the DO bit in the EDNS0 header: see RFC3225. So a client will  
not get signed responses without EDNS0.

---

From: Richard Shockey <[email-masked]>
Date: Sat, 17 Sep 2005 20:47:20 -0400

> not get signed responses without EDNS0.

IMHO this is very very very important... I'd like to get a consensus 
from the list on this ... this could be a critical element of the 
Implementers draft .. should support for EDNSO be mandatory?

--

---

From: Jim Reid <[email-masked]>
Date: Sun, 18 Sep 2005 10:09:38 +0100

On Sep 18, 2005, at 01:47, Richard Shockey wrote:

>> This isn't a matter of opinion Lawrence. It's a matter of fact.  
>> Apart  from explicitly querying for DNSSEC-related RRtypes, DNS  
>> clients --  resolving name servers or stub resolvers -- will only  
>> get those  RRtypes if they indicate that they are DNSSEC-aware.  
>> This is done by  setting the DO bit in the EDNS0 header: see  
>> RFC3225. So a client will  not get signed responses without EDNS0.
>
> IMHO this is very very very important... I'd like to get a  
> consensus from the list on this ... this could be a critical  
> element of the Implementers draft .. should support for EDNSO be  
> mandatory?

YES! Even without DNSSEC, ENUM clients need EDNS0. There are two  
reasons:

[1] It's likely some ENUM entries will have large NAPTR RRsets which  
would exceed the 512 byte limit. EDNS0 allows for a bigger UDP  
payload which should eliminate truncated responses and TCP retries.  
This is a VERY Good Thing: less latency for the client and less load  
on the name servers.

[2] EDNS0 provides more flexibility for future expansion. There are  
extra header bits available. There might be a need to use them later  
on. Or ENUM might want to rely on some still-to-be-invented DNS  
feature which uses them.

I'd be happy to contribute a paragraph to the draft explaining why  
EDNS0 support is mandatory.

IMO the draft is fatally flawed if EDNS0 support is not made mandatory.

---

From: "Peter Williams" <[email-masked]>
Date: Sun, 18 Sep 2005 16:24:05 -0700

RFC 2671

"5 - Transport Considerations

5.1. The presence of an OPT pseudo-RR in a request should be taken as an
indication that the requestor fully implements the given version of
EDNS, and can correctly understand any response that conforms to
that feature's specification.

5.2. Lack of use of these features in a request must be taken as an
indication that the requestor does not implement any part of this
specification and that the responder may make no use of any
protocol extension described here in its response."

We can (and MUST) assert the negative as a standard track requirement: if a 
responder receives a ENUM request without an OPT pseudo-RR, it must not 
process the ENUM query. Quite what it should do might now be specified.

This is not a guide issue: this issue is normative, and must be part of the 
standards track.

>From: Jim Reid <[email-masked]>
>To: Richard Shockey <[email-masked]>
>CC: [email-masked], lconroy <[email-masked]>,"Lawrence Conroy 
>(Lawrence Conroy)" <[email-masked]>
>Subject: Re: [Enum] A note for the Implementers Draft
>Date: Sun, 18 Sep 2005 10:09:38 +0100
>
>>>resolving name servers or stub resolvers -- will only  get those  RRtypes 
>>>if they indicate that they are DNSSEC-aware.  This is done by  setting 
>>>the DO bit in the EDNS0 header: see  RFC3225. So a client will  not get 
>>>signed responses without EDNS0.
>>
>>IMHO this is very very very important... I'd like to get a  consensus from 
>>the list on this ... this could be a critical  element of the Implementers 
>>draft .. should support for EDNSO be  mandatory?
>
>YES! Even without DNSSEC, ENUM clients need EDNS0. There are two  reasons:
>
>[1] It's likely some ENUM entries will have large NAPTR RRsets which  would 
>exceed the 512 byte limit. EDNS0 allows for a bigger UDP  payload which 
>should eliminate truncated responses and TCP retries.  This is a VERY Good 
>Thing: less latency for the client and less load  on the name servers.
>
>[2] EDNS0 provides more flexibility for future expansion. There are  extra 
>header bits available. There might be a need to use them later  on. Or ENUM 
>might want to rely on some still-to-be-invented DNS  feature which uses 
>them.
>
>
>I'd be happy to contribute a paragraph to the draft explaining why  EDNS0 
>support is mandatory.
>

---

From: lconroy <[email-masked]>
Date: Mon, 19 Sep 2005 13:43:01 +0100

Hi Jim, Richards, folks,

OK - "fatally flawed if EDNS0 support is not made mandatory" is  
perhaps not the most tactful comment, given the effort that has been  
put into the document so far. However...

First - note that EDNS0 and TCP support has already been covered in  
the existing Experiences draft - please read section 6. I have  
tightened it up somewhat in the new version, but this is not a NEW  
issue.

Second - thanks for the offer, Jim, but this has to be woven into  
what's already there, so it would be better if I stitched it together.

Third - the current (and updated) text strongly recommends TCP and  
EDNS0 support, and explains that if the entities involved don't do  
this, then it isn't going to work well if at all. What we're talking  
about here is recommending that Clients MUST support EDNS0, not that  
they SHOULD.

Personally, given that EDNS0 support for larger packets consists of  
tacking a *fixed* 11 byte chunk onto the end of a packet and bumping  
the N_additional count to 1 (for any chosen reported supported  
datagram size), I do not believe that EDNS0 support in "home rolled"  
customer ENUM/DNS clients is hard.
IIUC, the chunk to report 1280 byte packets is '00 0029 0500 00000000  
0000' - gee whiz.
We'll worry about queries with "DNSSEC items requested" later.

But ... let's get real here.
This is non-trivial, and please will folks think about things before  
just saying yes.

It is not just "hand rolled" ENUM/DNS clients - the Recursive  
Resolvers need to support EDNS0, the Authoritative Servers need to  
support EDNS0 (and any middle box needs not do dump DNS messages  
larger than 512 bytes ;).

There is also the issue of Network Access Providers who support small  
MTUs.
If one uses EDNS0 and one's provider supports an MTU of 576 bytes,  
then reporting that MTU as the supported datagram size is not going  
to help. Of course, one can report a larger size, but this means that  
datagram fragmentation is going to occur, or if one is really unlucky  
the Authoritative Server will have set the DF bit in its response and  
the packet will be dumped on the way back.

Also, if it uses a standard DNS stack, then the ENUM client needs  
some way to indicate that it wants this query to indicate EDNS0  
support. That means that the stack needs a usable API.
Typically, this means that the DNS stack sends EDNS0 with *every* DNS  
query (not just ones looking for NAPTRs in an ENUM zone), but YMMV  
with different stacks and APIs.
As we cobbled together a hand-rolled stack for our mobile phone  
client, I don't worry about interfacing with the underlying DNS stack  
(just as well, as the APIs provided by DNS stacks on mobile phones  
typically "are less than ideal" - gethostbyname and that's about it  
for most of them).

----

I do worry that this mandate means that *every* involved component,  
including your ISP's (or MoFoCo's) Recursive Resolver is required to  
provide this support, and Network Access and MTU may add some  
interesting issues to the mix. Short of "sustained physical  
pressure", I don't know how one can force them to do this.

If the WG wants to go for a MUST (and the IETF/IESG agrees) then at  
least we should include a description
of what happens when everything is not playing ball, and what the  
fallback process should be for a client.
If we put in an unalloyed MUST, then some developers WILL assume that  
the send an EDNS0 query and they're done. If it doesn't work, then  
DNS is broken and they abort the process.

all the best,
   Lawrence

On 18 Sep 2005, at 10:09, Jim Reid wrote:
> [1] It's likely some ENUM entries will have large NAPTR RRsets  
> which would exceed the 512 byte limit. EDNS0 allows for a bigger  
> UDP payload which should eliminate truncated responses and TCP  
> retries. This is a VERY Good Thing: less latency for the client and  
> less load on the name servers.
>
> extra header bits available. There might be a need to use them  
> later on. Or ENUM might want to rely on some still-to-be-invented  
> DNS feature which uses them.
>
>

---

From: lconroy <[email-masked]>
Date: Tue, 20 Sep 2005 10:19:54 +0100

Hi there,
   I beg to differ slightly with the statement that this is not a  
guide issue.
IIUC, what folk aim to say is that EDNS0 ->support<- is mandatory,  
NOT that
an ENUM/DNS Client MUST only send EDNS0 queries.

Of course, we ADVISE that these queries should go out with EDNS0  
(which is
why it's in the guide - it's advisory).

However, nowhere in RFC2671 does is state that support for EDNS0  
means that
"standard" queries according to RFC1035 MUST NOT be answered.
That would certainly be a standards track issue, and would IMHO be  
both bad
and wrong.

all the best,
   Lawrence

On 19 Sep 2005, at 00:24, Peter Williams wrote:
> We can (and MUST) assert the negative as a standard track  
> requirement: if a responder receives a ENUM request without an OPT  
> pseudo-RR, it must not process the ENUM query. Quite what it should  
> do might now be specified.
>
> This is not a guide issue: this issue is normative, and must be  
> part of the standards track.
>
>
>
>> CC: [email-masked], lconroy <[email-masked]>,"Lawrence  
>> Conroy (Lawrence Conroy)" <[email-masked]>
>>>> clients --  resolving name servers or stub resolvers -- will  
>>>> only  get those  RRtypes if they indicate that they are DNSSEC- 
>>>> aware.  This is done by  setting the DO bit in the EDNS0 header:  
>>>> see  RFC3225. So a client will  not get signed responses without  
>>>> EDNS0.
>>>>
>>>
>> retries.  This is a VERY Good Thing: less latency for the client  
>> and less load  on the name servers.
>>
>> [2] EDNS0 provides more flexibility for future expansion. There  
>> are  extra header bits available. There might be a need to use  
>> them later  on. Or ENUM might want to rely on some still-to-be- 
>> invented DNS  feature which uses them.
>>
>>
>> I'd be happy to contribute a paragraph to the draft explaining  
>> why  EDNS0 support is mandatory.
>>

---

From: "Peter Williams" <[email-masked]>
Date: Tue, 20 Sep 2005 03:10:54 -0700

I think I understand the intent of the language in reflecting the group's 
state of mind, but Im attempting to read the material as would a new 
(intelligent) reader, one without the benefit of WG experience.

After 10+ years of IETF experience, Ive really no idea what "mandatory 
<feature>_support_" means. Im either conforming with MUST, SHOULD or MAY in 
my implementation or i'm not. On this issue, there seems no reason not to 
expect the definition of conformance to be pretty clear. (ok. the political 
layer in IETF means that implementor guides add the unauthorized "ADVISE" to 
the conformance option set, but, lets not go there.)

Let me be priggish, for the sake of clarity, expecting the answer to the 
following to be "NO":

does "mandatory feature support" equate to initiators "SHOULD" send the 
EDNSO-format queries?

The rationale for SHOULD might be that (a) ENUM wont work half the time if 
non-EDNSO queries are sent (b) sending EDNSO queries with the magic const 
bytes at least addresses the transport issue without obliging the client to 
have the capability to process any EDNSO protocol elements (c) responders 
recognizing that the UDP limit has been reached on a non EDNSO query 
response might reasonably abandon the operation, in a manner conforming with 
the incoming transport (e.g. UDP tunneled over an IPSEC/IKEv2 TCP-based SA)

Now to the impudent, priggish part: why not have SHOULD in the stds 
language, and why punt to the implementors guide? My red flag went up, 
especially as the introduction to the issue was founded in ..... DNS SEC 
issue area. lets mark the language used:  "feature support" mandatory, 
DNSSEC, signed responses, implied client support for processing DNS signed 
responses....ENUM WG has punted DNSSEC till "later"...

Im worried we are just mandating DNSSEC "feature support" by the back door, 
becuase its politically too hot to do in the stds track. But using guides 
for this purpose this is like the "just under the legal definition of 
torture" culture: it has bad sideeffects on the stds process, once we start 
down this track. Its politically expedient and perhaps even necessary in 
todays ENUM-based VOIP to start signing the E.164 entries in the Carrier 
ENUM domain adminsitration model; but do we really want to mandate that in a 
backdoor manner?

What started out as "solve the practical UDP problem using accepted 
migration strategies" quickly started being about DNSSEC, and thats whats 
worried me.

>From: lconroy <[email-masked]>
>To: Peter Williams <[email-masked]>
>CC: [email-masked]
>Date: Tue, 20 Sep 2005 10:19:54 +0100
>
>Hi there,
>   I beg to differ slightly with the statement that this is not a  guide 
>issue.
>IIUC, what folk aim to say is that EDNS0 ->support<- is mandatory,  NOT 
>that
>Of course, we ADVISE that these queries should go out with EDNS0  (which is
>However, nowhere in RFC2671 does is state that support for EDNS0  means 
>that
>That would certainly be a standards track issue, and would IMHO be  both 
>bad
>and wrong.
>
>all the best,
>   Lawrence
>
>>We can (and MUST) assert the negative as a standard track  requirement: if 
>>a responder receives a ENUM request without an OPT  pseudo-RR, it must not 
>>This is not a guide issue: this issue is normative, and must be  part of 
>>the standards track.
>>
>>
>>
>>>>>RRtypes if they indicate that they are DNSSEC- aware.  This is done by  
>>>would exceed the 512 byte limit. EDNS0 allows for a bigger  UDP  payload 
>>>which should eliminate truncated responses and TCP  retries.  This is a 
>>>VERY Good Thing: less latency for the client  and less load  on the name 
>>>servers.
>>>
>>>on. Or ENUM might want to rely on some still-to-be- invented DNS  feature 
>>>which uses them.
>>>
>>>

---

From: Jim Reid <[email-masked]>
Date: Tue, 20 Sep 2005 12:05:24 +0100

On Sep 20, 2005, at 11:10, Peter Williams wrote:

> The rationale for SHOULD might be that (a) ENUM wont work half the  
> time if non-EDNSO queries are sent

Nope! Most of the world's name servers support EDNS0 today. The few  
that don't -- BIND4, djbdns -- are supposed to return a FORMERR,  
SERVFAIL or NOTIMPL response if they get an ENDS0 query. The client  
then repeats the query in RFC1035-format. Which could of course lead  
to a truncated response => TCP retry.

ENUM will work just fine without EDNS0. However it won't work well.  
And without EDNS0, the load on ENUM name servers could be very, very  
nasty. Few operating systems have TCP/IP stacks that can cope with  
thousands (or many hundreds) of TCP connections per second: the  
typical query rate for a busy name server.

I think Section 6 of the draft is too vague. IMO the language &  
recommendations need to be tightened up to say:

[1] All name servers involved in ENUM -- authoritative and recursive  
resolvers -- MUST support EDNS0 and TCP queries.

This is a no-brainer as 90%+ of the world's name servers already do  
this. By making this requirement mandatory, it should hopefully stop  
the clueless from using broken or ancient DNS software for ENUM. That  
software probably wouldn't understand NAPTR records anyway. At the  
very least, a strong, clear recommendation here gives engineers  
something to point at when their management decides BIND4 would be a  
good platform for ENUM.

[2] ENUM clients -- name servers and stub resolvers -- MUST support  
EDNS0. EDNS0 queries SHOULD be the default for lookups unless the  
client knows for sure it's talking to a name server that violates [1]  
by not supporting EDNS0.

[3] ENUM clients SHOULD support TCP queries. Dropping TCP support  
would be inadvisable. But it might be OK in controlled environments:  
say handsets that can't accommodate TCP(?) but always use EDNS0 to  
talk to name servers that always support EDNS0.

---

From: Jim Reid <[email-masked]>
Date: Tue, 20 Sep 2005 12:36:16 +0100

> why it's in the guide - it's advisory).

My interpretation of what you're saying Lawrence is that EDNS0  
support is mandatory and that lookups SHOULD be done by EDNS0 unless  
the query is going to a server that doesn't speak EDNS0. Right?

> That would certainly be a standards track issue, and would IMHO be  

Indeed. EDNS0 was designed to be backwards compatible with the  
installed base. [In 1999, few name servers supported EDNS0. It's a  
very different story today.] If an EDNS0 query went to a server that  
didn't support EDNS0, it would return a "I don't understand this"  
response. The client would then repeat the query using RFC1035  
semantics and all would be well. Apart obviously from the latency of  
an extra query/response RTT.

---

From: Jim Reid <[email-masked]>
Date: Tue, 20 Sep 2005 12:58:54 +0100

On Sep 19, 2005, at 13:43, lconroy wrote:

> Typically, this means that the DNS stack sends EDNS0 with *every*  
> DNS query (not just ones looking for NAPTRs in an ENUM zone), but  
> YMMV with different stacks and APIs.
> client, I don't worry about interfacing with the underlying DNS  
> stack (just as well, as the APIs provided by DNS stacks on mobile  
> phones typically "are less than ideal" - gethostbyname and that's  
> about it for most of them).

Sigh. Yes, the DNS has lacked a decent API ever since it was  
invented. [The de facto API -- nearest thing to a standard -- is the  
set of 20 year-old res_mkquery() BSD library calls that usually lurk  
underneath the gethostby{name,addr}() interface.] New DNS stuff like  
Dynamic Update, EDNS0, TSIG, SIG(0), DNSSEC and NAPTR record  
processing make this problem even more acute. No wonder there's so  
much perl shimware to support these features.

There is a general recognition that there's a need for a  
comprehensive and up to date DNS API. Sadly nobody seems willing to  
pay for one to be developed. Or share the cost with like-minded  
companies. If you know of anyone who'd be willing to fund this work,  
I know of a neutral, non-profit organisation that would be delighted  
to produce that API and get it through X/Open and/or the ANSI C  
people. :-)

---

From: lconroy <[email-masked]>
Date: Tue, 20 Sep 2005 13:09:13 +0100

Hi Jim, folks,
On 20 Sep 2005, at 12:36, Jim Reid wrote:
> support is mandatory and that lookups SHOULD be done by EDNS0  
> unless the query is going to a server that doesn't speak EDNS0. Right?
We ADVISE that queries MUST use EDNS0 for good performance reasons  
(and/or sanity).

Will the protocol work if EDNS0 is NOT used? Generally, yes. That  
means that, from a Standards Track *protocol* perspective, there is  
no need for a MUST (but there is a "gotcha" if the infrastructure  
supports neither EDNS0 nor TCP and large RRSets are "published").
=> It is not a standards track mandate for the underlying DNS  
protocol and its implementations.

If the result of a probe is not implemented/serv fail/..., then the  
fallback procedure will work - it's just painful.

The implication is that, for performance reasons, we advise that  
Servers and Middleboxes MUST support EDNS0.
Again, the protocol still works if they don't, but they sure will  
p**s people off. They did me until I junked the box.

I also take this to mean that the *advice* is that one MUST try EDNS0  
first.
Anything else is going to be painfully slow.

Is this acceptable?

> very different story today.] If an EDNS0 query went to a server  
> that didn't support EDNS0, it would return a "I don't understand  
> this" response. The client would then repeat the query using  
> RFC1035 semantics and all would be well. Apart obviously from the  
> latency of an extra query/response RTT.
Absolutely agree - section 5.3 in rfc2671 spells out that one falls- 
back if the response indicates lack of support.

I assume that this would mean one then tries UDP, and if/when THAT  
comes back with TC=1, one finally tries TCP. In the situation where a  
server doesn't support EDNS0, then one is in for a long delay.
If the server/middlebox also doesn't support TCP, then one is in a  
heap of pain with large RRSets, but from the text of 1035 and 1123, I  
take that to mean that the configuration of the server/middlebox is  
broken.

all the best,
   Lawrence

---

From: lconroy <[email-masked]>
Date: Tue, 20 Sep 2005 13:18:10 +0100

Hi Jim, folks,
atEnd:
On 20 Sep 2005, at 12:58, Jim Reid wrote:
> invented. [The de facto API -- nearest thing to a standard -- is  
> the set of 20 year-old res_mkquery() BSD library calls that usually  
> lurk underneath the gethostby{name,addr}() interface.] New DNS  
> stuff like Dynamic Update, EDNS0, TSIG, SIG(0), DNSSEC and NAPTR  
> record processing make this problem even more acute. No wonder  
> there's so much perl shimware to support these features.
>
> companies. If you know of anyone who'd be willing to fund this  
> work, I know of a neutral, non-profit organisation that would be  
> delighted to produce that API and get it through X/Open and/or the  
> ANSI C people. :-)

res_mkquery? - you were lucky.
Don't forget Java and the J2ME standardisation process. It's no good  
if the devices out there don't have it,
and from my experience, this means every mobile phone. I would dearly  
love to be convinced otherwise, but...

all the best,
   Lawrence

---

From: Jim Reid <[email-masked]>
Date: Tue, 20 Sep 2005 13:49:40 +0100

> protocol and its implementations.

I disagree. The draft should mandate support for queries using EDNS0  
and TCP. And explain why. If it leaves enough wiggle room for people  
to deploy stuff that doesn't support these things, some will take the  
easy/lazy way out and deploy stuff that won't support them. This  
would be bad for everyone. We have a fair idea today that ENUM  
lookups are likely to generate jumbogram responses -- big NAPTR  
RRsets, DNSSEC, etc. So the WG should produce (mandatory)  
recommendations that will avoid the operational problems caused by  
too many truncated responses and TCP retries. It's better to get this  
nailed before there's substantial deployment because fixing it later  
is never going to succeed, especially for hand-held devices. In this  
context. MUSTs are preferable to SHOULDs.

> I also take this to mean that the *advice* is that one MUST try  
> EDNS0 first.

Yes. But IMO the draft doesn't state this clearly enough. I believe  
we're in violent agreement Lawrence. We seem to disagree on how to  
say that.