[nsd-users] NSD not serving DNSKEY requests if the key is =>2048 bits

[Jelte Jansen]

Teran McKinney wrote:
> I guess this has turned into a drill or ldns issue.
> 
> I was using drill for the queries. Setting it to use TCP worked in all
> cases, and setting the DNSSEC flag worked for 2048 bits but not 4096
> bits. dig works fine over UDP with 2048 or 4096 bit requests. Sorry I
> didn't notice this earlier.
> 
> 8.4.e164.arpa has a 4096 bit DNSKEY and drill (1.3.0, under my setup)
> will not return a reponse unless the DNSSEC flag or TCP flag is set.
> Strange that setting DNSSEC works without TCP for this 4096 bit key,
> but did not work on my own 4096 bit keys. dig works without any flags
> to that zone.
> 

dig automatically falls back to tcp when it sees the tc bit in an answer
(as normal resolvers would). IIRC, it even does so when udp transport is
requested by command line argument.

drill on the other hand, just shows the packet it gets back, which is
the one with TC=1, and no (or not all) data. This has been a design
choice (based on my personal preference to literally show what is
sent/received and perform as little underwater magic as possible).

This is not cast in stone however, so if people think the default
behaviour should change we could discuss that, but ldns-users would be a
better place for that.

> 
>>>
>>> PS: How well supported is SHA2 for DNSSEC? ldns optionally supports it
>>> and I have read of some vulnerabilities with SHA1, so I would prefer
>>> to use it.

Currently i don't expect it to be supported at all anywhere, i haven't
had any responses to my request for implementations to do
interoperabilty tests. Since the document is no RFC yet, there are also
no official type codes for the algorithms, and the one ldns uses are
guesses of the value they might become. That's also the reason it is not
turned on by default yet. Also, auth servers should not need explicit
support for it (except maybe for the zone file parser, but
coincidentally not for the output made by ldns).

But the doc seems to be going into last call so i expect that support
will be added pretty soon after it has become an RFC.

Jelte

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL: <http://lists.nlnetlabs.nl/pipermail/nsd-users/attachments/20080820/a117ac7c/attachment.bin>