[Pdns-users] .pl admins here? answers of c-dns.pl differ from all other .pl nameservers

[Thomas Mieslinger]

Hi Brian,

thanks for looking closer at the output of dig than I did. You are 
right, the configuration of c-dns.pl is correct. I'm sorry that I wasted 
your time.

In the meantime I was contacted by .pl admins. There is an issue I 
reproduce constantly with 194.0.1.2. But that is an anycast address and 
it could also be a rate limiting issue I run into.

Best regards

Thomas

On 21.02.19 09:30, Brian Candler wrote:
> On 21/02/2019 07:53, Thomas Mieslinger wrote:
>> *c-dns.pl answers like this. (wrong in my opinion)*
>>
>> dig +retry=0 mx sassc.com.pl @c-dns.pl
>>
>> ;sassc.com.pl.                  IN      MX
>>
>> ;; AUTHORITY SECTION:
>> com.pl.                 86400   IN      NS      a-dns.pl.
>> com.pl.                 86400   IN      NS      b-dns.pl.
>> com.pl.                 86400   IN      NS      d-dns.pl.
>> com.pl.                 86400   IN      NS      e-dns.pl.
>> com.pl.                 86400   IN      NS      f-dns.pl.
>> com.pl.                 86400   IN      NS      g-dns.pl.
>> com.pl.                 86400   IN      NS      h-dns.pl.
>> com.pl.                 86400   IN      NS      i-dns.pl. 
> 
> I don't see what's wrong.  That's a perfectly valid delegation to those 
> 8 nameservers.
> 
> In other words: {a,b,d-i} happen to be authoritative for both pl and 
> com.pl; c is authoritative for pl only. Nothing wrong with that.
> 
> What really matters is the authoritative NS records within the com.pl 
> zone itself, and that is also consistent:
> 
> $ dig +norec @a-dns.pl. com.pl. ns
> 
> ...
> 
> ;; ANSWER SECTION:
> com.pl.            86400    IN    NS    f-dns.pl.
> com.pl.            86400    IN    NS    b-dns.pl.
> com.pl.            86400    IN    NS    h-dns.pl.
> com.pl.            86400    IN    NS    a-dns.pl.
> com.pl.            86400    IN    NS    e-dns.pl.
> com.pl.            86400    IN    NS    i-dns.pl.
> com.pl.            86400    IN    NS    d-dns.pl.
> com.pl.            86400    IN    NS    g-dns.pl.
> 
> This confirms that the authoritative nameservers for com.pl are 
> {a,b,d-i}-dns.pl only.
> 
>  > This makes my recursors and sometimes 1.1.1.1 recursors reply with 
> servfail for queries.
> 
> I am not doubting that you sometimes get servfail, but I don't see how 
> you draw the cause-and-effect conclusion.  Since you see the problem on 
> your own recursors, can you generate some logs which might show what is 
> going on?
> 
> If one is down, then the recursor will try others; and since there are 
> so many it seems unlikely that they would all be down at once.
> 
> In fact, it seems much more likely that the problem is with your own 
> authoritative nameservers:
> 
> $ dig sassc.com.pl. ns
> 
> ...
> ;; ANSWER SECTION:
> sassc.com.pl.        86400    IN    NS    dns.home.pl.
> sassc.com.pl.        86400    IN    NS    dns3.home.pl.
> sassc.com.pl.        86400    IN    NS    dns2.home.pl.
> 
> ;; ADDITIONAL SECTION:
> dns.home.pl.        3600    IN    A    46.242.149.10
> dns.home.pl.        3600    IN    A    46.242.149.11
> dns2.home.pl.        3600    IN    A    46.242.149.20
> dns2.home.pl.        3600    IN    A    46.242.149.21
> dns3.home.pl.        3600    IN    A    46.242.149.30
> dns3.home.pl.        3600    IN    A    46.242.149.31
> 
> If you have all your authoritative nameservers on the same subnet, that 
> certainly *can* lead to intermitted servfail problems as you've 
> observed.  I recommend follow the advice in RFC 2182.
> 
> Regards,
> 
> Brian.
>