[dnssd] Re: Why SIG(0) doesn't work for >1 hop

[Donald Eastlake <[e-mail]>]

Hi Ted,

On Fri, Jul 25, 2025 at 6:12 AM Ted Lemon <[e-mail]> wrote:
>
> Can you say more about what aspect of the solution is a kludge? The part that I'm particularly concerned about is that replacing the xid and using the replacement xid as an identifier for looking up the state required to forward the response back to the original requestor seems like an unnecessary complication to me.

? So you are not talking about a normal DNS recursive server? Because
you are saying that something all DNS recursive servers have always
done is "an unnecessary complication". (I am fudging a little on
details below but not much.)

Normally a DNS server that is configured to provide recursive service
does whatever requests it needs to and then creates a response to send
to the original source of the request that it received. The DNS
requests sent by the recursive server have IDs that are determined by
the recursive server independent of whatever ID was in the original
request it got. This has always been a part of DNS. See Section 4.3.1
of RFC 1034.

Recursive servers need to know when to forward a TSIG since by default
meta RRs are not forwarded, but TSIG is fairly widely supported so
this is in many DNS servers. If SIG(0) had been specified to have an
Original ID field, like TSIG does, then SIG(0) forwarding would be the
same as TSIG forwarding, so straightforward.

The above is all independent of whether UDP or TCP is being used
between the original source of the request and the DNS forwarder or
between the forwarder and another server.

The kludginess of the BIND support of forwarding SIG(0) is that
forwarding SIG(0) is the only case where it has to use TCP (or some
other stream protocol) for forwarding and the only case where it has
to jimmy the ID it uses on the DNS request it sends that is carrying
the forwarded SIG(0)

> From the perspective of SRP, the only reason to have a forwarder is that SRP relies on knowing what link the SRP update was sent from, which requires the use of a link-local source address or using TCP to confirm that the sender is reachable before processing the request. So if the SRP registrar is actually off-network, then either the SRP client needs to use TCP, or there needs to be some sort of relay.

So, you're talking about some special SRP UDP relay, not just an IP
router and not a recursive DNS server?

> The only thing the relay actually has to do is either change the source address to its link-local address and use a source port on which it can receive and forward back a reply, or else use TCP to forward the request in a way that conforms to the security requirements of SRP.
>
> So in this case the only thing the forwarder needs is some way of figuring out where to send the response that it receives from the SRP registrar. The BIND approach seems like a valid one to me—it's not clear why it's a kludge from this particular perspective. So presumably I am missing something. :)

I never said it was invalid. It works. It's just that it involves
adding SIG(0) only code that affects the DNS message ID logic which is
low level DNS logic that hasn't changed in ages.



Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   [phone] (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [e-mail]

> > On 25 Jul 2025, at 05:26, Donald Eastlake <[e-mail]> wrote:
> >
> > Hi Ted,
> >
> > On Thu, Jul 24, 2025 at 12:14 PM Ted Lemon <[e-mail]> wrote:
> >>
> >> FWIW I think the added complexity of the double signature isn't worth it.
> >
> > "double signature"? My apologies if the one example in my presentation
> > was confusing. It was designed so I could talk about two orthogonal
> > things: (1) using more than one SIG(0) in the request and response on
> > a DNS hop, and (2) why the Server MUST have the original DNS request
> > ID value available to it to be able to validate the the SIG(0). There
> > is almost no relationship between these. Problem two exists regardless
> > of whether or not any hop along the DNS forwarding server path uses
> > more than 1 SIG(0).
> >
> >> The BIND solution (or a similar UDP-based solution that used a different outgoing UDP source port per incoming source A+P) is a lot easier. I don't mean to say you shouldn't describe such a solution, but I don't see the value of it. You have to keep a table anyway, so you're just making the key a little bit smaller if it's a transaction ID rather than a port number.
> >
> > I'm not sure what you think "such a solution" is since you seem to say
> > it has something to do with double signatures. The solution in the
> > rfc2931bis draft is an EDNS0 option.
> >
> > I think the BIND solution is a kludge, admittedly a clever kludge
> > needed because of my lack of foresight when I specified SIG(0) a
> > quarter of a century ago in the year 2000. It is not specified in any
> > IETF document and it is my impression that only BIND supports it. It
> > does not take care of the admitted less pressing need for an extended
> > error return separate from DNS header error code. It does not provide
> > any assistance in conveying the key state information called for in
> > draft-berra-dnsop-keystate. If it is not clear, I think continuing
> > dependence on this sort of kludge is not a good idea.
> >
> > Thanks,
> > Donald
> > ===============================
> > Donald E. Eastlake 3rd   [phone] (cell)
> > 2386 Panoramic Circle, Apopka, FL 32703 USA
> > [e-mail]
> >
> >> I can see this maybe making sense in a really high volume situation, where you might run out of ports, but even then I don't think this is really an issue, because we only need the ports to disambiguate transaction IDs, so in practice we could do this very efficiently and not consume very many ports.
> >
> >> On 24 Jul 2025, at 17:26, Donald Eastlake <[e-mail]> wrote:
> >>
> >> The clearest description of the data in a DNS request that is signed by SIG(0) is probably in
> >> https://datatracker.ietf.org/doc/draft-eastlake-dnsop-rfc2931bis-sigzero/
> >> In particular, the data signed includes the DNS message header. This header, whether the request is an UPDATE (RFC 2136, Section 2.2) or other (RFC 1035, section 4.1.1) includes the "ID" field which DNS uses to match up replies with requests.
> >>
> >> To verify the SIG(0), you need the public key and exactly the same data as the data that was signed.
> >>
> >> Normally, when a DNS forwarder forwards a request, the header it constructs for the forwarded request has a new ID which is the forwarder's ID so the forwarder can recognize the response the forwarder gets. (If the forwarder just reused, over UDP for example, the ID from the request it received, there would be conflicts as, in general, the forwarder is getting requests from multiple different original requesters that are generating uncoordinated IDs.)
> >>
> >> TSIG, which is in many ways similar to SIG(0), solves this by including the original request message ID inside the TSIG (RFC 8945, Section 4.2).
> >>
> >> The BIND DNS implementation solves this problem for SIG(0) by always using a separate TCP connection to forward a request with a SIG(0). That way it can use the same ID in the forwarded request and keeps things straight by having an ID space scoped to that TCP connection.
> >>
> >> It seems likely to me that this general problem with >1 hot SIG(0) will be fixed in the DNSOP WG.
> >>
> >> Thanks,
> >> Donald
> >> ===============================
> >> Donald E. Eastlake 3rd   [phone] (cell)
> >> 2386 Panoramic Circle, Apopka, FL 32703 USA
> >> [e-mail]
> >>
> >>
>