On 30/05/2010 19:31, bert hubert wrote:
On Thu, May 20, 2010 at 11:12:29AM +0100, Simon Bedford wrote:
This has happened a further twice in the last week, output sent off
list, please let me know if you need any further information.
Simon,
Could you apply this patch:
On Tue, Jun 08, 2010 at 05:33:26PM -0700, Gary Shaver wrote:
Before I pull much more hair out, I thought I'd toss this up to the list to
see if anyone has experienced this in the past (or has better google-foo
than I)
I'm slaving a zone from 208.78.69.112, I'm able to pull the zone
On 6/9/10 5:49 AM, Kenneth Marshall wrote:
another issue that I've run into was another slave zone. This had pdns
cycling every 2-3 seconds
Jun 7 00:48:44 ns1 pdns[10216]: Initiating transfer of 'axxxa.us' from
remote '216.117.186.93'
Jun 7 00:48:45 ns1 pdns[10216]: AXFR started for
Ah, I hit the same problem. WKS records are not supported by
PDNS. On top of that, they are not really useful and have not
been for quite a while. Try nuking them and your zone should
transfer fine.
Regards,
Ken
On Wed, Jun 09, 2010 at 11:43:27AM -0700, Gary Shaver wrote:
On 6/9/10 5:49 AM,
Hi Ken,
I just found your ticket from abut 4 years ago... Seems strange that
it's still a bug. We just ran a few tests and yep.. you were completely
correct, WKS records just piss off pdns something fierce.
I'll consolidate the test case down to something reasonable and submit a
bug
Garry,
2.6.1 WKS WKS records are deprecated in [RFC 1123]. They serve no known
useful function, except internally among LISP machines
Normally we'd whip up an implementation just to have the issue go away, but
it is a pretty weird record type too, containing a bitmap of protocols.
Unknown
Hi Bert,
I have a few that we've put on a bind server locally here. We were
providing secondary service for one domain that had WKS records (which
is how I ended up starting down this road).
Here are the WKS records that customer's nameserver was spitting out
towards us.
atlantica.us.
