Ed, On 07/01/2025 01.09, Edward Lewis wrote:
On Jan 6, 2025, at 17:06, Shane Kerr <sh...@time-travellers.org> wrote:Alex, On 06/01/2025 22.02, Brotman, Alex wrote:Looking at something relating to the day job, and I'm curious if there's any method declared in the IETF world where the query side of the interaction can understand that the response was fulfilled by a wildcard record. I've asked a few folks, and I haven't gotten anything that suggests as though this is possible. No one knew of any RFC or similar document that suggested this was an option. I was curious if we're all missing something that could indicate this type of response. If not, is it something that should exist?Others have mentioned signed zones. For unsigned zones, you cannot know from an answer, but you can send queries for the wildcard record itself. So if you query FOO.BAR.EXAMPLE and get an answer at the server for EXAMPLE, you can query *.BAR.EXAMPLE and *.EXAMPLE at the same server and see if the wildcard record exists at either of these.At first I thought that, but existence of a “source of synthesis” (a name whose first [lowest in the tree] label is ‘*’) doesn’t mean it was used to generate the response. It’s possible that the queried RRSET at the queried name is the equivalent to that at the source of synthesis.
This is a good point! I guess it depends on whether you really, REALLY care if the answer is made from a wildcard. Otherwise if the RDATA is the same you can safely assume that it was - or might as well be.
Should there be a wildcard flag? I don’t think so, as a protocol engineer. Any such flag wouldn’t impact the operation of the protocol (as it exists today). Perhaps there is some other reason outside protocol functioning.
I'd rather spend effort in getting rid of wildcards. 😉 Cheers, -- Shane
OpenPGP_0x3732979CF967B306.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
