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.
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
manually using dig, but it does go a little slower than I would