Cannot get linodes dns to work as slaves

So I assume you clicked "I wanted a slave zone" when adding the zone? How does your slave zone setup look like in Linode DNS Manager?

Do your master DNS server's logs show any sign of a transfer being attempted?

You really haven't provided any detail as to your actual master DNS configuration (nor even what DNS server you are using), nor exact details about how you configured the Linode DNS manager side. So it's hard to say what might be amiss.

Broadly, to master to your own domain:
* Configure your Linode appropriately (DNS server install, master domain, etc…). Permit zone transfers to Linode ns#.linode.com nameservers. Optionally, depending on server, enable slave notifications.

• Add the domains to the Linode DNS manager as slave zones. You add the IP address of your own master machine(s) here, not the IP addresses of Linode nameservers.
  You cover many of those points, but it's not completely clear which side you are doing which steps on. It would help if you were to show explicit Linode DNS Manager and local nameserver configurations. You also have 3 nameservers defined for your domain, and it's not clear which (or all) you are pointing Linode to as master?

Note that you are not able to restrict the set of Linode nameservers. Once you have a slave domain, your master will receive periodic requests (even if you don't notify them) from all Linode nameservers. Of course, you can reject some.

Some nameservers will only notify slaves that exist as NS records for the affected domain, and at the moment you only have NS records for ns[012].htservices.co.uk - the Linode servers should still eventually pick up the domain based on polling but it might take much longer.

To your tests:
> ;; WARNING: recursion requested but not available

would seem to indicate that ns1.linode.com sees the domain as external (which if it was a slave for of course it would not be)
Probably not so much external as simply not yet something it is authoritative for. That could be due to yet having a successful master transfer, or it could be something amiss with the basic entry. Showing your Linode DNS manager pages would be helpful.

> the master is working and answering queries. I can query it directly or via google's dns
Well, it shows Google got it somehow, but not directly how the master is doing. Plus since Google will support recursion, it's not really that helpful for this particular issue. I'd probably stick with direct queries to the master and to Linode.

Assuming the basic master/client is correct on both sides, I'd then recommend tracing the network traffic to your master nameserver (and/or watching its logs for slave requests). Maybe you're firewalled, or maybe the master is opting to reject transfers for some reason.

In terms of timing, it'll take up to 15 minutes for the initial slave domain entry to enter the Linode nameservers, but after that notification based changes will be reflected in real time, or based on periodic queries the Linode nameservers will do to the master per the SOA record values. I'm not sure what the default polling interval is prior to the first successful retrieval.

Even if you've got the master messed up, as long as you have the master IP address in Linode's DNS manager as a slave zone, you should see periodic attempts from each Linode nameserver to retrieve the zone arriving at the master IP address.

– David

@retrograde inversion:

So I assume you clicked "I wanted a slave zone" when adding the zone? How does your slave zone setup look like in Linode DNS Manager?

removed

@retrograde inversion:

Do your master DNS server's logs show any sign of a transfer being attempted?

No, nothing in the logs at all from linode's servers (I have another slave that is querying and transferring ok)

Hi David

Thanks for replying.

master is my linode server ns0.htservices.co.uk running Bind9

I used to have a very similar setup with my old VPS hosting and it worked fine

I followed a forum post and set ns1.htservices.co.uk and ns2.htservices.co.uk as slave nameservers with glue records pointing to the relevant servers. (85.159.212.111, 69.93.127.10, 65.19.178.10)

Master ns0 - 85.159.212.111 is answering fine and is authoratitive (and is providing the answer to Google)

; public view zone file for htservices.co.uk

$TTL 5m ;2d; 172800 secs default TTL for zone
$ORIGIN htservices.co.uk.

htservices.co.uk.     IN    SOA        ns0.htservices.co.uk. admin.htservices.co.uk. (
                            2014062203 ; se = serial number
                            3h         ; ref = refresh
                            15m        ; ret = update retry
                            3w         ; ex = expiry
                            3h         ; min = minimum
                            )

                      IN    NS      ns0.htservices.co.uk.
                      IN    NS      ns1.htservices.co.uk.  ; ns1.linode.com
                      IN    NS      ns2.htservices.co.uk.  ; ns2.linode.com

                      IN    MX  10  mx1.htservices.co.uk.

@                     IN    A       89.145.86.105
mx1                   IN    A       89.145.86.98
www                   IN    A       85.159.212.108
ns0                   IN    A       85.159.212.111  
ns1                   IN    A       69.93.127.10      ; ns1.linode.com
ns2                   IN    A       65.19.178.10      ; ns2.linode.com
mail                  IN    CNAME   mx1
gw                    IN    A       81.187.202.94

@                     IN    TXT     "v=spf1 mx a ptr ~all"
@                     IN    SPF     "v=spf1 mx a ptr ~all"

There is my master zone and the relevant chunk out of /etc/bind/named.conf.local

        zone "htservices.co.uk" {
                type master;
                file "/etc/bind/zones/htservices.co.uk.db";
                allow-transfer { 69.93.127.10; 65.19.178.10; };
                also-notify    {  69.93.127.10; 65.19.178.10; };
                notify-source 85.159.212.111;
        };

@db3l:

Maybe you're firewalled, or maybe the master is opting to reject transfers for some reason.

– David

:oops: Useful info added to brain axfr uses tcp not udp :oops:

Thanks everyone for looking in

@GuyH:

;; WARNING: recursion requested but not available

would seem to indicate that ns1.linode.com sees the domain as external (which if it was a slave for of course it would not be)

This is expected and desired behavior from an authoritative-only nameserver. Add +norec to your dig command so that dig does not request recursion (does not set the RD bit) in the query.

@GuyH:

; public view zone file for htservices.co.uk

If this comment is to be trusted it would appear to imply that you are using views. The view configuration would then be relevant as well.

@GuyH:

                      IN    NS      ns1.htservices.co.uk.  ; ns1.linode.com
                      IN    NS      ns2.htservices.co.uk.  ; ns2.linode.com
...
ns1                   IN    A       69.93.127.10      ; ns1.linode.com
ns2                   IN    A       65.19.178.10      ; ns2.linode.com

While this does not appear to be related to your problem it raises the question of why one would do such a thing?

@GuyH:

No, nothing in the logs at all from linode's servers (I have another slave that is querying and transferring ok)

Are you absolutely positive?

@GuyH:

@db3l:

Maybe you're firewalled, or maybe the master is opting to reject transfers for some reason.

– David

:oops: Useful info added to brain axfr uses tcp not udp :oops:

Thanks everyone for looking in

DNS in general has 53/udp as well as 53/tcp as a requirement.

@hawk7000:

@GuyH:

;; WARNING: recursion requested but not available

would seem to indicate that ns1.linode.com sees the domain as external (which if it was a slave for of course it would not be)

This is expected and desired behavior from an authoritative-only nameserver. Add +norec to your dig command so that dig does not request recursion (does not set the RD bit) in the query.

Thanks, another useful snippet of info. The prob I find with DNS is that usually 'it just works' so I don't play with it very often.

@hawk7000:

@GuyH:

; public view zone file for htservices.co.uk

If this comment is to be trusted it would appear to imply that you are using views. The view configuration would then be relevant as well.

Yes, it is actually quite a complicated setup with this server as a master for 1 domain & a slave for the internal view & the rDNS for a subnet of mine working off another (stealth) master elsewhere and, of course, Linode's DNS slaving off this (finally ;) ).

I used to serve lots of domains with no problem from my last VPS hosting, running happily for 4+yrs. They didn't offer an authoritiative service though, so at least here I can offload most of them :)

@hawk7000:

@GuyH:

                      IN    NS      ns1.htservices.co.uk.  ; ns1.linode.com
                      IN    NS      ns2.htservices.co.uk.  ; ns2.linode.com
...
ns1                   IN    A       69.93.127.10      ; ns1.linode.com
ns2                   IN    A       65.19.178.10      ; ns2.linode.com

While this does not appear to be related to your problem it raises the question of why one would do such a thing?
I did something very similar with the old hosting company and I couldn't find any official way, but saw this post https://forum.linode.com/viewtopic.php?t=2981

Pros and cons imho doing it this way and for my setup the pros outweighed the cons :)

@hawk7000:

@GuyH:

No, nothing in the logs at all from linode's servers (I have another slave that is querying and transferring ok)

Are you absolutely positive?

Yes, BUT then I realised that the machine that was transferring was doing it over a VPN and therefore have different firewall rules … that together with the message from David got me thinking. So I opened up transfers to all and tried a 'dig axfr' which was connection refused. So then realised … (it had been a very, very long day …)

Thanks again.

I have written this post as it may help someone in the future and to say thanks for those that helped :D