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 outbound query), "tcpdump" reports "[1au]", but the
query has no authority records, rather it has an EDNS(0) OPT record:

  tcpdump output:

    02:57:17.063675 IP (tos 0x0, ttl 64, id 37926, offset 0, flags [none], 
proto UDP (17), length 76)
        100.2.39.101.25779 > 1.1.1.1.53: 45584+% [1au] NS? secureshopping.info. 
(48)

  tshark output:

    Domain Name System (query)
        Transaction ID: 0xb210
        Flags: 0x0110 Standard query
            0... .... .... .... = Response: Message is a query
            .000 0... .... .... = Opcode: Standard query (0)
            .... ..0. .... .... = Truncated: Message is not truncated
            .... ...1 .... .... = Recursion desired: Do query recursively
            .... .... .0.. .... = Z: reserved (0)
            .... .... ...1 .... = Non-authenticated data: Acceptable
        Questions: 1
        Answer RRs: 0
        Authority RRs: 0
        Additional RRs: 1
        Queries
            secureshopping.info: type NS, class IN
                Name: secureshopping.info
                [Name Length: 19]
                [Label Count: 2]
                Type: NS (authoritative Name Server) (2)
                Class: IN (0x0001)
        Additional records
            <Root>: type OPT
                Name: <Root>
                Type: OPT (41)
                UDP payload size: 8192
                Higher bits in extended RCODE: 0x00
                EDNS0 version: 0
                Z: 0x8000
                    1... .... .... .... = DO bit: Accepts DNSSEC security RRs
                    .000 0000 0000 0000 = Reserved: 0x0000
                Data length: 0

The OPT record is needed to set the "DO" bit, and to convey the
EDNS buffer size.  Some router on your network has broken DNS, and
is generating fake NXDomain responses for DNSSEC-enabled queries.

FWIW, Exim does not actually "need" to set the DO bit, setting the
AD bit in the request would suffice, and would not require an OPT
record, but libresolv does not have "RES_AD" option, rather it only
has RES_DNSSEC, which then also elicits the AD bit.

If there were a simple way to get the stub resolver to set only
the AD bit, Exim could use that, and you'd not run into this
particular obstacle, but the fault is wither whatever device
is filtering your DNS queries.  It is b0rked, and it would
be good to find a way to get it to stop doing that.

-- 
        Viktor.

Attachment: pkt
Description: Binary data

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Reply via email to