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

[George Barwood]

----- Original Message ----- 
From: "bert hubert" <bert.hubert at netherlabs.nl>
To: <dns-operations at lists.dns-oarc.net>
Sent: Sunday, June 21, 2009 11:49 AM
Subject: [dns-operations] wrapup of fragmentation/do/tcp discussion requested


> 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'm also a simple implementor, and no expert, so my answers be wrong or unhelpful.
Maybe better qualified people will answer you questions later.

> 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..).

Yes, although I haven't seen any quantification of  "often".
 
> 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?

Not that I have seen.
 
> 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. 

BIND has been setting DO on queries with acceptable response length of only 512.
This seems to be a violation of the standard, unless you twist the words quite a bit.
However, I don't think it's the main issue.

> In other words, DNSSEC over TCP appears not to be acceptable? 

No, not exactly, but it is a worry, because TCP is problematic.
Large numbers of TCP queries could be a problem for the servers of large TLDs.

> Or alternatively, people w/o a path that supports fragments to
> the auth servers, should do w/o DNSSEC too?

It's not so much fragments, but firewalls that stop DNS responses > 512 bytes.
These people probably need to fix their firewalls before they can use DNSSEC, I think.
 
> 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?

Apparent yes, there are non-trivial numbers, but I haven't seen it quantified.

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

Maybe it did, but we were not informed.
 
> Was .se immune because it does not do NSEC3?

Not immune, but NSEC3 does make it worse, as your example shows.

The other issue you haven't mentioned is that fragmented responses are
susceptible to spoofing, which could lead to DoS problems.
 
> Your answers would help me in pondering DNSSEC in PowerDNS (should anyone
> care of course).

I share some of your concerns about DNSSEC. I do seriously wonder if DNSCurve
is a more practical way of improving DNS security in a reliable way. 
It's certainly much easier to implement, with much less to go wrong, compared to
DNSSEC.

That said, the worries may turn out to be no big problem.

Regards,
George
 
> Bert
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>