Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for connection re-use by secondary for XFR #145

Open
wants to merge 10 commits into
base: master
Choose a base branch
from

Conversation

saradickinson
Copy link
Contributor

*** FOR REVIEW ONLY AT THIS TIME***

  • Part of the work to prototype draft-ietf-dprive-xfr-over-tls
  • Adds 2 new parameters: xfrd-conn-reuse (default no) and tcp-idle-timeout (default 10)
  • If xfrd-conn-reuse: yes the secondary will utilise the existing the mechanisms in place (which are currently only used when XFRD_MAX_TCP is exhausted) to re-use connections
  • It will additionally leave those connections open and idle for tcp-idle-timeout, which is currently a fixed timeout. A later commit will add support for EDNS0 Keepalive, so the server can signal the timeout to use (as described in draft-ietf-dprive-xfr-over-tls)
  • Tested against BIND for multiple IXFR and AXFR on the same connection, for the same and different zones
  • NOTE: Encountered an issue with NSD reload behaviour and persistent XFR connections when trying to update the tpkg\long\testplan-axfr.dir test, will send separate email about this.

wcawijngaards added a commit that referenced this pull request Dec 3, 2020
  does not allow new queries to be made, the connection is closed.
  Only existing queries and zone transfers are answered, new ones
  are rejected by a close of the channel.
@wtoorop
Copy link
Member

wtoorop commented Jul 13, 2021

Instead of the xfrd-conn-reuse option, I'd like to have this enabled automatically when connecting over TLS (i.e. XoT) or when a KEEPALIVE EDNS0 option is detected with TCP.
So postponing merge until we have looked into that.

@saradickinson
Copy link
Contributor Author

I think having the default on would be good, I thought an option might be useful so it could be disabled in case of interop problems (e.g a legacy XFR implementation behind a proxy).

@wtoorop
Copy link
Member

wtoorop commented Jul 14, 2021

Perhaps it should be configurable per upstream then? For example in the tls-auth: declaration?
It would be good to have tls-cert-bundle configurable per tls-auth: declaration too b.t.w.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants