DNS resolution failing with mixed replies

[anubhav]

I am getting mixed reply when looking at the logs for resolving a domain. I have added it to whitelist as well .quotable.io # quotes for obsidian but it still seems to be blocked when querying from device. What am I missing here?

❯ dig api.quotable.io

; <<>> DiG 9.10.6 <<>> api.quotable.io
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 3442
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1352
;; QUESTION SECTION:
;api.quotable.io.		IN	A

;; Query time: 157 msec
;; SERVER: <pfsense IP>#53(<pfsense IP>)
;; WHEN: Wed Sep 04 14:36:03 PDT 2024
;; MSG SIZE  rcvd: 44

[johnpoz]

@anubhav said in DNS resolution failing with mixed replies:

api.quotable.io

looks to be dnssec failure to me

https://dnsviz.net/d/api.quotable.io/dnssec/

ede response is this

; EDE: 9 (DNSKEY Missing): (No DNSKEY matches DS RRs of quotable.io)

Also showing this error with just unbound on pfsense

; EDE: 6 (DNSSEC Bogus)

You can enable EDE in unbound so you can see such info

edit: if you set

ede: yes

In the custom option box, and you dig and there is a servfail, you should get hopefully some info on what is wrong

As a work around, you could set that domain as not secure, so that it doesn't do dnssec.. Or could turn off dnssec completely - but would be better to just make an exception for that domain.. But clearly they have an issue currently, so prob best not to even go there.

[anubhav]

@johnpoz Thnaks for sharing this insight

[johnpoz]

@anubhav so your saying it sometimes works? Are you forwarding vs resolving? If you forward to different services where one does dnssec and the other does not, you will get an answer when you ask the one that is not doing dnssec.. for example 4.2.2.2 doesn't do dnssec..

$ dig @4.2.2.2 api.quotable.io                                                                                    
                                                                                                                  
; <<>> DiG 9.16.50 <<>> @4.2.2.2 api.quotable.io                                                                  
; (1 server found)                                                                                                
;; global options: +cmd                                                                                           
;; Got answer:                                                                                                    
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7115                                                          
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1                                              
                                                                                                                  
;; OPT PSEUDOSECTION:                                                                                             
; EDNS: version: 0, flags:; udp: 4096                                                                             
;; QUESTION SECTION:                                                                                              
;api.quotable.io.               IN      A                                                                         
                                                                                                                  
;; ANSWER SECTION:                                                                                                
api.quotable.io.        2384    IN      CNAME   mysterious-feijoa-0raf5466fxw0fo43e63hphuv.herokudns.com.         
mysterious-feijoa-0raf5466fxw0fo43e63hphuv.herokudns.com. 60 IN A 3.232.242.170                                   
mysterious-feijoa-0raf5466fxw0fo43e63hphuv.herokudns.com. 60 IN A 52.20.78.240                                    
mysterious-feijoa-0raf5466fxw0fo43e63hphuv.herokudns.com. 60 IN A 3.220.57.224                                    
mysterious-feijoa-0raf5466fxw0fo43e63hphuv.herokudns.com. 60 IN A 54.91.59.199                                    
                                                                                                                  
;; Query time: 28 msec                                                                                            
;; SERVER: 4.2.2.2#53(4.2.2.2)                                                                                    
;; WHEN: Wed Sep 04 18:52:05 Central Daylight Time 2024                                                           
;; MSG SIZE  rcvd: 178                                                                                            

This is another example of why its not good to forward to different services. When you forward to more than 1 NS, you can never be sure which one will be asked.. And if they don't provide the same services and info, like if they do filtering and one doesn't you run into stuff like this where sometimes something might resolve when you don't want it to, like if their dnssec is failing. Or it might not resolve when it should because the dns service doing some of their own filtering.

Notice that ttl is 60 seconds.. that is horrifically low.. There is no call for such low ttls - unless you were in the middle of changing the ip where something was going to point too.. They like these low numbers for tracking if you ask me..

If not tracking someone that is hosting a domain might be artificially creating more queries so they can charge more? In normal operation of dns such a low ttl makes little sense..

I on purpose set my min ttl to 3600 seconds for domains that do such shenanigans..

[Gertjan]

@johnpoz said in DNS resolution failing with mixed replies:

https://dnsviz.net/d/api.quotable.io/dnssec/

Nice ! Pure fireworks. I've regenerated the report. It's getting better every minute.

Any serious resolver would not accepting anything from that mess.
Nice example of

DNS resolution failing with mixed replies

why you shouldn't forward.

@johnpoz said in DNS resolution failing with mixed replies:

In normal operation of dns such a low ttl makes little sense..

To the defense of the admin of the zone "quotable.io", he is probably aware of the DNSSEC mess he created.
In case of emergency, the first think I would do, is setting the TTL to a low value, like 3600 or so. This way, when I try to repair the DNSSEC, and add even more errors because I never remember how generate a new KSK, where to place the ZSK etc etc, at least the currently produced DNS answers won't be cached all over the planet for days.
As that is the time needed for the host name to become accessible again.

@anubhav : normally, when you' forward' you've made up your choice, and one of them is : "I don't want DNSSEC to protect my DNS requests", so you shut down DNSSEC in unbound.

Not doing so creates

DNS resolution failing with mixed replies

[anubhav]

@Gertjan In my pfSense config, "DNS forwarder" service is disabled. I see that in my "DNS resolver" service, I had the DNS forward mode enabled. If I understand correctly, that is the one that you mention should not be done to allow for correct operation of DNSSEC.

[johnpoz]

@anubhav if you forward, you should not have dnssec enabled - where you forward is either going to do dnssec for you, like googledns or cloudflare, etc. or they won't like my 4.2.2.2 example

enabling dnssec and forwarding is just going to lead to problems.

And if your going to forward, if you want dnssec all the NS that you have listed to forward to should be doing it, or you can have different results depending on which actual NS got asked. Or if you don't want it - then all the NS you forward to shouldn't be doing it.