Subject: [Enum] FYI - another topic for the experiences draft

From: "Conroy, Lawrence (SMTP)" <[email-masked]>
Date: Thu, 21 Oct 2004 12:26:12 -0400

Hi Folks,
  Now it has been processed/announced, I want to give everyone notice
about a topic we'll be adding to the update of the experiences draft
- the thorny issue of Authoritative DNS servers (also known, in some
circles, as T2 servers) and the *need* for TCP and EDNSO support.
In short, we believe that Authoritative servers for ENUM domains SHOULD
support EDNSO and SHOULD support TCP queries.
I an interested in the group's feeling on whether or not this SHOULD ->  
MUST,
for the specific case of ENUM
- it's a SHOULD in the basic specs, but is ENUM a special case where  
this
can be stronger?

- also, of course, TCP DNS queries SHOULD NOT be filtered by your  
friendly
I.T. Department, if the Authoritative servers are hosted by a Company,  
or else
name server support for TCP queries is pointless - I find a baseball  
bat helps.
(From experience, firewall config is the biggest nuisance, and real fun  
to debug).

My esteemed co-author Fujiwara-san has a draft that details this issue,  
so please
look at this - it is concerned with large RRsets, and even without  
DNSSEC, we are
likely to have those in the real world in ENUM (a couple of Austrian  
zones come
to mind :).

see  
<http://www.ietf.org/internet-drafts/draft-fujiwara-dnsop-bad-dns-auth 
-00.txt>

all the best,
  Lawrence
_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum

---

From: Adrian Georgescu <[email-masked]>
Date: Thu, 21 Oct 2004 14:33:22 -0400

Next to PTR examples given, 4-5 NAPTR records can already fill up the  
maximum packet size via UDP. TCP is a valid transport option but some  
performance requirements I have seen demanded from ENUM servers must be  
reviewed and the providers must take provision to be able to take the  
load of more expensive TCP connections, it has the same impact of  
operating a SIP server on TCP, performance decreases dramatically. I am  
wondering if anyone knows the performance ratio of UDP/TCP transport on  
a DNS server.

On Oct 21, 2004, at 6:16 PM, Conroy, Lawrence (SMTP) wrote:
Hi Folks,
I an interested in the group's feeling on whether or not this SHOULD  
-> MUST,

- also, of course, TCP DNS queries SHOULD NOT be filtered by your  
friendly
I.T. Department, if the Authoritative servers are hosted by a Company,  
or else
name server support for TCP queries is pointless - I find a baseball  
bat helps.
(From experience, firewall config is the biggest nuisance, and real  
fun to debug).

My esteemed co-author Fujiwara-san has a draft that details this  
issue, so please
look at this - it is concerned with large RRsets, and even without  
DNSSEC, we are
likely to have those in the real world in ENUM (a couple of Austrian  
zones come
to mind :).

see  
<http://www.ietf.org/internet-drafts/draft-fujiwara-dnsop-bad-dns- 
auth-00.txt>

all the best,
  Lawrence

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 21 Oct 2004 15:18:58 -0400

On Oct 21, 2004, at 18:16, Conroy, Lawrence (SMTP) wrote:
Hi Folks,
  Now it has been processed/announced, I want to give everyone notice
about a topic we'll be adding to the update of the experiences draft
- the thorny issue of Authoritative DNS servers (also known, in some
circles, as T2 servers) and the *need* for TCP and EDNSO support.
In short, we believe that Authoritative servers for ENUM domains SHOULD
support EDNSO and SHOULD support TCP queries.
Well, DNS servers MUST support TCP and SHOULD support EDNS0. The latter  
because packet size might be larger than 512 bytes, and for use of  
DNSSEC use of EDNS0 is a MUST.

For these reasons I am nervous the ENUM wg working on these DNS  
deployment issues. This is a DNSOP issue, and the question -- if it has  
to be answered -- should be passed over the fence.

Maybe it is the case that we (ENUM people) have discovered there is no  
"BCP on DNS deployment", and that is something we should ask DNS people  
to create? Or at least look at what we have?

The baseball bat issue below, I agree with ;-)
    paf
I an interested in the group's feeling on whether or not this SHOULD  
-> MUST,
for the specific case of ENUM
- it's a SHOULD in the basic specs, but is ENUM a special case where  
this
can be stronger?

see  

all the best,
  Lawrence

---

From: "Conroy, Lawrence (SMTP)" <[email-masked]>
Date: Thu, 21 Oct 2004 18:06:59 -0400

