This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[dns-wg] DNSSEC breaks qmail
- Previous message (by thread): [dns-wg] DNSSEC breaks qmail
- Next message (by thread): [dns-wg] DNSSEC breaks qmail
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Roy.Arends at nominet.org.uk
Roy.Arends at nominet.org.uk
Fri Feb 17 14:31:52 CET 2006
> * Roy Arends wrote: > > I can think of non-dnssec responses that are larger than 512 octets, so > > the subject of this message does not cover its content. > > Of course. The ANY request for "bofh." does exceed 512 bytes, too. In this > case it's caused by the large number of NS records. DNSSEC "guarantees" > exceeding this limit. Does it ? I can think of dnssec responses that are smaller than 512 octets. > > Which service marks a DNS message 'truncated' in your example ? > > The questioned nameserver. Setting the TC bit is a requirement from RfC 1035. The questioned nameserver has the luxury of constructing a response so that it _at_least_ satisfies the request. There is for instance no need for authority and additional section information to be send to the stub. I have no idea why an rfc4035 compliant resolver would send RRSIGs NSECs or DNSKEYs to a stub if the DO bit was not set. ANY only covers those if DO=1. I suspect that the questioned nameserver is broken. Roy
- Previous message (by thread): [dns-wg] DNSSEC breaks qmail
- Next message (by thread): [dns-wg] DNSSEC breaks qmail
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ dns-wg Archives ]