3 ms·

There’s a lot of ways to replicate zone data of which zone transfers are the worst. I’ve never used the protocol. Use scp or rsync.

by js2 4y ago

icedchai 4y ago
What’s wrong with them? I’ve been using them for 25 years. Zone transfers are built in and “just work” once you set it up.
- js2 4y ago
  So I did used to use the axfrs back when I used to use bind. It’s clear text. It requires updating a serial number for no other reason than for the client to know to update. It’s based on polling. It exposes more complexity in the server that isn’t needed. It’s an archaic and dumb protocol. There’s nothing wrong with it in the same way there was nothing wrong with telnet or ftp. https://cr.yp.to/djbdns/axfr-notes.html https://cr.yp.to/djbdns/axfr-notes.html
  - icedchai 4y ago
    The primary can notify the secondary, so it doesn't have to poll: https://bind9.readthedocs.io/en/v9_16_6/advanced.html https://bind9.readthedocs.io/en/v9_16_6/advanced.html That feature was added well over a decade ago. Your changes on the primary will be replicated (within seconds) to your secondaries.
    - js2 4y ago
      I’m actually aware of that. Hacks upon hacks. And it doesn’t address the other issues. I’m glad axfr works for you and you’re happy with it. I stopped using bind after a multitude of security issues it had over the years and I haven’t looked back. When I did used to use it, I switched to rsync for zone files probably sometime around 2000. All of this is completely besides my original point: the zone file format needn’t have been an RFC, and probably not AXFR either. As far as I’m aware, no other RFC specifies implementation-specific decisions like the DNS RFCs do. It would be as if the sendmail.cf format had an RFC. AXFR is idiosyncratic and as recently as a decade ago underspecified: https://datatracker.ietf.org/doc/html/rfc5936 https://datatracker.ietf.org/doc/html/rfc5936 And it looks like there’s still ongoing work to make it secure: https://www.rfc-editor.org/rfc/rfc9103.html https://www.rfc-editor.org/rfc/rfc9103.html

There’s a lot of ways to replicate zone data of which zone transfers are the worst. I’ve never used the protocol. Use scp or rsync.

by js2 4y ago

There’s a lot of ways to replicate zone data of which zone transfers are the worst. I’ve never used the protocol. Use scp or rsync.

icedchai 4y ago

What’s wrong with them? I’ve been using them for 25 years. Zone transfers are built in and “just work” once you set it up.

js2 4y ago
So I did used to use the axfrs back when I used to use bind. It’s clear text. It requires updating a serial number for no other reason than for the client to know to update. It’s based on polling. It exposes more complexity in the server that isn’t needed. It’s an archaic and dumb protocol. There’s nothing wrong with it in the same way there was nothing wrong with telnet or ftp. https://cr.yp.to/djbdns/axfr-notes.html https://cr.yp.to/djbdns/axfr-notes.html
- icedchai 4y ago
  The primary can notify the secondary, so it doesn't have to poll: https://bind9.readthedocs.io/en/v9_16_6/advanced.html https://bind9.readthedocs.io/en/v9_16_6/advanced.html That feature was added well over a decade ago. Your changes on the primary will be replicated (within seconds) to your secondaries.
  - js2 4y ago
    I’m actually aware of that. Hacks upon hacks. And it doesn’t address the other issues. I’m glad axfr works for you and you’re happy with it. I stopped using bind after a multitude of security issues it had over the years and I haven’t looked back. When I did used to use it, I switched to rsync for zone files probably sometime around 2000. All of this is completely besides my original point: the zone file format needn’t have been an RFC, and probably not AXFR either. As far as I’m aware, no other RFC specifies implementation-specific decisions like the DNS RFCs do. It would be as if the sendmail.cf format had an RFC. AXFR is idiosyncratic and as recently as a decade ago underspecified: https://datatracker.ietf.org/doc/html/rfc5936 https://datatracker.ietf.org/doc/html/rfc5936 And it looks like there’s still ongoing work to make it secure: https://www.rfc-editor.org/rfc/rfc9103.html https://www.rfc-editor.org/rfc/rfc9103.html