Unable to resolv 1 domain

Unbound
1

Hi,

My Unbound server unable to resolv this domain : lkpp.go.id
In fact i have forward it to other dns server and its domain server.

But again it is no issue on named.
Any idea what i have to check ?

Here is some information :

[root@ns1smg ~]# dig @103.55.160.20 lkpp.go.id

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.47.rc1.el6_8.4 <<>> @103.55.160.20 lkpp.go.id

; (1 server found)

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22042

;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:

;lkpp.go.id. IN A

;; ANSWER SECTION:

lkpp.go.id. 604800 IN A 103.206.244.234

;; AUTHORITY SECTION:

lkpp.go.id. 604800 IN NS ns2.lkpp.go.id.

lkpp.go.id. 604800 IN NS ns1.lkpp.go.id.

;; ADDITIONAL SECTION:

ns1.lkpp.go.id. 604800 IN A 103.13.181.24

ns2.lkpp.go.id. 604800 IN A 103.55.160.20

;; Query time: 9 msec

;; SERVER: 103.55.160.20#53(103.55.160.20)

;; WHEN: Thu Apr 6 17:14:58 2017

;; MSG SIZE rcvd: 112

On my unbound server :

[root@ns1smg ~]# dig @111.68.27.3 lkpp.go.id

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.47.rc1.el6_8.4 <<>> @111.68.27.3 lkpp.go.id

; (1 server found)

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 41327

;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:

;lkpp.go.id. IN A

;; Query time: 9 msec

;; SERVER: 111.68.27.3#53(111.68.27.3)

;; WHEN: Thu Apr 6 17:14:34 2017

;; MSG SIZE rcvd: 28

Regards,
Franky Yu

2

Hi Franky,

The domain is DNSSEC bogus. Unbound says:
validation failure <lkpp.go.id. A IN>: no keys have a DS with algorithm
RSASHA1-NSEC3-SHA1 from 103.13.181.24 for key lkpp.go.id. while building
chain of trust

And dnsviz output also shows it is bogus, here is a link
http://dnsviz.net/d/lkpp.go.id/dnssec/

If you want to make unbound ignore this failure, add to unbound.conf:
domain-insecure: "lkpp.go.id"

Best regards, Wouter

3

Wouter,

are you sure about the BOGUS status? I see (stripped down to minimum):

1. at the parent:

$ kdig +multi +dnssec IN NS lkpp.go.id. @b.dns.id.

KSK 31653

lkpp.go.id. 43200 IN DS 31653 7 1 (
        1DD2E4B3643C20097ECE57ECC1F36B8EFBBE303B
        )

2. at the child:

$ kdig +multi +dnssec IN DNSKEY lkpp.go.id. @ns1.lkpp.go.id.

KSK 31653

lkpp.go.id. 604800 IN DNSKEY 257 3 7 (
        AwEAAc4geZlrl3lZHie+wgyVayHtQ/KX1LSLZ6FsfPUO
        lHFsqHFV9osTQ+v9PR++SVPfU8cQZgmWeWsLut7JDqgX
        WRSt1833y8Q80HCB67RLRNoyktFkVrhGh2/1qL+bPvJW
        RdZjufqmvYMPpLJ+g8U1hx1JdsTOwSmEKuxGPlSJJft2
        crQBIN/XRi6MEDE8tGdw3SnwkgocVmTRJteO2V+uLRpK
        HN0WJYD7R7CGI0INoWbI2rsAgZr4hvbCQ3J0BToVoWue
        2UbPbACaZgmJXx1FPOC4bHKDzLVtLi62k/L1a/AJwp9E
        Zo7x5F7yCNQg6XUudxI+Nl7jJ5d12mJnQLsOFqUt48/R
        UKV0Fm1hl6lka6DiogwqA+7iTcaGknRoIXXjZ2p/D7vf
        i4vQGgmVV42POvrOi7rffhzbQEpiA7Vqx597cP8yCfbL
        5cpWFZncxkkLgp92u3D2MWxtdE9aFcuP58xPbnO6mvKq
        RrdnXzY4o2XbTtV4WlhJ69VzDoVeMm6p67R4R2cdqDZq
        LkdrbLU29nj3fVkrMK+9IswIfVJl/DOEHzCCye8brlce
        HF+vqNOb0g6OHj6S86aKtfKgl6DhiBFoaMneNSAFtca4
        yVhCMngZOfiWTnxTPqWE0VHu8QrnNL7M2AjZXrZFweLl
        AKvoYkUCb7HoOI+FASbZm3+0mkYx
        ) ; KSK; alg = NSEC3RSASHA1; key id =
        31653

and

lkpp.go.id. 604800 IN RRSIG DNSKEY 7 3 604800 (
        20170428022332 20170329022332 31653
        lkpp.go.id.
        iAMSKEUwNHmjqCRBygXeqvK2+kYAOGhHd1ZdTFkZeQDv
        D5/AmgfVASEpeso9kQ3Y/YRC8NBQ5JDFT/B3DFB26y9y
        FKBgLLsIrOjLNw7286FikQGtp4ZIGJmxgSbClaZsMnBA
        YS0vMu4uY42pOQ8C4gDMav94g1au+CU9w4QpBKDS8xtb
        6f+1B+yc3eodXdzS/iyKJYrpqPVRlOnAFGlJuxLXQxNJ
        GgC2ZvxmITARjfwDPROvo9zx9BoSKKnN1EV+sFqY0/xY
        j9OO8Q2CcQFRRuwHO4UO4or2aa1xn8lle7yhQAG46pbB
        74rFHU7Tyd5tfLNs0wD+gLTC27xw2kXRIJixgLM3bHOr
        nREuAjeokP0KulNe/TvfTiUVD+jcdDRsdTcBOZRyDOQy
        4Ke6pFp0jgQXXcwdRYnq39G6z+hdWuAmdN9ejnSg2R5N
        o7CF/Kh+uL5E+tlkEZAdW5i94FDSxrmlnbqLNwD+Bc4Z
        kwR8Rq7d4x2o1p5SjS8/v+vvsOUOVWN99Lnk9w7NwLfc
        pwn83kN5a91jkcu1lcgR+Dr+l2WVUlqWSgTIwfIKQ8A5
        y2PzaQCXZ1nCK5iexoYOl1zIgps4pM0WenAviFjHWgAE
        med75qM7rwLZqqZpRBBOB3VaaHqYFQohm8f3sVLN1n+O
        T6kkCOkeGsO+Saaht2SHHoU= )

