Hi,
Here is NSD 3.2.9. It has a fair list of bugfixes and it introduces two
new features:
- - Minimize responses to reduce truncation.
- - Less NSEC3 prehashing, to speed up zone transfer reloads.
For more information, see the Release Notes.
You can download NSD 3.2.9 at
Link: http://www.nlnetlabs.nl/downloads/nsd/nsd-3.2.9.tar.gz
Sha1: 66e17e5801e94da1a21f0f2a4dd7a4ab4ffe0dd9
Best regards,
Matthijs
RELNOTES
Matthijs,
Thanks for the 3.2.9 release. It looks like there are allot of good fixes in the release.
I'm trying to get a more thorough understanding of the mininal-responses feature in order to do a risk assessment of enabling it in our build.
I've done some archeology and from what I can tell, commits 3471 through 3473 are the total change. I could not find a bug referring to these commits.
Looking at the commits, I find this additional documentation in doc/REQUIREMENTS:
+ The feature 'minimize responses' is included since NSD 3.2.9.
+ NS RRsets that would go into the Authority section in positive
+ responses are not considered REQUIRED and therefore will NOT lead
+ to setting of the TC bit.
As I see it, my biggest risk of taking this feature is that I could possibly cause unexpected behavior in any client expecting this information, even though the spec says it's optional.
Are there any other issues I should consider?
Thanks,
Todd
Hi Todd,
Looks correct to me: by enabling minimal responses, we change the
behavior of NSD slightly. A resolver may expect the optional NS RRsets
and, but not having them in the response should not trouble the
resolver. In my opinion, this biggest risk is not a big risk at all.
I am not aware of any other issues that you should take into considerations.
Best regards,
Matthijs
Matthijs,
- Minimize responses to reduce truncation: NSD will only add optional
records to the authority and additional sections when the response
size does not exceed the minimal response size.The minimal response size is 512 (no-EDNS), 1480 (EDNS/IPv4),
1220 (EDNS/IPv6), or the advertized EDNS buffer size if that is
smaller than the EDNS default.
I'm curious why you choose to ignore the EDNS buffer size when it is
advertised (unless smaller than 1480/1220).
I see that NSD already uses the minimum MTU when possible on the system.
In principle this means that UDP packets should be fragmented by the
kernel, so should already be sending IP packets that make it across the
network without many problems.
Do you have any data on how much of a problem this causes and avoids in
some production networks?
Hi Shane,
Matthijs,
- Minimize responses to reduce truncation: NSD will only add optional
records to the authority and additional sections when the response
size does not exceed the minimal response size.The minimal response size is 512 (no-EDNS), 1480 (EDNS/IPv4),
1220 (EDNS/IPv6), or the advertized EDNS buffer size if that is
smaller than the EDNS default.I'm curious why you choose to ignore the EDNS buffer size when it is
advertised (unless smaller than 1480/1220).
We want to prevent fragmentation as much as possible. Optional
information should not be able to cause fragmentation.
I see that NSD already uses the minimum MTU when possible on the system.
In principle this means that UDP packets should be fragmented by the
kernel, so should already be sending IP packets that make it across the
network without many problems.
Still, IP packets fragmented by the kernel may still cause problems
across the network. One example is that a box is not considering one
fragment as a DNS packet and it may be drop the packet.
Do you have any data on how much of a problem this causes and avoids in
some production networks?
We know of few issues caused by fragmentation by the kernel, that is why
we want to prevent it as much as possible.
Best regards,
Matthijs
We want to prevent fragmentation as much as possible. Optional
information should not be able to cause fragmentation.
not everything in the additional section is 'optional', think of
additional data originating from glue records.
Still, IP packets fragmented by the kernel may still cause problems
across the network. One example is that a box is not considering one
fragment as a DNS packet and it may be drop the packet.
True, but I am not convinced that pleasing this brokenness by
suggesting fragments are avoidable (and thus making those that aren't
even more exceptional) is the right way to go. Race towards
lowest standards applies.
-Peter
swarm effects. While 'minimal responses' may be within the protocol
boundaries, the change limits the weight of the authoritative NS RRSet
compared to that in the delegation.
-Peter
While in practice I have no problem with suppressing the zone's NS set from most answers this has unindented side effects.
For most old resolver this changes their affinity from the Child side NS set to the parent one (i.e. makes them Parent centric).
If more an more authoritative servers do this we should be strongly recommending that resolvers fetch the child NS set once the resolver discovers a delegation.
Olafur
While in practice I have no problem with suppressing the zone's NS set
from most answers this has unindented side effects.
For most old resolver this changes their affinity from the Child side NS
set to the parent one (i.e. makes them Parent centric).
parent/child inconsistency and its mitigation by what you call 'child
centric' resolvers is current state. I'm not sympathetic
to sacrificing this on the altar of 'transition'.
If more an more authoritative servers do this we should be strongly
recommending that resolvers fetch the child NS set once the resolver
discovers a delegation.
That would be a protocol change, not a recommendation. QTYPE=NS just
doesn't exist in 1034/35. Can we please be conservative?
-Peter
Do you have any data to support your swarm effects claim?
Roy
Ha, apologies. Accidentally sorted my inbox oldest first, and responded to the first unread message.
Roy