<html><head/><body><html><head></head><body>A referral from a signed zone to a signed sub zone will include a signed ds rr set. Ns rr sets and glue a or aaaa rr sets by comparison are not signed in the parent and therefore not signed in the delegation response. Nor will there be any dnskey records or nsec records. But signed delegations will still be uncomfortably large when received from some orbital death ray projector when it receives a spoofed query flow with your source address.<br>
<br>
An upward delegation is actually a protocol error but a lot of older servers especially bind do send them. Oops, sorry about that. They should never be signed though.<br>
<br>
Paul<br><br><div class="gmail_quote">Vernon Schryver <vjs@rhyolite.com> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre style="white-space: pre-wrap; word-wrap:break-word; font-family: monospace; margin-top: 0px">> From: Andrew Sullivan <ajs@crankycanuck.ca><br /><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;">Which overhead is meant, maintaining a list of valid TLDs or rate<br />limiting response to requests TLDs? </blockquote><br />Surely both. Neither is free. REFUSED (and so on) all sounds to me<br />cheaper than spinning up rate limiting infrastructure for a condition<br />that could change in future when the relevant TLD gets delegated.</blockquote><br />On the contrary, I think letting the RRL patches send neither a referral<br />nor an error response of REFUSED or NXDOMAIN is cheaper than spending<br />the CPU cycles and bandwidth to marshal and send the response.<br /><br /><br
/><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;">A DNSSEC referral from the gTLD roots gives about amplification of<br />about 14X.</blockquote><br />What is a DNSSEC referral? I don't think such referrals are signed,<br />are they?</blockquote><br />I doubt DNSSEC would be secure if referrals could be forged undetectably.<br /><br />Try `dig +trace <a href="http://crankycanuck.ca">crankycanuck.ca</a>` or <br />`dig +dnssec <a href="http://crankycanuck.ca">crankycanuck.ca</a> @a.root-servers.net` and notice the<br />RRSIG and NSEC RRs as well as the ~12X amplification.<br /><a href="http://stats.research.icann.org/dns/tld_report">http://stats.research.icann.org/dns/tld_report</a>/ says that .ca is<br />not yet signed. I guess that's why I can't get signatures from the<br />authorities for .ca
for their referrals.<br /><br /><br />Vernon Schryver vjs@rhyolite.com<br /><hr /><br />ratelimits mailing list<br />ratelimits@lists.redbarn.org<br /><a href="http://lists.redbarn.org/mailman/listinfo/ratelimits">http://lists.redbarn.org/mailman/listinfo/ratelimits</a><br /></pre></blockquote></div><br>
-- <br>
Sent from my Android phone with K-9 Mail. Please excuse my brevity.</body></html></body></html>