Re: DNS lookup failing

Thu, 21 Mar 2024 02:40:48 -0700

I've done a bit more digging. With tcpdump, I can see the request coming from ClearOS into Unbound, going out onto the internet and returning with a valid answer to Unbound, but this answer does not then get back from Unbound to ClearOS.
I don't have the knowledge to look at the packet capture and diagnose what is going wrong, either in the original request from ClearOS or in the reply from Unbound to ClearOS. 

On 20/03/2024 12:31, Nick Howitt via Unbound-users wrote:



Dig works fine, it is just nslookup with Gateway Management on the 
client for direct lookups.
Unfortunately it also causes "amavisd testkeys" to fail because of an 
invalid response and I also get a startup warning with amavisd, so I 
assume it is doing a similar style lookup as nslookup. I've no idea 
which other programs may be failing.


On 20/03/2024 12:10, Cristiano Deana via Unbound-users wrote:

Hi,

should be a "answer too long packet truncated" problem.
Try use dig with TCP or edns




Il 20 marzo 2024 12:02:50 CET, Renaud Allard via Unbound-users 
<unbound-users@lists.nlnetlabs.nl> ha scritto:




    On 3/20/24 11:36 AM, Nick Howitt via Unbound-users wrote:

        I am having a problem with a particular DNS lookup and I am not
        even sure how to formulate the question, so please bear with me.

        My setup is Internet – IPFire with Unbound 1.19.0 – ClearOS7.
        ClearOS runs a system called Gateway Management which is a
        branding of AdamNetworks’ Adam:one, a DNS filtering tool.

        IPFire is currently running as a recursive resolver but the same
        problem exists when running as a Caching DNS server. All other
        boxes are empty on the DNS setup screen in IPFire. SSL and TLS
        are not being used. I should be able to dig out the configs, if
        needed.

        With Gateway Management running, in ClearOS I can resolve 1024
        and 2048 bit domainkeys (1024._domainkey.howitts.co.uk and
        2048_domainkey.howitts.co.uk) with nslookup. I can resolve 4096
        bit domainkeys using the dig command "dig txt
        202403._domainkey.howitts.co.uk" but with nslookup I get:


            [root@server ~]# nslookup -q=txt 
202403._domainkey.howitts.co.uk

            Server:         127.0.0.1
            Address:        127.0.0.1#53

            Non-authoritative answer:
            *** Can't find 202403._domainkey.howitts.co.uk: No answer

            Authoritative answers can be found from:
            howitts.co.uk
                     origin = achiel.ns.cloudflare.com
                     mail addr = dns.cloudflare.com
                     serial = 2336336559
                     refresh = 10000
                     retry = 2400
                     expire = 604800
                     minimum = 1800

        Without Gateway Management on ClearOS 7, it all works. This may
        lead you to thinking it is Gateway Management but if I change
        ClearOS’s upstream resolver from IPFire/Unbound to Cloudflare,
        all lookups work. This leads me to believe Unbound is doing an
        invalid lookup or giving an invalid response to a particular
        query formatted by Gateway Managament.

        I have pcap files of the working and non-working lookups between
        ClearOS and IPFire but I don’t know how to interpret them.

        Can anyone please help me?


    I get the exact same answer from unbound and cloudflare. Note that
    there is no authoritative answer. You might also have something like
    systemd-resolved in the way. Systemd-resolved is known to give bogus

    answers in certain cases, so you might want to disable it while 
testing.


    isildur$ nslookup -q=txt 202403._domainkey.howitts.co.uk
    Server: 127.0.0.1
    Address: 127.0.0.1#53

    Non-authoritative answer:
    202403._domainkey.howitts.co.uk text = "v=DKIM1;

    
p=MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAzvkHMnL2cPPUzm6gXBIsaiRMAj7wpajI1cQ3VPsIzIYfBTYgU7xX50tDZnTT4SiE/2+z87gMFSRcFiM9gaejAgV+YFse2AEId2t0+xYXuNwG35dqS6WWlwZY3Rr5IIebcPSeXouuYR3nCdzgK/FCT8Y2vvKTkIDXYsJMQJulxdDAewb9/V7pNZ7J8wky6RRIKnbAEdqO" "zJ9nDEe6wUGXhrMxB2ZjM6sQLJzAgz7VE0Z52eBk/TZgdzJwLxHzeclsWVES3Mw0tdDoUKT2QLd0SB9MsOwFcR6ph/h9VERhMAtjAmUG5YlQQ1bC8nznAwHdY2IP3RUdFZOYcUlv5yPzrRvBAjfi/CmR2zHVQs7gA7b67DaMy67dURWHDhMwqXgWVNrZ4iTInWr1vLEPoNBjppn1GOkXrb+FdNoWnFM5laAEmcFK2Sie5wpzCItFjWs3f3IQZxB" "lzJHIpkvR2ZTMJ5g3DWUU3ZK1rW1kNvGLjZkox7EZH3lFfkyS6lPnfIX5XS5YYeP0RmSAWNaKinCdQq8m8SdjWDIsRJ1aohq/Qx/O1sfQMDdrwetOn6KJqOFg7dcFtvKlRrHQYyujH3dapJ10Err/xAv3iyh9B7x8C6N+qjTMjRoIfPTyLeFnAtUrFQigpj70mbZPaw9AKglDafXvnXJwn8r5/Oq3mjVKKWkCAwEAAQ=="


    Authoritative answers can be found from:

    isildur$ nslookup -q=txt 202403._domainkey.howitts.co.uk 1.1.1.1
    ;; Truncated, retrying in TCP mode.
    Server: 1.1.1.1
    Address: 1.1.1.1#53

    Non-authoritative answer:
    202403._domainkey.howitts.co.uk text = "v=DKIM1;

    
p=MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAzvkHMnL2cPPUzm6gXBIsaiRMAj7wpajI1cQ3VPsIzIYfBTYgU7xX50tDZnTT4SiE/2+z87gMFSRcFiM9gaejAgV+YFse2AEId2t0+xYXuNwG35dqS6WWlwZY3Rr5IIebcPSeXouuYR3nCdzgK/FCT8Y2vvKTkIDXYsJMQJulxdDAewb9/V7pNZ7J8wky6RRIKnbAEdqO" "zJ9nDEe6wUGXhrMxB2ZjM6sQLJzAgz7VE0Z52eBk/TZgdzJwLxHzeclsWVES3Mw0tdDoUKT2QLd0SB9MsOwFcR6ph/h9VERhMAtjAmUG5YlQQ1bC8nznAwHdY2IP3RUdFZOYcUlv5yPzrRvBAjfi/CmR2zHVQs7gA7b67DaMy67dURWHDhMwqXgWVNrZ4iTInWr1vLEPoNBjppn1GOkXrb+FdNoWnFM5laAEmcFK2Sie5wpzCItFjWs3f3IQZxB" "lzJHIpkvR2ZTMJ5g3DWUU3ZK1rW1kNvGLjZkox7EZH3lFfkyS6lPnfIX5XS5YYeP0RmSAWNaKinCdQq8m8SdjWDIsRJ1aohq/Qx/O1sfQMDdrwetOn6KJqOFg7dcFtvKlRrHQYyujH3dapJ10Err/xAv3iyh9B7x8C6N+qjTMjRoIfPTyLeFnAtUrFQigpj70mbZPaw9AKglDafXvnXJwn8r5/Oq3mjVKKWkCAwEAAQ=="


    Authoritative answers can be found from:



--
Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità.






















					Reply via email to