Hi Patrik, folks,
 Sorry if I was unclear.
I'm very happy with MUST for Authoritative Name Server TCP support,
and a SHOULD for EDNSO (at least "before DNSSEC").
I'm glad it's not just me  - I'm also unaware of a BCP for DNS  
Deployment.
That is NOT the job of the ENUM experiences draft - Fujiwara-san's draft
*is* intended for the dnsop WG.

As this will "bite" for ENUM deployments, I suggest ONLY that we  
highlight
that folk need to set their servers (and clients) correctly, as  
otherwise
they will have problems.
Summarising the "rules" and the kind of problems they will have if they
(or their I.T. department) don't do the right thing seems to me  
appropriate
for an ENUM doc.
For the gory details we will have a reference to Fujiwara-san's dnsop  
draft
precisely as that's where it is treated (please, please, please not in  
ENUM).

Unless I get some strong objections before the weekend I'll add it to  
the updated
experiences (-01) draft and with luck, this will be accepted by the  
deadline.

all the best,
  Lawrence
On 21 Oct 2004, at 20:07, Patrik Fältström wrote:
On Oct 21, 2004, at 18:16, Conroy, Lawrence (SMTP) wrote:
Hi Folks,
  Now it has been processed/announced, I want to give everyone notice
about a topic we'll be adding to the update of the experiences draft
- the thorny issue of Authoritative DNS servers (also known, in some
circles, as T2 servers) and the *need* for TCP and EDNSO support.
In short, we believe that Authoritative servers for ENUM domains  
SHOULD
support EDNSO and SHOULD support TCP queries.
Well, DNS servers MUST support TCP and SHOULD support EDNS0. The  
latter because packet size might be larger than 512 bytes, and for use  
of DNSSEC use of EDNS0 is a MUST.

For these reasons I am nervous the ENUM wg working on these DNS  
deployment issues. This is a DNSOP issue, and the question -- if it  
has to be answered -- should be passed over the fence.

Maybe it is the case that we (ENUM people) have discovered there is no  
"BCP on DNS deployment", and that is something we should ask DNS  
people to create? Or at least look at what we have?

- also, of course, TCP DNS queries SHOULD NOT be filtered by your  
friendly
I.T. Department, if the Authoritative servers are hosted by a  
Company, or else
name server support for TCP queries is pointless - I find a baseball  
bat helps.
(From experience, firewall config is the biggest nuisance, and real  
fun to debug).

see  

all the best,
  Lawrence

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 21 Oct 2004 18:11:24 -0400

On Oct 21, 2004, at 21:52, Conroy, Lawrence (SMTP) wrote:
Please do!

---

From: Adrian Georgescu <[email-masked]>
Date: Fri, 22 Oct 2004 03:39:54 -0400

There is a discrepancy between previous document and  ETSI TS 102 172 
recommendation regarding the default value of naptr order field. Could 
a unique value be agreed upon?

ETSI doc (order=10)
Conroy experiences draft (order=100)
Adrian
On Oct 21, 2004, at 10:19 PM, Patrik Fältström wrote:
On Oct 21, 2004, at 21:52, Conroy, Lawrence (SMTP) wrote:
Unless I get some strong objections before the weekend I'll add it to 
the updated
experiences (-01) draft and with luck, this will be accepted by the 
deadline.
Please do!
   paf
_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum

---

From: Jim Reid <[email-masked]>
Date: Fri, 22 Oct 2004 06:59:06 -0400

>>>>> "lwc" == Conroy, Lawrence (SMTP) <lwc at roke.co.uk> writes:

    lwc> Hi Folks, Now it has been processed/announced, I want to give
    lwc> everyone notice about a topic we'll be adding to the update
    lwc> of the experiences draft - the thorny issue of Authoritative
    lwc> DNS servers (also known, in some circles, as T2 servers) and
    lwc> the *need* for TCP and EDNSO support.

    lwc> In short, we believe that Authoritative servers for ENUM
    lwc> domains SHOULD support EDNSO and SHOULD support TCP queries.

    lwc> I an interested in the group's feeling on whether or not this
    lwc> SHOULD -> MUST, for the specific case of ENUM - it's a SHOULD
    lwc> in the basic specs, but is ENUM a special case where this can
    lwc> be stronger?

Support for EDNS0 should be a MUST. Here's some suggested text to
explain why.

