DNSSec Issue with Parler

Hi there! I am looking into why Parler.com and par.dw aren’t working and it appears using https://dnsviz.net/ it has to do a few things, primarily the DNSSEC signing algorithm as well as with par.dw the expiration field is in the past.

For algorithm, is ED25519 the de facto standard now? Would you advise that this is the problem?

Regards, and thank you!

Patrick

I have also been unable to resolve parler.com or par.pw from Cloudflare’s DNS (and OpenDNS, for what it’s worth). Requested troubleshooting data follows:

    ; <<>> DiG 9.10.6 <<>> parler.com @1.1.1.1

    ;; global options: +cmd

    ;; Got answer:

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

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

    ;; OPT PSEUDOSECTION:

    ; EDNS: version: 0, flags:; udp: 1232

    ; OPT=15: 00 06 ("..")

    ;; QUESTION SECTION:

    ;parler.com. IN A

    ;; Query time: 57 msec

    ;; SERVER: 1.1.1.1#53(1.1.1.1)

    ;; WHEN: Tue Apr 06 11:29:31 PDT 2021

    ;; MSG SIZE rcvd: 45

; <<>> DiG 9.10.6 <<>> parler.com @1.0.0.1

;; global options: +cmd

;; Got answer:

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

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

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 1232

; OPT=15: 00 06 ("..")

;; QUESTION SECTION:

;parler.com. IN A

;; Query time: 64 msec

;; SERVER: 1.0.0.1#53(1.0.0.1)

;; WHEN: Tue Apr 06 11:35:11 PDT 2021

;; MSG SIZE rcvd: 45

; <<>> DiG 9.10.6 <<>> parler.com @8.8.8.8

;; global options: +cmd

;; Got answer:

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

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

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 512

;; QUESTION SECTION:

;parler.com. IN A

;; ANSWER SECTION:

parler.com. 204 IN A 216.246.208.249

;; Query time: 63 msec

;; SERVER: 8.8.8.8#53(8.8.8.8)

;; WHEN: Tue Apr 06 11:35:50 PDT 2021

;; MSG SIZE rcvd: 55

dig +short CHAOS TXT id.server @1.1.1.1
"SEA"

dig +short CHAOS TXT id.server @1.0.0.1
"SEA"

dig @ns3.Cloudflare.com whoami.Cloudflare.com txt +short 
"76.22.10.216"

For some reason, when using 1.1.1.1 whether over DoT, DoH, or regular DNS, I cannot resolve Parler.com

I hope this is not some sort of political issue on CloudFlares part. I did check other DNS servers such as Googles 8.8.8.8 and even my ISP’s DNS servers and they both resolve parler.com just fine.

I am just a user of the DNS, so I cannot say what goes on with Parler’s servers or CloudFlare’s servers. But it does seem odd to me.

Richard Wessels
Conroe, TX, USA

It doesn’t seem to work because ns1/2.parler.com nameservers respond with truncation to DNSKEY queries over UDP (because oversize), but then don’t accept retries over TCP:

$ kdig NS parler.com @a.gtld-servers.net
...
;; ADDITIONAL SECTION:
ns1.parler.com.     	172800	IN	A	216.246.208.246
ns2.parler.com.     	172800	IN	A	216.246.208.247

$ kdig @216.246.208.246 parler.com DNSKEY +bufsize=1452 +dnssec +retry=1
;; WARNING: truncated reply from [email protected](UDP), retrying over TCP
;; WARNING: connection timeout for [email protected](TCP)
;; WARNING: truncated reply from [email protected](UDP), retrying over TCP
;; WARNING: connection timeout for [email protected](TCP)
;; ERROR: failed to query server [email protected](UDP)

TCP support is not optional since RFC 7766 - DNS Transport over TCP - Implementation Requirements
I’ll try to send them an email to see if we can fix it.

2 Likes

This post was flagged by the community and is temporarily hidden.

I am not an expert on DNS, but I do work in IT. I suspect that DNS over TCP is a requirement these days because of DNS over HTTPS support requirements? I still think DNS over TLS via UDP is a more elegant solution, but c’est la vie… Many thanks for the reply, at least I now know what is going on and that I am not going crazy.

I wonder what other issues and what other services and sites will suffer similar issues as we move towards more and stronger implementations of DoH and DoT…

Only the future knows.

This topic was automatically closed 5 days after the last reply. New replies are no longer allowed.

@rorw this is an issue with sending plaintext DNS to authoritative DNS servers - RFC 7766 requires both TCP and UDP to work:

5. Transport Protocol Selection

Section 6.1.3.2 of [RFC1123] is updated: All general-purpose DNS implementations MUST support both UDP and TCP transport.