Hi,
I didn't suggest changing the rules, I asked whether I'd missed a way
to configure the rules (e.g. to replace "defer" by "panic").
Failing that, any way to grep the logs for things that "shouldn't
happen" would be useful. Of course I can now grep for this particular
error, but I'm sure
On Fri, Jul 19, 2019 at 03:12:38AM -0400, Viktor Dukhovni via Exim-users wrote:
> Actually, the "tcpdump" documentation is misleading. In the attached
> PCAP file (single outbound query), "tcpdump" reports "[1au]", but the
> query has no authority records, rather it has an EDNS(0) OPT record:
On Fri, Jul 19, 2019 at 09:15:26AM +0300, Evgeniy Berdnikov via Exim-users
wrote:
> > Might there be a dnssec-related difference?
>
> Definitely NO, because this difference is in client's initial packets.
Actually, the "tcpdump" documentation is misleading. In the attached
PCAP file (single
> On Jul 18, 2019, at 6:32 PM, Jeremy Harris via Exim-users
> wrote:
>
>> A few anomalies are checked and may result in extra fields enclosed in
>> square brackets: If a query contains an answer, authority records or
>> additional records section, ancount, nscount, or
On Thu, Jul 18, 2019 at 11:32:17PM +0100, Jeremy Harris via Exim-users wrote:
> On 18/07/2019 23:08, Evgeniy Berdnikov via Exim-users wrote:
> > Running tcpdump with -vvv shows that there is an authority record for root.
> > I don't know is this behaviour legal or not, and why this record is
