On Wed, Sep 30, 2015 at 11:48:47AM -0400, dagon wrote:
> I'm still digesting the rest of the document, and running tests. It's
> well written, and helpfully annotated. I'm just a bit slow in this
> process.
"As long as I have you on the phone..."
I have one more comment:
3) Towards ECS Blacklisting
I write in praise of Section 12.1, when it notes that ECS probes
should never be sent to a TLD, an effective TLD (ugh, that term), or
a root.
Brief testing has not revealed any TLD or gTLD NS that exhibits
edns-client-subnet behavior. (The lab has placed bets about whether
the nTLD NS will hold any surprises, but testing is not complete,
and is ongoing.)
If you're looking for particulars, the draft might also note that
query minimization would address this issue entirely. Stub ECS
information is a fragment of query data similar to a child label
that requires truncation when chasing delegation.
I wonder if the logic of this section would not apply to any NS that
answers in delegation? Surely ECS only helps subsequent
tcp/{80,443} flows, and the odd tcp/53 flow from the recursive does
not need similar acceleration through network localization.
Of course, this would require white lists to index not only by the
IP, but also then blacklist the NS by zone, in a last-match rule
system. And as an aside, if my requests for yet another pony have
worn out anyone's patience, please accept my apologies.
Summary: The document might simply describe the EDNS0 payload with
reference to qname minimization principles. Such data is ripe for
cutting when iterating upwards, and even if ECS recursives don't
expand to exclude all zone cuts, perhaps q-min implementations might
address my suggestion for expanding beyond {g,e,n}TLD/root exclusion.
Best,
--
David Dagon
[email protected]
D970 6D9E E500 E877 B1E3 D3F8 5937 48DC 0FDC E717
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
