DNSSEC error resolving gpo.gov ?
Alexandra Yang
drayales at gmail.com
Wed Mar 15 14:01:53 UTC 2023
Sorry about all the posts, but this is the dumpdb of one server that works,
sometimes if we keep flush the cache we could get it work:
; glue
gpo.gov. 82291 NS ns3.gpo.gov.
82291 NS ns4.gpo.gov.
; pending-answer
28731 RRSIG NS 8 2 28800 (
20230318171338 20230311161338 40779
gpo.gov.
jdROyVKn7AxFh5g18d9h0qqSda2qMZSTueMW
EP3nREV4R9M4S82m0a0XCJVUcdCqKIH6BwZz
fj0H3MIblDzQ6F8A2hj92yGNJP5f828OdibF
oGa4nElD7o1M46t6arqu3rVyYQlwcvMsNcC3
/FSQ7Skq3jfWJYo4s6QxcxjVGcU= )
28731 RRSIG NS 8 2 28800 (
20230321051507 20230314041507 63918
gpo.gov.
dDg7pHmTn6BXogKcTZ8b4hZb6BtHp3ezBjFy
Vyov0zKWeZUG6vJpXyohnFkJPSKOslGyqPxN
O0cU2w/yUi05kIWY/99b7GPujUz0AfZkcG5D
sKRrleq3SGEyWVM2Tk1A4bqnIhPS5yj1l3rr
QhROlUrOvO9lbI+qLczQ2GemsKQ= )
; secure
85529 DNSKEY 256 3 8 (
AwEAAaGcZVZTCT0NqL+mhdI1d57gdWDdFdj/
sNzZRn5cvqC5naMKewy3XiYFWIE1GYj+hKzL
CoJY9Q1bLTo/yClzG4pSgU7H0vJEZTwGvcwY
jQmhaOXrT5dbgGL4C4CnXTV2ghCTl2YF/B73
dtbQX0iBMxNiRC++/M69Zpv45Rafzz/R
) ; ZSK; alg = RSASHA256 ; key id =
63918
85529 DNSKEY 256 3 8 (
AwEAAbpag1JE97BXQL6zqiZxeUElfsOkN9zF
KBxmeqRJd+Mk8jqkHHfHQPcLwMby6raZg1Rx
N+BFPt6VJVNbpZRqU419fQcEDyGXMIN7aqcz
AM1eNTf9UauyYRwtBPJyTPSBNz1YcqXqfSS7
X+ksU0B17MpnwpFkrc32mv34HN/HNimf
) ; ZSK; alg = RSASHA256 ; key id =
40779
85529 DNSKEY 257 3 8 (
AwEAAcuy7Davlhnj12z2e4K01v2og+7wHJWP
vVDiHsDdt8t8GBEdPOSIB9Ho/lVefhIaXN9C
B5qtWxY0AZ1iYkYaJBK1EjvaXeYWmzksUFzQ
wHrTJZakFNVVa28d4W0XrcM0azVS88bAEbmC
QqeNghnUgekhs60We19j09PTO+sHkEIaL+9v
y+g0imjZDB8u3ORZxRHTkqIQf65iOZccELjD
jP5NtgxaUGResOj9BIPtfbWcq+/STPJFhGxZ
H5givVmIcrvBpHhCQ17WO48tjK8EB/8ZgMYh
z8dI1xpVTfqgUCwXZLGVn8S4jOpUJqslwm+d
DVKi0t4k6xAOBbLrIQ8QqSs=
) ; KSK; alg = RSASHA256 ; key id =
18496
; secure
85529 RRSIG DNSKEY 8 2 86400 (
20230321051507 20230314041507 18496
gpo.gov.
qdaqi1f7dZ6kdGBciLU6WI3DxtDRiHMlADwY
SDAsknuF0KFofH1ZLKf/gjrfgs4UevDlfHig
WZCWR3jogLo+EpxtW8gT+6tRIOiMSZcHK8jg
BSUcU1OCKGgF3HQTw3vgdoJryuNST67TluZP
XK/Rxr1YysRx5dYHPG+DMkSzpa5hnzYGnGTn
ihKYPc55OzQvERvfuRz4D/LTqRdaJWEIWbYK
y4ELZrflqhPeN7mjOizDp+SUfZs2EdZvekTc
ksBV6lAfdnmTZcq/eaqpSR4O3jphFIB8USdg
wJegWsivXyt0BeUl+g7/bRUq6PwCDbgi6imr
jlOxlLnrxSDIjMaaYg== )
85529 RRSIG DNSKEY 8 2 86400 (
20230321051507 20230314041507 40779
gpo.gov.
esowjIbR3VJpmYpC4heSdkOvRsJND/iWdwz5
gPUJxVWMCrp6PN9zm7w31Jjo/Yxm1gn2+cOM
kW2RCZp/p1qiei1QT9+RaBPLDbbeTv5ti/aP
G1srQM89FTVHpyS9qcWI7ykwqndnGT0iW79e
NMXMuJfm94VYgpXdy7eCbsnNIEw= )
85529 RRSIG DNSKEY 8 2 86400 (
20230321051507 20230314041507 63918
gpo.gov.
DDB1dfHiDY/hh+nLP62grAfoi77Bt0IW0nGm
qApsBDpwG4j2ZLgdAwrHiHFmkPmmWVROpCAZ
ypT0kj9MdJVohUVdIXE4InIKcMDwz5TIGJvW
CTc9UbQcL91wTKjoL2LEXjCgfRnNrq7/JXWE
8e1QAUID/ZHM/2pRdHWzEA6ZY34= )
; secure
ns3.gpo.gov. 27929 A 162.140.15.100
; secure
27929 RRSIG A 8 3 28800 (
20230318165415 20230311155415 40779
gpo.gov.
AwNHaeinOPDj+yhjyNcOZDLotIq7Ei0t/Yr+
sHU6sKP2v62km2OapVLR13rsibAt1WImomGC
IuLsSHvQz6UXatbqYUPN+tcL7m1E27vF856e
Vfog9Oadfi5A8EwV+J5vi5nB1/c+Xv3TK5UY
wjTWgfvCmkkdsgY9LZPMAO/D9ng= )
27929 RRSIG A 8 3 28800 (
20230321051505 20230314041505 63918
gpo.gov.
OXqvAly9Qz/2gT6FneyEyuRgzCpNwWbLL2hX
K4+U85Ofi/J765W2Jkm2LHJmxQNvexp4SuaO
2q901Enj2kk6d9eteAtFH2VhJPc4MrMovlgH
DJGlor/dOj2rcAG3uLV6tt91OcumdZdFJ4Wq
XKb33SMi1P/n6vFnrHflk5fPTpQ= )
; secure
ns4.gpo.gov. 28731 A 162.140.254.200
; secure
28731 RRSIG A 8 3 28800 (
20230318171338 20230311161338 40779
gpo.gov.
CrP0m4NHmX/mRp2Ixp8kRpTLk3ACPW8TfYOx
zL5AeO9Sto98F/oQWPaYYWPUVdiLhwm294vj
q4RPzlHXrliJirthpxcPtA9u1HYWnnxIZuSm
cN1Tv0K5uim8adV/j3UEQLl+BuPCwVOQN3mR
NpHdklJ6BGYSsDPj0HV+beNOago= )
28731 RRSIG A 8 3 28800 (
20230321051507 20230314041507 63918
gpo.gov.
gvtA9RRtTSKA4tKm8i6xxSRuido2DR3xqm7f
kmLdyYD4Nx1syJAqm7E71XzBMkmlSDjDOB0w
K+Ps8B8vH2Ph7J/hA7IKUAD/oE6AXNOakIMo
ri8j40bfi8f0Q42uwZUdWhv8v+awTQsiZ8Wz
1QEiPPVV3Ya2Ubof1xv4odnyRUw= )
On Wed, Mar 15, 2023 at 9:46 AM Alexandra Yang <drayales at gmail.com> wrote:
> 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/493fcc06/attachment-0001.htm>
More information about the bind-users
mailing list