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

From: "Klaus Darilion" <[email-masked]>
Date: Fri, 22 Oct 2004 11:30:44 -0400

Hi!

I'm glad that you discuss this topic as this is really a big problem in
the ENUM world. If someone wants to benefit from enum and configures all
the nice services (fax, voice, http, sms, mms,..), the 512 bytes limit
is reached easily. Therefore, at least one method (TCP or EDNS0) must be
supported for ENUM. As Jim said EDNSO will benefit from smaller
overhead.

But the main problem is not the standard ('should' or 'must'), but the
administrators of the name servers (authoritive and chaching servers). I
don't know if TCP is a should or a must, but there are definitely a lot
of name servers configured to block TCP.

Anyway, using resolvers which are capable of both (EDNS0 and TCP) will
increase the chance to get all NAPTRs for a domain.

regards,
klaus

> -----Original Message-----
> From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On 
> Behalf Of Conroy, Lawrence (SMTP)
> Sent: Thursday, October 21, 2004 6:16 PM
> To: 'enum at ietf.org'
> Cc: fujiwara at jprs.co.jp
> Subject: [Enum] FYI - another topic for the experiences draft
> 
> 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
> 
> 
> 
> 

_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum

---

From: Peter Koch <[email-masked]>
Date: Fri, 22 Oct 2004 12:41:00 -0400

> supported for ENUM. As Jim said EDNSO will benefit from smaller

yes, but requiring this in the enum spec is kind of a layer violation.
As Patrik already explained: you cannot control all the intermediate
nameservers ('recursive servers', 'forwarders'). And, it's not the client
that has to support EDNS0 but the resolver it uses.

> of name servers configured to block TCP.

There are firewalls which let tcp/53 pass out but not back in. SYN succeeds,
SYN/ACK gets dropped. Nice DoS, expect to suffer.

> increase the chance to get all NAPTRs for a domain.

TCP could turn out to be a performance problem (although this is currently
discussed on namedroppers).

-Peter