[Dnssec-deployment] EDNS0 follow up - Re: ... TLD DNSKEY responses
Ed.Lewis at neustar.biz
Wed May 9 08:30:17 EDT 2012
At 10:45 +1000 5/9/12, Mark Andrews wrote:
>Named retries on timeout with different sets of EDNS parameters so
>it's not a all or nothing situation. Most answers are also small
>enough that the occasional retry is not a issue. Named also logs
>when it succeeds after falling back. This produces a few false
>positives but if you are getting a lot of messages you usually have
>a problem that you can fix.
>Named also generates minimal responses if you ask it a question
>with EDNS at 512 so you don't get a lot TCP fallback.
I'd classify this strategy as a good band-aid, not a solution. What
this does is raise the amount of network traffic and round trips to
get the answer. The query issuer achieves its goal but slows the
application and burdens the infrastructure. I'm not say that this
tack is poison, just that it is a partial solution, solving for just
one leg of the problem.
(It would be good to put numbers next to the "so small" and "most"
and "occasional" and "few" language. Without that, this argument
remains academic at best. I say this because when I bother to
measure something, I'm usually surprised that the conventional wisdom
>For TLD's the bulk of the answers are referrals or NXDOMAIN responses
>neither of which are large enough to need to be fragmented.
I pulled this out of the air to challenge the assertion.
# dig kajsdfklsdlkjfsdjfls.org +dnssec
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 28525
;; MSG SIZE rcvd: 1018
Perhaps 1000 bytes won't get fragmentation, but an NSEC3 negative
answer can get large.
NeuStar You can leave a voice message at +1-571-434-5468
2012...time to reuse those 1984 calendars!
More information about the Dnssec-deployment