[Asterisk-Dev] recent ENUM buffer mods

[lconroy]

Hi Folks,
  I note the patch that has gone in to extend the buffer sizes for  
ENUM lookup.
To clarify quite what the limits are...

The fields of a NAPTR rrData are 16 bit integers, strings, and an  
uncompressed domain name.
In DNS, a dns-string has a maximum length of 255 bytes (as it starts  
with a single unsigned byte as the "length" count). Thus, when  
manipulating strings, this is the maximum length the input dns-string  
CAN be.

 From extensive study, you are VERY unlikely to come across multi- 
byte characters any time soon, so make that a maximum of 255 characters.

The flags and service fields are no problem, and even the replacement  
field is no problem (as domain names have the same maxiumum length).

The only "gotcha" is that the RegExp field is used to generate a URI  
from the static text and the matched sub-patterns of the passed  
telephone number. Thus, this one could, in theory, be longer, if for  
some reason the input telephone number (maximum of 15 digits) was  
duplicated in the "replacement" bit a number of times. Thus the  
static output buffer for the RegExp should be very long, to avoid  
nasty attacks like putting in a Regexp of "!\+(^.)$!sip:\1\1\1\1\1\1\1 
\1\1\1\1\1\1\1\1\1\1\1\1\1\1A@\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1 
\1.example.com.!"
and watching things fall over.

(No, I don't have such nasty NAPTRs published, but some tw*t will try  
it).

Whilst we're on the subject, remember that we don't need to use '!'  
as a delimiter - \000 is perfectly valid according to the standards.  
Now let's see your C-string processing deal with that.

all the best,
   Lawrence
[co-author of draft-ietf-experiences-02.txt with my esteemed co- 
author Fujiwara-san]