[Asterisk-Dev] recent ENUM buffer mods

[Olle E. Johansson]

lconroy wrote:
> 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.

Thanks for your input! The \000 delimiter seems evil...

/O