Re: SERVFAIL/FORMERR/EINVAL on AAAA query - DNS

This is a discussion on Re: SERVFAIL/FORMERR/EINVAL on AAAA query - DNS ; > Greetings, > > Need an advice here, any idea what could be wrong with t_AAAA queries on > these hosts ? : > > emi.lancasterlabs.com. > smail.lancasterlabs.com. > mail.iss.it. > > Using BIND v9.3.x, I get SERVFAIL: > ========== ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Re: SERVFAIL/FORMERR/EINVAL on AAAA query

  1. Re: SERVFAIL/FORMERR/EINVAL on AAAA query


    > Greetings,
    >
    > Need an advice here, any idea what could be wrong with t_AAAA queries on
    > these hosts ? :
    >
    > emi.lancasterlabs.com.
    > smail.lancasterlabs.com.
    > mail.iss.it.
    >
    > Using BIND v9.3.x, I get SERVFAIL:
    > ==========
    > 10:40:24 root@zaibas:~# rndc flush
    > 10:40:29 root@zaibas:~# dig AAAA emi.lancasterlabs.com.
    >
    > ; <<>> DiG 9.3.2 <<>> AAAA emi.lancasterlabs.com.
    > ;; global options: printcmd
    > ;; Got answer:
    > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 62077
    > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
    >
    > ;; QUESTION SECTION:
    > ;emi.lancasterlabs.com. IN AAAA
    >
    > ;; Query time: 1260 msec
    > ;; SERVER: 127.0.0.1#53(127.0.0.1)
    > ;; WHEN: Thu Jul 27 10:40:31 2006
    > ;; MSG SIZE rcvd: 39
    > ==========
    >
    > with further details revealing FORMERR in debug log:
    >
    > ==========
    > 27-Jul-2006 09:55:37.552 resolver: resquery 0x83a1c00 (fctx
    > 0x8250a00(emi.lancasterlabs.com/AAAA)): response
    > 27-Jul-2006 09:55:37.552 general: message has 3 byte(s) of trailing garbage
    > 27-Jul-2006 09:55:37.552 resolver: received packet:
    > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49309
    > ;; flags: qr aa ; QUESTION: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
    > ;; QUESTION SECTION:
    > ;emi.lancasterlabs.com. IN AAAA
    >
    > ;; AUTHORITY SECTION:

    lancasterlabs.com. 86400 IN SOA lancasterlabs.com.
    > administrator.lancasterlabs.com. 998545544 28800 7200 6
    > 04800 86400
    >
    >
    > 27-Jul-2006 09:55:37.552 resolver: fctx
    > 0x8250a00(emi.lancasterlabs.com/AAAA'): noanswer_response
    > 27-Jul-2006 09:55:37.552 resolver: fctx
    > 0x8250a00(emi.lancasterlabs.com/AAAA'): cancelquery
    > 27-Jul-2006 09:55:37.552 dispatch: dispatch 0x8229000 response 0x852b300
    > 65.163.209.74#53: detaching from task 0x823d600
    > 27-Jul-2006 09:55:37.552 dispatch: dispatch 0x8229000: detach: refcount 6
    > 27-Jul-2006 09:55:37.552 resolver: fctx
    > 0x8250a00(emi.lancasterlabs.com/AAAA'): add_bad
    > 27-Jul-2006 09:55:37.552 lame-servers: FORMERR resolving
    > 'emi.lancasterlabs.com/AAAA/IN': 65.163.209.74#53
    > ==========
    >
    > Tried to trace the thing and FORMERR is returned from following part of
    > noanswer_response() code:
    >
    > ===== resolver.c lines 4252-4272 =====
    > /*
    > * Did we find anything?
    > */
    > if (!negative_response && ns_name == NULL) {
    > /*
    > * Nope.
    > */
    > if (oqname != NULL) {
    > /*
    > * We've already got a partial CNAME/DNAME chain,
    > * and haven't found else anything useful here, but
    > * no error has occurred since we have an answer.
    > */
    > return (ISC_R_SUCCESS);
    > } else {
    > /*
    > * The responder is insane.
    > */
    > return (DNS_R_FORMERR);
    > }
    > }
    > ==========
    >
    > The problem is that on FreeBSD boxes (starting with FreeBSD v5.3 and up,
    > my guess is when BIND v9 resolver was integrated) sendmail now gets
    > h_errno=EINVAL (errno=h_errno below) for these queries, so resolver
    > option WorkAroundBrokenAAAA is not working anymore:
    >
    > ===== sendmail v8.13.6 daemon.c lines 2318-2326 =====
    > if (WorkAroundBrokenAAAA && family == AF_INET6 &&
    > errno == ETIMEDOUT)
    > {
    > /*
    > ** An attempt with family AF_INET may
    > ** succeed By skipping the next section
    > ** of code, we will try AF_INET before
    > ** failing.
    > ==========
    >
    > Regards,
    > Evaldas


    Note the SOA record in the last response should be owned
    by emi.lancasterlabs.com not lancasterlabs.com. Named
    rejects answers which move back up heirachy.

    Mark

    com. 172800 IN NS L.GTLD-SERVERS.NET.
    com. 172800 IN NS M.GTLD-SERVERS.NET.
    com. 172800 IN NS A.GTLD-SERVERS.NET.
    com. 172800 IN NS B.GTLD-SERVERS.NET.
    com. 172800 IN NS C.GTLD-SERVERS.NET.
    com. 172800 IN NS D.GTLD-SERVERS.NET.
    com. 172800 IN NS E.GTLD-SERVERS.NET.
    com. 172800 IN NS F.GTLD-SERVERS.NET.
    com. 172800 IN NS G.GTLD-SERVERS.NET.
    com. 172800 IN NS H.GTLD-SERVERS.NET.
    com. 172800 IN NS I.GTLD-SERVERS.NET.
    com. 172800 IN NS J.GTLD-SERVERS.NET.
    com. 172800 IN NS K.GTLD-SERVERS.NET.
    ;; Received 511 bytes from 192.203.230.10#53(E.ROOT-SERVERS.NET) in 169 ms

    lancasterlabs.com. 172800 IN NS ns1.everydns.net.
    lancasterlabs.com. 172800 IN NS ns2.everydns.net.
    lancasterlabs.com. 172800 IN NS ns3.everydns.net.
    lancasterlabs.com. 172800 IN NS ns4.everydns.net.
    ;; Received 187 bytes from 192.48.79.30#53(J.GTLD-SERVERS.NET) in 322 ms

    emi.lancasterlabs.com. 3600 IN NS linkproof-1.lancasterlabs.com.
    emi.lancasterlabs.com. 3600 IN NS linkproof-2.lancasterlabs.com.
    ;; Received 123 bytes from 63.219.183.200#53(ns4.everydns.net) in 241 ms

    lancasterlabs.com. 86400 IN SOA lancasterlabs.com. administrator
    ..lancasterlabs.com. 998545544 28800 7200 604800 86400
    ;; Received 143 bytes from 65.163.209.74#53(linkproof-1.lancasterlabs.com) in 25
    3 ms

    --
    Mark Andrews, ISC
    1 Seymour St., Dundas Valley, NSW 2117, Australia
    PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org



  2. Re: SERVFAIL/FORMERR/EINVAL on AAAA query

    Mark Andrews wrote:
    >
    > Note the SOA record in the last response should be owned
    > by emi.lancasterlabs.com not lancasterlabs.com. Named
    > rejects answers which move back up heirachy.
    >
    > Mark
    >
    > com. 172800 IN NS L.GTLD-SERVERS.NET.
    > com. 172800 IN NS M.GTLD-SERVERS.NET.
    > com. 172800 IN NS A.GTLD-SERVERS.NET.
    > com. 172800 IN NS B.GTLD-SERVERS.NET.
    > com. 172800 IN NS C.GTLD-SERVERS.NET.
    > com. 172800 IN NS D.GTLD-SERVERS.NET.
    > com. 172800 IN NS E.GTLD-SERVERS.NET.
    > com. 172800 IN NS F.GTLD-SERVERS.NET.
    > com. 172800 IN NS G.GTLD-SERVERS.NET.
    > com. 172800 IN NS H.GTLD-SERVERS.NET.
    > com. 172800 IN NS I.GTLD-SERVERS.NET.
    > com. 172800 IN NS J.GTLD-SERVERS.NET.
    > com. 172800 IN NS K.GTLD-SERVERS.NET.
    > ;; Received 511 bytes from 192.203.230.10#53(E.ROOT-SERVERS.NET) in 169 ms
    >
    > lancasterlabs.com. 172800 IN NS ns1.everydns.net.
    > lancasterlabs.com. 172800 IN NS ns2.everydns.net.
    > lancasterlabs.com. 172800 IN NS ns3.everydns.net.
    > lancasterlabs.com. 172800 IN NS ns4.everydns.net.
    > ;; Received 187 bytes from 192.48.79.30#53(J.GTLD-SERVERS.NET) in 322 ms
    >
    > emi.lancasterlabs.com. 3600 IN NS linkproof-1.lancasterlabs.com.
    > emi.lancasterlabs.com. 3600 IN NS linkproof-2.lancasterlabs.com.
    > ;; Received 123 bytes from 63.219.183.200#53(ns4.everydns.net) in 241 ms
    >
    > lancasterlabs.com. 86400 IN SOA lancasterlabs.com. administrator
    > .lancasterlabs.com. 998545544 28800 7200 604800 86400
    > ;; Received 143 bytes from 65.163.209.74#53(linkproof-1.lancasterlabs.com) in 25
    > 3 ms


    I see, does it look like delegation ? Then maybe it's not a good idea to
    delegate records for MX hosts ?

    Also SOA serial numbers are different on ns1.everydns.net. and
    linkproof-1.lancasterlabs.com., looks like split DNS with both parts
    exposed to Internet.

    iss.it has the same setup for their MX, and I guess there are others.

    The bad thing is that you only notice the problem when sendmail tries to
    deliver mail from ipv6 enabled box, the A queries work like a charm
    because there is an answer and we see no "killer" SOA replies.

    Thanks for the explanation.

    Regards,
    Evaldas



+ Reply to Thread