That would have been me testing transfers from the new server and not
setting the source ip properly. The master server is 184.23.168.134.
That instance controls the backend that the [a-c].auth-ns.sonic.net
servers use, so it is the only one you need to notify.

On 05/02/2017 12:01 PM, Dave Jones wrote:
>
>
> On 05/02/2017 11:56 AM, Grant Keller wrote:
>> Kevin,
>>
>> The information located here:
>> https://wiki.sonic.net/wiki/Secondary_DNS_Service is the current
>> configuration information you will need.
>
> Grant,
> The wiki documentation refers to .134 that I already had in the
> PowerDNS configs since Sunday.  My logs show the IP coming from .37 so
> I have added that IP to both be notified and allow axfrs.
>
> May 02 09:50:14 sa-vm1 pdns_server[20755]: May 02 09:50:14 AXFR of
> domain 'spamassassin.org' initiated by 184.23.168.37
> May 02 09:50:14 sa-vm1 pdns_server[20755]: May 02 09:50:14 AXFR of
> domain 'spamassassin.org' denied: client IP 184.23.168.37 has no
> permission
> May 02 09:50:14 sa-vm1 pdns_server[20755]: May 02 09:50:14 AXFR of
> domain 'spamassassin.org' failed: 184.23.168.37 cannot request AXFR
>
> I am using PowerDNS with a specific list for notifies and allowed
> axfrs.  Please let me know all of the IPs I should be notifying and
> allowing zone transfers.  It appears based on the logs above that I
> don't need .134 in my configs.
>
> Is .37 acting as a hidden slave for spamassassin.org plus a master to
> [abc].auth-ns.sonic.net?
>
>
> Dave
>
>>
>> On 05/02/2017 05:32 AM, Kevin A. McGrail wrote:
>>> Gents, I appreciate your patience and I'm cc'ing a new list for SA
>>> sysadmins so there can be better documentation with a higher bus
>>> factor.  If you are ok with your emails being known, that would be
>>> cool if you replied back to the list.
>>>
>>> Please point your public slaves at 62.210.60.231 as their master,
>>> allowing notifies/transfers/beers to flow freely.
>>>
>>> Grant, can you confirm which IPs we should notify? We have some
>>> discrepancies but perhaps you had some slaving internally occurring
>>> however there were small discrepancies on the records.
>>>
>>> Brian, we'll check when you turn things back on but it appears you
>>> were missing a test DKIM record oddly enough.  Perhaps a record
>>> length  limit or something.
>>>
>>> Best,
>>> KAM
>>>
>>
>

-- 
Grant Keller
System Operations
[email protected]

Reply via email to