Bert, list,
Utmost apologies for all the noise - I'm deeply disappointed with my
testing methodology, and my assertions are in error. Having examined
the packet contents I see that pdns is actually sending correctly
formatted information on the wire, however `host` helpfully re-escapes
the re
Peter Fern wrote:
Hi Bert,
bert hubert wrote:
Can you try doubling the \, so:
100 0 "u" "E2U+sip" "!^\\+([0-9][0-9][0-9])$!sip:[EMAIL PROTECTED]" .
As I thought - the slashes are returned verbatim when doubled, and
cause the parser to barf when there is only one:
OK, this is killing me
Peter Fern wrote:
> What version are you running? The problem that sparked this thread is
> that <2.9.21 bind backend doesn't handle NAPTR, and =2.9.21 includes the
> MOADNSParser, which doesn't handle backslashes correctly for at least
> gmysql (I assume for every backend).
We've used from 2.9.
Duane wrote:
I've never had a problem with \+ in PDNS...
What version are you running? The problem that sparked this thread is
that <2.9.21 bind backend doesn't handle NAPTR, and =2.9.21 includes the
MOADNSParser, which doesn't handle backslashes correctly for at least
gmysql (I assume f
Peter Fern wrote:
> Correct, however we often have a requirement to match a substring and
> sub it into another pattern to translate one number range to another,
> hence the requirement for regex. And regardless - it's currently
> impossible to escape characters like '+' since the backslashes are
Duane wrote:
Peter Fern wrote:
All I'm trying to do is get PDNS to return a record verbatim from the
backend (actually, I've just reviewed the RFC, which says a
double-backslash in the zone must return a single in the response).
Simply matching '\\' and returning '\' is a low-cost operation
Peter Fern wrote:
> All I'm trying to do is get PDNS to return a record verbatim from the
> backend (actually, I've just reviewed the RFC, which says a
> double-backslash in the zone must return a single in the response).
> Simply matching '\\' and returning '\' is a low-cost operation, and
> req
Duane wrote:
Peter Fern wrote:
Duane wrote:
It's pointless trying to expand regular expressions from within the DNS
server, either it will increase load unnecessarily or the regular
expressions were designed to be expanded by a client requesting the
information.
I'm aware tha
Peter Fern wrote:
> Duane wrote:
>> It's pointless trying to expand regular expressions from within the DNS
>> server, either it will increase load unnecessarily or the regular
>> expressions were designed to be expanded by a client requesting the
>> information.
>>
>
> I'm aware that parsing o
Duane wrote:
It's pointless trying to expand regular expressions from within the DNS
server, either it will increase load unnecessarily or the regular
expressions were designed to be expanded by a client requesting the
information.
I'm aware that parsing of the regex is meant to be done clie
Peter Fern wrote:
> Duane wrote:
>> Peter Fern wrote:
>>
>>> Can anyone point me to roughly where I should be looking in the codebase
>>> to patch this out? I imagine somewhere in this new universal parser? I
>>> assume it will only be a couple of lines to fix, but I don't have the
>>> spare he
Duane wrote:
Peter Fern wrote:
Can anyone point me to roughly where I should be looking in the codebase
to patch this out? I imagine somewhere in this new universal parser? I
assume it will only be a couple of lines to fix, but I don't have the
spare headspace right now to come to grips wit
Peter Fern wrote:
> Can anyone point me to roughly where I should be looking in the codebase
> to patch this out? I imagine somewhere in this new universal parser? I
> assume it will only be a couple of lines to fix, but I don't have the
> spare headspace right now to come to grips with another c
Can anyone point me to roughly where I should be looking in the codebase
to patch this out? I imagine somewhere in this new universal parser? I
assume it will only be a couple of lines to fix, but I don't have the
spare headspace right now to come to grips with another codebase
completely - a
Hi Bert,
bert hubert wrote:
Can you try doubling the \, so:
100 0 "u" "E2U+sip" "!^\\+([0-9][0-9][0-9])$!sip:[EMAIL PROTECTED]" .
As I thought - the slashes are returned verbatim when doubled, and cause
the parser to barf when there is only one:
Here is the result with a single '\':
mysq
bert hubert wrote:
On Tue, Jul 29, 2008 at 05:08:26PM +1000, Peter Fern wrote:
No one else is serving NAPTR E2U expressions from PowerDNS?
Peter,
Sorry for the late replay. In fact, quite a number of people are doing such
things with PowerDNS.
No problem Bert, thank you for the r
On Tue, Jul 29, 2008 at 05:08:26PM +1000, Peter Fern wrote:
> No one else is serving NAPTR E2U expressions from PowerDNS?
Peter,
Sorry for the late replay. In fact, quite a number of people are doing such
things with PowerDNS.
Can you try doubling the \, so:
100 0 "u" "E2U+sip" "!^\\+([0-9][0-9
No one else is serving NAPTR E2U expressions from PowerDNS?
Peter Fern wrote:
Hello list,
I am attempting to serve NAPTR records with E2U regular expressions,
requiring escaping of characters by employing a '\', eg:
100 0 "u" "E2U+sip" "!^\+([0-9][0-9][0-9])$!sip:[EMAIL PROTECTED]" .
I'm runni
Hello list,
I am attempting to serve NAPTR records with E2U regular expressions,
requiring escaping of characters by employing a '\', eg:
100 0 "u" "E2U+sip" "!^\+([0-9][0-9][0-9])$!sip:[EMAIL PROTECTED]" .
I'm running a master/slave setup, with a gmysql backend master, and bind
backend slaves,
19 matches
Mail list logo
