[dns-operations] Assistance Request: OpenDNS Not Resolving Certain .realtor™ Domains

[Viktor Dukhovni]

On Mon, Dec 01, 2025 at 05:42:23PM +0000, Matthew Embrescia via dns-operations wrote:

> Over the past week, we’ve received multiple reports from customers
> indicating that some .realtor domains (for example, hlaor.realtor)
> are failing to resolve through OpenDNS, while resolving normally
> across most other major recursive resolvers, including Google Public
> DNS, Cloudflare, and Quad9.

Indeed some of the recursive servers are responding with SERVFAIL and an
EDE suggesting a DNSSEC issue:

- LAX:

    $ for ns in 208.67.22{0,2}.2 2620:0:cc{c,d}::2; do dig +nsid @${ns} hlaor.realtor; done | grep -E 'opcode:|EDE|NSID'
    ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 59550
    ; EDE: 6 (DNSSEC Bogus)
    ; NSID: 72 33 30 30 38 2e 6c 61 78 ("r3008.lax")
    ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 20672
    ; EDE: 6 (DNSSEC Bogus)
    ; NSID: 76 72 31 2e 6c 61 78 ("vr1.lax")
    ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 7531
    ; EDE: 6 (DNSSEC Bogus)
    ; NSID: 72 33 30 31 31 2e 6c 61 78 ("r3011.lax")
    ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 21870
    ; EDE: 6 (DNSSEC Bogus)
    ; NSID: 72 33 30 30 38 2e 6c 61 78 ("r3008.lax")

- MEL:

    $ for ns in 208.67.22{0,2}.2 2620:0:cc{c,d}::2; do dig +nsid @${ns} hlaor.realtor; done | grep -E 'opcode:|EDE|NSID'
    ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 35571
    ; EDE: 6 (DNSSEC Bogus)
    ; NSID: 72 34 30 30 32 2e 6d 65 6c 31 ("r4002.mel1")
    ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 53654
    ; EDE: 6 (DNSSEC Bogus)
    ; NSID: 72 34 30 30 34 2e 6d 65 6c 31 ("r4004.mel1")
    ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 11898
    ; EDE: 6 (DNSSEC Bogus)
    ; NSID: 72 34 30 30 34 2e 6d 65 6c 31 ("r4004.mel1")
    ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 5349
    ; EDE: 6 (DNSSEC Bogus)
    ; NSID: 72 34 30 30 32 2e 6d 65 6c 31 ("r4002.mel1")

And ditto for DNSViz for via the same OpenDNS recursive servers:

    https://dnsviz.net/d/hlaor.realtor/e/3525266/dnssec/

but with the additional detail that the "CD" flag yields success, which
I can also confirm:

    $ for ns in 208.67.22{0,2}.2 2620:0:cc{c,d}::2; do dig +nsid +cd @${ns} hlaor.realtor; done | grep -E 'opcode:|EDE|NSID|^[^;]'
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33629
    ; NSID: 72 33 30 31 30 2e 6c 61 78 ("r3010.lax")
    hlaor.realtor.          3600    IN      A       100.24.208.97
    hlaor.realtor.          3600    IN      A       35.172.94.1
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14743
    ; NSID: 72 33 30 30 36 2e 6c 61 78 ("r3006.lax")
    hlaor.realtor.          3600    IN      A       100.24.208.97
    hlaor.realtor.          3600    IN      A       35.172.94.1
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49680
    ; NSID: 72 34 30 30 35 2e 6c 61 78 ("r4005.lax")
    hlaor.realtor.          3600    IN      A       35.172.94.1
    hlaor.realtor.          3600    IN      A       100.24.208.97
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14934
    ; NSID: 72 33 30 30 32 2e 6c 61 78 ("r3002.lax")
    hlaor.realtor.          3600    IN      A       100.24.208.97
    hlaor.realtor.          3600    IN      A       35.172.94.1

So most likely for some reason the OpenDNS servers don't like the DS
non-existence proof from the .realtor authoritative servers.  Which is
odd, because the DNSKEY and DS records of .realtor haven't changed since
late July 2021.

If Brian Somers is reading this list and still at Cisco OpenDNS, he
should have a better insight into the nature of the problem.

-- 
    Viktor.  🇺🇦 Слава Україні!