Responses to ENUM lookups are likely to contain many NAPTR records and
could well exceed the 512-byte payload limit on UDP responses defined
in RFC1035. If these replies are also signed using Secure DNS, they
will be considerably larger than 512 bytes. When this limit is
exceeded, the server truncates the response and sets the TC bit in the
reply. The client then repeats the query using TCP so that all the
data can be obtained. This is undesirable for two reasons. Firstly,
there is the overhead and additional latency of creating a TCP
connection and repeating the query. Those delays are not conducive to
environments like ENUM where high query throughput is necessary. The
second reason is large numbers of TCP queries can place undue load on
the server's operating system because it may have to maintain state
information for many hundreds or thousands of short-lived TCP
connections.

When a resolver uses EDNS0, it can inform the name server that it is
able to receive more than 512 bytes in a UDP response. Therefore ENUM
clients SHOULD use EDNS0 when making queries to avoid the potential
delays and undesirable overheads caused by truncated responses
followed by repeated queries over TCP. Clients making queries with
EDNS0 should indicate that they can accept appropriately large enough
UDP responses: perhaps as much as 4096 bytes. Authoritative name
servers for ENUM zones MUST support EDNS0.

BTW, stating that name servers SHOULD support TCP is a bit like saying
they SHOULD support RFC1035. :-)

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 22 Oct 2004 07:33:53 -0400

On Oct 22, 2004, at 09:34, Adrian Georgescu wrote:
There is a discrepancy between previous document and  ETSI TS 102 172 
recommendation regarding the default value of naptr order field. Could 
a unique value be agreed upon?

ETSI doc (order=10)
Conroy experiences draft (order=100)
The order value has no meaning, so there is no need for a default value.
I.e. why do you ask?
    paf
Adrian
On Oct 21, 2004, at 10:19 PM, Patrik Fältström wrote:
On Oct 21, 2004, at 21:52, Conroy, Lawrence (SMTP) wrote:
Unless I get some strong objections before the weekend I'll add it 
to the updated
experiences (-01) draft and with luck, this will be accepted by the 
deadline.
Please do!
   paf
_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 22 Oct 2004 07:33:54 -0400

On Oct 22, 2004, at 12:55, Jim Reid wrote:
Support for EDNS0 should be a MUST. Here's some suggested text to
explain why.
I don't see how we can say MUST on EDNS0 if not all nameservers 
(including all recursive resolvers) do support it.

I do see the need for a MUST regarding TCP, because that is what is in 
1034/1035, but EDNS0?

Has the DNSOP wg decided support of EDNS0 is a MUST for DNS?
We all know EDNS0 is a MUST if the packet size is larger than 512 
bytes, and the truncated data is something that "is needed" (whatever 
that is, it is still to be defined), but...

    paf

---

From: "Conroy, Lawrence (SMTP)" <[email-masked]>
Date: Fri, 22 Oct 2004 08:21:16 -0400

Hi Patrik, folks,
It can be hard to decode RFC3403 and RFC3761 section 1.3, so I'm in 
favour of giving people a hint
in plain text that "The order value has no meaning" :).
Telling everyone to use the same ORDER field value within a given zone 
is a good solution.
It's also true that using a different ORDER field value in different 
zones is unimportant for
most queries.
However...
If anyone really wants the joy of implementing non-final NAPTRs, then 
they MAY be confused by section
1.3 - if there's a different (lower) order field value in a zone 
referred to by a non-final, then
does this mean that one discards the other NAPTRs in the referring 
zone. Conversely, if the zone
referred to by a non-final NAPTR contains entries that have a higher 
ORDER field value, then does one
ignore those?

My guess is that one just "forgets to consider" the order field value 
in NAPTRs that are scanned as
the result of a non-final NAPTR zone reference, and that's what we 
propose in the experiences draft.
It's possible to interpret RFC3761 ss 1.3 differently, which means that 
someone somewhere has/is/will
read/is reading/will read it that way.

Thus using the same ORDER field value for ALL zones is "a good idea" - 
it avoids arguments over
the meaning of 3403 and 3761 ss 1.3, so removing the need for a 
philosophy higher degree before
implementing this stuff.

The short answer is "I vote we propose 100", for those obscure corner 
cases where it matters.

all the best,
  Lawrence
On 22 Oct 2004, at 12:28, Patrik Fältström wrote:
On Oct 22, 2004, at 09:34, Adrian Georgescu wrote:
There is a discrepancy between previous document and  ETSI TS 102 172 
recommendation regarding the default value of naptr order field. 
Could a unique value be agreed upon?

