Score:2

Remove RRSIG record from GoDaddy subdomain

ph flag

I added 4 NS entries for a subdomain for a SalesForce email campaign.

SalesForce has since complained they see an "RRSIG entry for the subdomain" and they "do not support (add to NS) RRSIG records", and as such I need to remove it.

I did not add the RRSIG entry - looks like it is automated? I do not see it in GoDaddy interface or in zone file. Can I remove it?

SalesForce directed me to a web tool (xnnd.com) that shows the offending record (last line)

email.example.com.  3600    IN  NS  ns4.exacttarget.com.
email.example.com.  3600    IN  NS  ns3.exacttarget.com.
email.example.com.  3600    IN  NS  ns2.exacttarget.com.
email.example.com.  3600    IN  NS  ns1.exacttarget.com.
email.example.com.  600 IN  RRSIG   NSEC 8 3 600 20220517140242 20220502140242.. (bunch of stuff...)

Per anx's comments and direction to DNSViz I see this error:

example.com to email.example.com: The server(s) for the parent zone (example.com) responded with a referral instead of answering authoritatively for the DS RR type.

I'm not sure if this is evidence of a problem or just an indicator that we have delegated DNS control for the subdomain to SalesForce. So still unclear where the issue lies.

Score:3
cn flag

RRSIG is a signature, related to DNSSEC. It is not an "hidden" record, but it can't be edited like any other record.

Your zone is DNSSEC enabled, as the DS record can tell, and the full DNSViz diagnostics. This is done by your DNS provider so for any question about the content of your zone, and if you are unaware about DNSSEC, your DNS provider should be your first point of contact.

But then you delegate a part of your zone to another set of nameservers. In that case you should have one or more DS records in your zone and the corresponding DNSKEY record(s) in the child nameservers. Which is obviously not the case as DNSViz tells you because it is unable to fetch the relevant DS record hence breaking the full DNSSEC validation for at least part of your zone, a situation you don't want to be because that means for some users (and probably the majority as the biggest public DNS resolvers are fully DNSSEC validating) they won't see that part of the zone at all, they will get a DNS error as if the name doesn't exist.

The "easy" (or at least quick) solution would be to ask your current DNS provider to disable DNSSEC on your full zone (which will have the consequence of removing those "hidden" RRSIG records). But you also loose a little, as DNSSEC do provide some guarantees about the integrity of the responses received by clients when accessing your resources.

The real solution would be instead to go to Salesforce and ask them to provide another way (without doing a delegation and NS records) to fulfil whatever service you need for them. That way, you could keep your zone being DNSSEC enabled. There is a big risk however that this request comes on deaf ears, as first you will need to go through enough layers of customer supports before arriving at someone understanding DNSSEC.

As for:

just an indicator that we have delegated DNS control for the subdomain to salesforce.

The mere presence of the NS records at the authoritative nameservers for your zone is a proof of control. If that is done just to assert proof, it is good enough, and they can be removed. If they are part of the service delivered, as explained above, you can not have those and a DNSSEC enabled zone at the same time, so it will be one or the other, not both.

Patrick Mevzek avatar
cn flag
@anx Because you think that end customer would be free to enter `NSEC` record in their zone? I don't know any single DNS provider offering that, do you know one? Hence, while technically possible and easy if you manage your zone yourself on your servers, it feels completely unrealistic for 99.99% of cases, even more so with a "generic" registrar and DNS provider, and for an OP who is obviously not well acquainted with DNSSEC...
anx avatar
fr flag
anx
Oh, I foolishly assumed because its possible and other parts can happen automatically in more or less the way most customers need, so could this. Dang, I can see now how that leaves only the two options you suggested.
Steve avatar
ph flag
@Patrick Mevzek Great. Thanks. I now recall we had a security audit and the auditors had us enable `DNSSEC`. So enabling `DNSSEC` is good for security but complicates things like delegating a subdomain. To properly delegate would involve generating keys or signatures or something that is more involved than clicking an option or filling out a simple record in the GoDaddy UI I assume? Salesforce did say if we cannot remove the `RRSIG` entry we could skip the delegation and I make their required entries directly.
user1686 avatar
fr flag
@Steve: A signed domain _is_ allowed to make an unsigned delegation, there's no problem with that. You just add the usual NS records, without any DS records alongside, and DNSSEC validators won't complain; they'll just accept the child zone as deliberately unsigned (the NSEC record lets validators know it's not a dnssec-stripping attack or anything). As far as I understand, the "problem" of having RRSIG records is entirely made up by SalesForce and there's no technical basis for their complaint.
Patrick Mevzek avatar
cn flag
@user1686 100% agree on "the "problem" of having RRSIG records is entirely made up by SalesForce and there's no technical basis for their complaint." except that, technically, as DNSViz reports, the current situation is broken due to how the current nameservers reply for a `DS` record on the name being delegated. So things could be made working but not necessarily at the current provider with the current case of delegation.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.