On Wed, 3 Apr 2019, Dave Crocker wrote:
Section 7's suggestion for using Additional information does not rely on
caching.
Reliance on existing wildcard depends on propagation of a new RR, which
continues to be problematic. There's a reason the Attrleaf table has so many entries...
Now we're having a discussion about which is the frying pan and which is
the fire.
In my experience, these days getting a new rrtype that doesn't have extra
semantics into DNS servers happens pretty quickly. It's an entry in a
table or a new short stylized parse/unparse routine. DNS caches don't
have to change at all. The problem is the web provisioning crudware, which
is what I have tried with limited success to address with my DNS extension
language work. My dbound draft has no new DNS semantics, just ordinary
wildcards and an ordinary rrtype.
To put anything into the additional section, you're asking the DNS servers
to treat a _perim name specially if there are TXT records under the name
and to go search through the zone to find the extra stuff and put it in
the additional section. DNS caches have to change too, to treat the
additional stuff as non-hostile and pass it through, since caches throw
away unrecongnized additional sections to prevent cache poisoning (the
Kashpureff bug.)
You should run this by dnsop where I expect you'll get a great deal of
pushback and references to the DNS Camel for anything with new semantics.
Regards,
John Levine, [email protected], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