ETSI doc (order=10)
Conroy experiences draft (order=100)
The order value has no meaning, so there is no need for a default 
value.

I.e. why do you ask?
    paf
Adrian

---

From: Jim Reid <[email-masked]>
Date: Sun, 24 Oct 2004 11:34:48 -0400

>>>>> "paf" == =?ISO-8859-1?Q?Patrik F=E4ltstr=F6m?= <ISO-8859-1> writes:

    >> Support for EDNS0 should be a MUST. Here's some suggested text
    >> to explain why.

    paf> I don't see how we can say MUST on EDNS0 if not all
    paf> nameservers (including all recursive resolvers) do support it.

By that argument, we shouldn't use NAPTR records either because not
all DNS software supports them. ENUM was first documented in RFC2916
which came out in Sept 2000. EDNS0 predates it. RFC2671 was published
in Aug 1999. So the chances are that a DNS implementation which
doesn't support EDNS0 won't support NAPTR records either.

    paf> I do see the need for a MUST regarding TCP, because that is
    paf> what is in 1034/1035, but EDNS0?

I would say EDNS0 is much more important than TCP for ENUM queries.
Making TCP a MUST and not EDNS0 will send out the wrong message: ie
that truncated responses and TCP retries are preferable to jumbogram
UDP replies. This is very bad. It even worse because we already know
that ENUM replies are likely to be bigger than 512 bytes even if
they're not signed. So we should be taking protective measures like
demanding the use of EDNS0 now to avoid the evils of truncated
responses before these become a crippling operational problem.

    paf> Has the DNSOP wg decided support of EDNS0 is a MUST for DNS?

Dunno.

    paf> We all know EDNS0 is a MUST if the packet size is larger than
    paf> 512 bytes, and the truncated data is something that "is
    paf> needed" (whatever that is, it is still to be defined), but...

This seems to contradict what you just said. (ie Support for EDNS0
should be a SHOULD.) Real-world ENUM replies are almost certainly
going to always exceed 512 bytes. So mandating EDNS0 now will save us
a whole world of pain later. It'll be too late to make EDNS0 mandatory
when everyone's ENUM name servers are dying because they are having to
keep state about zillions of short-lived TCP connections caused by
loadsaqueries that result in truncated responses.

Since ENUM doesn't have much of an installed base yet, there shouldn't
be a problem mandating that ENUM-aware applications support reasonably
current DNS protocol features. There isn't an army of BIND4 servers
hosting zones under e164.arpa or legacy applications that have to be
considered. After all RFC3761 says software that implements ENUM MUST
be prepared to handle standard signed responses. It even goes on to
say they MUST be prepared to receive large responses, EDNS0 signaling,
unknown RRs, etc. [Last para of 6.1] I read this as implying EDNS0 is
already mandatory.

As a compromise I could live with a doc for ENUM that said:

stub resolvers SHOULD use EDNS0

resolving name servers MUST use EDNS0 for lookups in e164.arpa

authoritative name servers MUST support EDNS0

TCP lookups under e164.arpa are strongly discouraged

---

From: "Conroy, Lawrence (SMTP)" <[email-masked]>
Date: Sun, 24 Oct 2004 12:09:39 -0400

Hi Jim, folks,
  OK - I wasn't going to mention this,
    it isn't (and won't be) spelt out in the experiences draft I'm 
updating,
    and most importantly, IT'S OFF TOPIC for ENUM WG,
  but...

AFAIK, EDNS0 only helps if the MTU is more than 512 octets
  (see the comment at the end of 2671 on ICMP storms for a hint).
You can't guarantee that this is the case in all access networks.
===>>>
Thus EDNS0 may not be the "Great White Hope" that folk assume it to be.
<<<===
TCP queries do work.
RFC1123 makes them a SHOULD for DNS servers.
=> That's what's going into the experiences update, only as a hint,
   as experiences is an INFORMATIONAL document.
   The Masters are still the DNSOPS docs.
(BTW, RFC1123 also says that Clients SHOULD discard any partial 
response they receive,
 and RFC1035 makes TCP a MUST for AXFR, as UDP is excluded).

With that, I leave you so I can get the fr*gg*n XML version sorted.
all the best,
  Lawrence
On 24 Oct 2004, at 16:31, Jim Reid wrote:
"paf" == =?ISO-8859-1?Q?Patrik F=E4ltstr=F6m?= <ISO-8859-1> 
writes:

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 24 Oct 2004 13:37:47 -0400

