Re: [dmarc-ietf] [dbound] Fwd: New Version Notification for draft-dcrocker-dns-perimeter-00.txt

["John R Levine" <[e-mail]>]

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, [e-mail], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly