DNSSEC error resolving gpo.gov ?

[Alexandra Yang]

We have client reporting problem resolving federalregister.gov
<http://www.federalregister.gov/> for several weeks, which hosted by the
two gpo.gov nameservers, and our nameserver can't resolve anything under
gpo.gov, we have dnssec-validation yes that's all, I really can't think of
anything can be done on our end to fix this, but also i don't understand
why such generic config like us see such issue not wide-spread?


Mar 14 10:23:32 ipam-dns-in-1 named[3713]: no valid RRSIG resolving '
ns3.gpo.gov/DS/IN': 162.140.15.100#53

Mar 14 10:23:32 ipam-dns-in-1 named[3713]: no valid RRSIG resolving '
ns3.gpo.gov/DS/IN': 162.140.254.200#53

Mar 14 10:23:32 ipam-dns-in-1 named[3713]: broken trust chain resolving '
ns3.gpo.gov/A/IN': 162.140.15.100#53


This is the dumpdb, wonder why pending-answer:


; glue

gpo.gov.                85163   NS      ns3.gpo.gov.

                        85163   NS      ns4.gpo.gov.

; secure

                        2363    DS      18496 8 1 (

                                        20D05E8AF9ED7706AC31146B9E3BEF2D04C4

                                        98ED )

                        2363    DS      18496 8 2 (

                                        665A12F38B1E446269351305495D6E5746CD

                                        F92D0CBAA34BAF77624C1CDDDD07 )

; secure

                        2363    RRSIG   DS 8 2 3600 (

                                        20230321224235 20230314224235 24250
gov.

                                        ZFdS88EC8WeL8H6jDcylnXBW5FBboNLhI8vT

                                        +hU0GFHVDDdhFW5u7qEEtTvyNArbBtZ8xAPA

                                        nALlJwe76n1GXEmYtdx/3CPSF/YLZWE9yc+R

                                        3eyXyvN65Ht73WtY1qY7cevXcWVxjiZQI7vf

                                        bFIS+yCkX4ZXE3U5dS7ydzasO5yIru05hLnD

                                        vTb6eHZty1Kb/O+d/v9WtsqgSTPcVXOgaA==
)

; pending-answer

ns3.gpo.gov.            889     \-AAAA  ;-$NXRRSET

; gpo.gov. SOA ins1.gpo.gov. noc.gpo.gov. 2010073218 10800 3600 2592000 900

; glue

                        43567   A       162.140.15.100

; pending-answer

ns4.gpo.gov.            889     \-AAAA  ;-$NXRRSET

; gpo.gov. SOA ins1.gpo.gov. noc.gpo.gov. 2010073218 10800 3600 2592000 900

; glue

                        43567   A       162.140.254.200

On Wed, Mar 15, 2023 at 1:50 AM Mark Andrews <marka at isc.org> wrote:

>
>
> > On 15 Mar 2023, at 15:42, Tim Maestas <tmaestas95 at gmail.com> wrote:
> >
> > Named should be sending queries with DO=1 and it should be getting back
> signed responses.  I suspect that you will need to run packet captures of
> the traffic to and from 162.140.15.100 and 162.140.254.200 port 53 from the
> nameserver.  Either signed responses will cease or DNSSEC requests will
> cease.  In either  case having the traffic around the transition should
> help to determine what is happening.
> >
> > I've found that, after a fresh restart of named, if I query for "
> federalregister.gov A" I get a good AD response, and then subsequent
> queries for "www.federalregister.gov" are successful as well.  If however
> after a restart of named I begin with a query for www.federalregister.gov
> A then I get servfail, and subsequent queries for federealregister.gov
> servfail as well.  Here is the tcpdump from the 2nd (failed) case of an
> initial query for www.federalregister.gov:
> >
> >
> > reading from file dns.cap, link-type EN10MB (Ethernet), snapshot length
> 262144
> > 04:30:01.114458 IP (tos 0x0, ttl 64, id 35832, offset 0, flags [none],
> proto UDP (17), length 92)
> >     10.0.0.159.43263 > 162.140.254.200.53: [udp sum ok] 15013 [1au] A?
> www.federalregister.gov. ar: . OPT UDPsize=512 DO [COOKIE
> 352538a87bde87a5] (64)
> > 04:30:01.204863 IP (tos 0x0, ttl 229, id 4936, offset 0, flags [DF],
> proto UDP (17), length 80)
> >     162.140.254.200.53 > 10.0.0.159.43263: [udp sum ok] 15013*-| q: A?
> www.federalregister.gov. 3/0/1 . OPT UDPsize=4096 DO [|domain]
>
> This is a malformed DNS response.  It looks like the server tried to send
> a truncated response with an OPT record but failed to correctly update the
> answer count field to zero.
>
> % dig www.federalregister.gov @162.140.15.100 +dnssec +bufsize=512
> +ignore +qr +norec
>
> ; <<>> DiG 9.19.11-dev <<>> www. @162.140.15.100 +dnssec +bufsize=512
> +ignore +qr +norec
> ;; global options: +cmd
> ;; Sending:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57919
> ;; flags: ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags: do; udp: 512
> ; COOKIE: 4a67cc813cfe03eb
> ;; QUESTION SECTION:
> ;www.federalregister.gov. IN A
>
> ;; QUERY SIZE: 64
>
> ;; Warning: Message parser reports malformed message packet.
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57919
> ;; flags: qr aa tc; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; QUESTION SECTION:
> ;www.federalregister.gov. IN A
>
> ;; ANSWER SECTION:
> . 32768 CLASS4096 OPT
> ;; Query time: 271 msec
> ;; SERVER: 162.140.15.100#53(162.140.15.100) (UDP)
> ;; WHEN: Wed Mar 15 16:30:22 AEDT 2023
> ;; MSG SIZE  rcvd: 52
>
>  --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742              INTERNET: marka at isc.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20230315/d8a60690/attachment-0001.htm>