[dns-operations] wrapup of fragmentation/do/tcp discussion requested

[bert hubert]

Hi everybody,

I'm but a simple implementor, and I don't follow the DNS(EC) commnuity well
enough, so perhaps someone could help me to some answers.

I ask these questions because the sudden enthousiasm over DNSSEC (which I
can't fathom) may be forcing me to implement this protocol.

>From what I understand, when implementing support for EDNS 'large response'
on outgoing queries, it appears resolvers often discover that said large
answers don't make it back to the resolver (because of routers,
firewalls..).

So, resolvers then implement a sort of 'path probing' whereby they reask the
question with a shorter maximum acceptable response length, until they do
get a response.

This however will most likely be a packet that has been truncated (or, if we
are lucky, one that has been shorn of its optional additional records).

If truncated, the question is then re-asked over TCP.

It appears people are worried over this since the ORG switchover triggered a
600-fold increase in TCP traffic. I also hear rumors this should have come
down now that the TTL of DNSKEY is no longer zero. Any datapoints on that?

It also appears BIND is now asked to drop the DO ('DNSSEC ok') bit if it
can't get a clear UDP based path to the ORG servers large enough to carry
signed answers. In other words, DNSSEC over TCP appears not to be
acceptable? Or alternatively, people w/o a path that supports framents to
the auth servers, should do w/o DNSSEC too?

I also find that 
$ dig +norecurs +dnssec +bufsize=512 www.powerdns.org a @A2.ORG.AFILIAS-NST.INFO

Leads to a 512+ byte plus answer (578), which indeed gets truncated. This is
an unsigned delegation, and should represent the most common question to the
ORG. servers.

Since this answer would comfortably bit a 1280 byte packet, this truncation
could probably have been avoided. Or are there non-trivial amounts of routes
that pass 512 octet UDP/53 packets, but drop 1280 octet ones?

Also, why did .gov not run into this issue? 

Was .se immune because it does not do NSEC3?

Your answers would help me in pondering DNSSEC in PowerDNS (should anyone
care of course).

	Bert