On Oct 24, 2004, at 17:31, Jim Reid wrote:
"paf" == =?ISO-8859-1?Q?Patrik F=E4ltstr=F6m?= <ISO-8859-1> 
writes:

My point is that a MUST is very very strong, and I ask whether 
requiring EDNS0 will make too many ENUM-capable nameservers no longer 
correct?

UDP replies.
TCP is already a MUST according to the DNS protocol, something EDNS0 is 
not.

This is very bad. It even worse because we already know
that ENUM replies are likely to be bigger than 512 bytes even if
they're not signed. So we should be taking protective measures like
demanding the use of EDNS0 now to avoid the evils of truncated
responses before these become a crippling operational problem.
    paf> Has the DNSOP wg decided support of EDNS0 is a MUST for DNS?
Dunno.
Very important if they are.
    paf> We all know EDNS0 is a MUST if the packet size is larger than
    paf> 512 bytes, and the truncated data is something that "is
    paf> needed" (whatever that is, it is still to be defined), but...
This seems to contradict what you just said. (ie Support for EDNS0
should be a SHOULD.) Real-world ENUM replies are almost certainly
going to always exceed 512 bytes.
No, they are not. My NAPTR things are not larger than 512.
I did not contradict what I said. Read what I wrote. I said EDNS0 is 
needed if the response is larger than 512 bytes.

So mandating EDNS0 now will save us
a whole world of pain later. It'll be too late to make EDNS0 mandatory
when everyone's ENUM name servers are dying because they are having to
keep state about zillions of short-lived TCP connections caused by
loadsaqueries that result in truncated responses.
I want the DNSOP wg to state requirements on the DNS protocol. Not the 
ENUM wg.

Since ENUM doesn't have much of an installed base yet, there shouldn't
be a problem mandating that ENUM-aware applications support reasonably
current DNS protocol features.
That's not what we are discussing here. The question is whether EDNS0 
is a MUST requirement for any DNS server holding NAPTR records for 
ENUM. I said that is a too strong requirement.

There isn't an army of BIND4 servers
hosting zones under e164.arpa or legacy applications that have to be
considered. After all RFC3761 says software that implements ENUM MUST
be prepared to handle standard signed responses. It even goes on to
say they MUST be prepared to receive large responses, EDNS0 signaling,
unknown RRs, etc. [Last para of 6.1] I read this as implying EDNS0 is
already mandatory.
No, the paragraph says:
   Finally, as an ENUM service will be implementing some type of
   security mechanism, software which implements ENUM MUST be prepared
   to receive DNSSEC and other standardized DNS security responses,
   including large responses, EDNS0 signaling, unknown RRs, etc.
This is something completely different than requiring that a DNS server 
MUST implement it. It doesn't even say the ENUM service implementation 
MUST be able to understand DNSSEC signed responses. Only that it is 
prepared on getting such responses.

Don't compare apples and pears.
As a compromise I could live with a doc for ENUM that said:
stub resolvers SHOULD use EDNS0
This is a DNSOP requirement.
resolving name servers MUST use EDNS0 for lookups in e164.arpa
This is a DNSOP requirement.
authoritative name servers MUST support EDNS0
This is a DNSOP requirement.
TCP lookups under e164.arpa are strongly discouraged
I strongly oppose this.
You are doing massive layering violations here Jim.
    paf
_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum

---

From: Andrew Newton <[email-masked]>
Date: Tue, 26 Oct 2004 17:44:20 -0400

On Oct 24, 2004, at 12:08 PM, Conroy, Lawrence (SMTP) wrote:
AFAIK, EDNS0 only helps if the MTU is more than 512 octets
  (see the comment at the end of 2671 on ICMP storms for a hint).
You can't guarantee that this is the case in all access networks.
True, but pragmatically speaking won't almost anybody doing voip be 
connected in such a way to allow higher PMTUs anyway?

-andy

---

From: "Samia M'timet" <[email-masked]>
Date: Fri, 29 Oct 2004 01:49:28 -0400

On Fri, 22 Oct 2004 11:55:42 +0100
Jim Reid <jim at rfc1035.com> wrote:

> will be considerably larger than 512 bytes.

I think there's a real need of documentation to explain what is the difference between "Secure DNS" and "walled garden". There's a lot of confusing words in this field.

-- 
Samia M'timet				
AFNIC