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 <ma...@isc.org> wrote:
>
>
> > On 15 Mar 2023, at 15:42, Tim Maestas <tmaesta...@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: ma...@isc.org
>
>
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