ZSK 15284

lkpp.go.id. 604800 IN DNSKEY 256 3 7 (
        AwEAAdX16LDm+07IAtsXv+bf2HHO5S+jngvxcpay
        9awjHYtoy2tAPrjWWabRm8ymSO3wStqH6YY9xNiJ
        sKF8t+BXBenV4TQgbFO/FuioTZwTex4t3dJf01Ss
        auhidhoVVrPzkAOHOstHCjuIIxwH8DaGMncn7tx/
        lF4+S3Joi8CwceBWrwbdA0IWq7e7WG5Z/w4pK96E
        y4bpFDeY737EkBhPGiI5KAW5mD9eMkz7PZPss3vy
        5oC863I+XcD1RyaCv+Yljq1ZLLvgfpN8fCkokAYM
        QXxBK0PW0M4UPUTRbLatCHfxRawXpkg+bE/06bm/
        QrgbwYoDCiOjvkasZUJ/Vdavr4M=
        ) ; ZSK, RSASHA1_NSEC3_SHA1 (2048b), id
        = 15284

$ kdig +multi +dnssec IN A lkpp.go.id. @ns1.lkpp.go.id.

lkpp.go.id. 604800 IN A 103.206.244.234
lkpp.go.id. 604800 IN RRSIG A 7 3 604800 20170428022332 (
        20170329022332 15284 lkpp.go.id.
        FfCuaRXD14lOhnTQgL1g3DjUXo/OFLrhn9Y1x+9Q
        NWXniZgdiKhubf53ZxV8+xVYiBWvGGq0imcFoyzt
        98Uv8DrT9iHP4a6aZgE45Z1DXX6UE7u4x0CYeZd7
        g9JeV2s4jNWR1rYyln+DsbTBY5qLWNStaA71gvsn
        w29Pk34ssV6AP38i9OHD7bk39CY6ClOlvVtd+8Uh
        cZXAeWOr4BI+aCuJw5EYBte9GrlbBVD4z20Aw4/1
        KBK9jitG0Ty5SJz/1gJPDwAzIN6SLMNLzGNEjGz9
        cRsaPmlLBIOXwVC9MlTdR0GeYDTLzOZRRSviv/2u
        Dglyc3eRIjofg/O8A6yzkQ==
        )

And Verisign's DNSSEC Debugger also seems to disagree with DNSViz:

http://dnssec-debugger.verisignlabs.com/lkpp.go.id

O.

4

I see - the 31653 DS is only algo 1, but the other one is 1,2, but

But RFC 4509 says:

3. Implementation Requirements

   Implementations MUST support the use of the SHA-256 algorithm in DS
   RRs. Validator implementations SHOULD ignore DS RRs containing SHA-1
   digests if DS RRs with SHA-256 digests are present in the DS RRset.

So perhaps Unbound is too strict here? There are no known usable
attacks on SHA-1 for use in DNSSEC, so I don't think it's necessary to
ignore it right _now_.

O.

5

Hi Ondrej,

The issue is not that DS but the other SHA2 DS that makes all the SHA1
DSes irrelevant.

Also, partial rrsets are something unbound doesn't do, but parent-child
disagreements on the delegation glue are very common. Extreme leniency
stuff.

Best regards, Wouter

6

Hi Ondrej,

I see - the 31653 DS is only algo 1, but the other one is 1,2, but

But RFC 4509 says:

3. Implementation Requirements

   Implementations MUST support the use of the SHA-256 algorithm in DS
   RRs. Validator implementations SHOULD ignore DS RRs containing SHA-1
   digests if DS RRs with SHA-256 digests are present in the DS RRset.

So perhaps Unbound is too strict here? There are no known usable
attacks on SHA-1 for use in DNSSEC, so I don't think it's necessary to
ignore it right _now_.

But unbound clearly implements the SHOULD and thus should be
interoperable? That is what the 'SHOULD' is there for, right?
So, I am doing this because I think it is the standard. And I think so
should you.

I didn't do this out of strictness, but out of trying to implement
exactly what the standard said.

Best regards, Wouter

7

Perhaps this could be added to things controlled by:

harden-algo-downgrade: yes/no?

I don't think there's any security risk from using SHA1 for DS record
verification even if SHA-2 is available.

Ultimately, it's your call and decision.

Cheers,

8

Hi Ondrej,

Perhaps this could be added to things controlled by:

harden-algo-downgrade: yes/no?

I don't think there's any security risk from using SHA1 for DS record
verification even if SHA-2 is available.

I never analysed the implications, but just implemented the RFC. That
is why I am surprised by this.

And I think you are right and that stuff can be controlled by the same
switch. More leniency and strictness choice.

Best regards, Wouter