fix: adding environment variable to set edns max message size

[cmaurer]

We are encountering an issue where some runs error with unknown transport: tcp. This is due to the dns message coming back from our Dns Server (BlueCat) with the Truncation flag set.

provider.go

...
} else if r.Truncated {
	if retry_tcp {
		switch c.Net {
		case "udp":
			c.Net = "tcp"
		case "udp4":
			c.Net = "tcp4"
		case "udp6":
			c.Net = "tcp6"
		default:
			return nil, fmt.Errorf("unknown transport: %s", c.Net)
		}
	} else {
		msg.SetEdns0(dns.DefaultMsgSize, false)
		retry_tcp = true
	}
...

The code will retry with EDNS0 with a message size to the DefaultMessageSize. This DefaultMessageSize is 4096 bytes, but the dns library has a max message size of 65535.

github.com/miekg/dns/dns.go

	// MaxMsgSize is the largest possible DNS packet.
	MaxMsgSize = 65535

Since we are still getting the unknown transport: tcp after a retry, the dns response coming back from BlueCat is still larger than 4096 bytes.

This change is to create an Environment Variable (DNS_UPDATE_EDNS_MSG_SIZE) to allow setting the EDNS0 Message size to a value larger than DefaultMsgSize.

[bbasata]

👋 Hello from a terraform-provider-dns maintainer. I'm happy to assist with this pull request.

First, I'm curious if this change solves the problem. msg.SetEdns0 sets only the UDP payload size, so I'd be surprised if this changes the BlueCat server's behavior for a TCP retry. Do you have access to BlueCat's support team for clarification?

One way to verify: do you have a way to build this branch of the provider locally and test it with your DNS server and your Terraform configuration?

Alternately, it would be helpful to confirm the size of the server's response for the exact same query. Perhaps using a command line tool such as dig.

[cmaurer]

@bbasata We do have access to BlueCat support. I can follow up on that on another thread.

[bbasata]

@bbasata We do have access to BlueCat support. I can follow up on that on another thread.

Sounds good. Also, is it possible that the response is larger than 65535 bytes?

[cmaurer]

@bbasata We would need to get some detailed logging to determine if the response is greater than 65535 bytes. I have to coordinate with another Team to do that.

This provider needs the ability to log those types of things. It's would be easier to enable debugging in the provider vs coordinating with another Team (i.e. Networking).

Also, fyi, we have tried setting DNS_UPDATE_TRANSPORT to tcp, tcp4, and we get the same error. BlueCat is sending back a truncated flag.

Other things I have tried:

DNS_UPDATE_TIMEOUT - extending the timeout. it was a long-shot, but worth a try
DNS_UPDATE_RETRIES - increasing the number of retries, a long-shot also, but worth a try

[cmaurer]

@bbasata
One way to verify: do you have a way to build this branch of the provider locally and test it with your DNS server and your Terraform configuration?

I work in a highly secure environment, and I am not able to build this locally and test it.

[bbasata]

I work in a highly secure environment, and I am not able to build this locally and test it.

Got it, no problem. We'll eliminate that one.

Any info from BlueCat support on the "truncate TCP" behavior will be super helpful here.

[bbasata]

This provider needs the ability to log those types of things.

I'm looking into some options!

[bbasata]

This provider needs the ability to log those types of things.

I'm looking into some options!

I'm thinking we can log r.Len() and r.String() at the TF_PROVIDER_LOG=DEBUG level.

Let me know if this sounds helpful.

[cmaurer]

@bbasata that would be great. It might also be helpful to log the message being returned from the dns system.