[Pdns-users] Need help re: Remote tried to sneak in out-of-zone data ''|SOA during AXFR of zone

Chris Moody chris at node-nine.com
Tue Feb 18 22:11:45 UTC 2014


Sorry - my mistake again re: multiple SOA - RFC 1034, page 28/29.

Still stumped about what would be causing the 'Remote 206.71.169.116 
tried to sneak in out-of-zone data ''|SOA during AXFR of zone 
'mysitehealth.com', ignoring' failure.

The supermaster auto-provision bit worked as the slave shows the domain 
in the domains table.  Just won't actually axfr the records.

-Chris

On 2/18/14 4:51 PM, Chris Moody wrote:
> Replies inline.
>
> On 2/18/14 2:56 PM, Aki Tuomi wrote:
>> On Tue, Feb 18, 2014 at 02:47:33PM -0500, Chris Moody wrote:
>>> Could all this perhaps be related to using opendbx as the backend?
>>>
>>> =====
>>> Feb 18 19:25:22 nyny-dp-1 pdns[7979]: Received NOTIFY for
>>> mysitehealth.com from 206.71.169.116 for which we are not
>>> authoritative
>>> Feb 18 19:25:23 nyny-dp-1 pdns[7979]: Unable to find backend willing
>>> to host mysitehealth.com for potential supermaster 206.71.169.116. 4
>>> remote nameservers:
>>> =====
>>>
>> This issue is due to misconfiguration for supermasters. The 
>> supermasters table
>> must have matching hostname and ip address in it. It has to match 
>> ns1.mysitehealth.com and 206.71.169.116.
>
> Face palm - my mistake on this bit.  When I dropped the table I forgot 
> to re-add the supermaster records.  They're back and again reporting 
> the AXFR issue.
>
>>> Here's the brand new zone that's got the same issue.
>>> =====
>>> mysql> SELECT * FROM records WHERE domain_id = 635;
>>> +-------+-----------+----------------------+------+-------+------+----------------------------------------------------------------------------+-----------+------+----------+ 
>>>
>>> | id    | domain_id | name                 | type | ttl   | prio |
>>> content | ordername | auth | disabled |
>>> +-------+-----------+----------------------+------+-------+------+----------------------------------------------------------------------------+-----------+------+----------+ 
>>>
>>> | 35276 |       635 | mysitehealth.com     | SOA  | 86400 | NULL |
>>> ns1.mysitehealth.com. postmaster at mysitehealth.com 0 10800 3600
>>> 604800 3600 | NULL      | NULL |     NULL |
>>> | 35277 |       635 | ns1.mysitehealth.com | A    |   120 | NULL |
>>> 206.71.169.116 | NULL      | NULL |     NULL |
>>> | 35278 |       635 | ns2.mysitehealth.com | A    |   120 | NULL |
>>> 64.106.186.196 | NULL      | NULL |     NULL |
>>> | 35279 |       635 | mysitehealth.com     | NS   |   120 | NULL |
>>> ns1.mysitehealth.com | NULL      | NULL |     NULL |
>>> | 35280 |       635 | mysitehealth.com     | NS   |   120 | NULL |
>>> ns2.mysitehealth.com | NULL      | NULL |     NULL |
>>> | 35282 |       635 | mysitehealth.com     | MX   |   120 | 10 |
>>> mx1.node-nine.com | NULL      | NULL |     NULL |
>>> +-------+-----------+----------------------+------+-------+------+----------------------------------------------------------------------------+-----------+------+----------+ 
>>>
>>> 6 rows in set (0.00 sec)
>>>
>>> mysql>
>>> =====
>>>
>> Can you try dig axfr mysitehealth.com @localhost (if you have axfr 
>> from localhost permitted)
>>
>> Please check master logs as well
> So this is strange - I -do- see duplicate SOA records in the axfr but 
> not in the master's DB.
>
> ex>
> =====[ master ]=====
> mysql> SELECT * FROM records WHERE name = "." OR name = "";
> Empty set (0.00 sec)
> =====
>
> =====[ dig axfr @ master ]=====
> root at nyny-dp-1 ~ # dig @206.71.169.116 mysitehealth.com axfr
>
> ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 <<>> @206.71.169.116 
> mysitehealth.com axfr
> ; (1 server found)
> ;; global options: +cmd
> .            86400    IN    SOA    ns1.mysitehealth.com. 
> postmaster.mysitehealth.com. 61 10800 3600 604800 3600
> ns1.mysitehealth.com.    120    IN    A    206.71.169.116
> ns2.mysitehealth.com.    120    IN    A    64.106.186.196
> mysitehealth.com.    120    IN    NS ns1.mysitehealth.com.
> mysitehealth.com.    120    IN    NS ns2.mysitehealth.com.
> mysitehealth.com.    120    IN    MX    10 mx1.mysitehealth.com.
> mx1.mysitehealth.com.    120    IN    A    206.71.169.116
> www.mysitehealth.com.    120    IN    A    206.71.169.116
> .            86400    IN    SOA    ns1.mysitehealth.com. 
> postmaster.mysitehealth.com. 61 10800 3600 604800 3600
> ;; Query time: 144 msec
> ;; SERVER: 206.71.169.116#53(206.71.169.116)
> ;; WHEN: Tue Feb 18 21:40:53 2014
> ;; XFR size: 9 records (messages 3, bytes 326)
> =====
>
> Now I suppose it begs the question, why are there duplicate SOA's 
> being returned when they're not in the DB?
>
> (I -REALLY- appreciate the help on this)
>
> -Chris
>>
>>> Cheers,
>>> -Chris
>>>
>>> On 2/18/14 2:14 PM, Aki Tuomi wrote:
>>>> SELECT * FROM records WHERE domain_id =
>>>
>
>
> _______________________________________________
> Pdns-users mailing list
> Pdns-users at mailman.powerdns.com
> http://mailman.powerdns.com/mailman/listinfo/pdns-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.powerdns.com/pipermail/pdns-users/attachments/20140218/033f636f/attachment-0001.html>


More information about the Pdns-users mailing list