0

T-Com VOIP not working with EDNS-clientsubnet

When enabling EDNS-clientsubnet support, I can observe following:

This is without EDNS-option, and working answer:

nico@debian01:~$ dig _sips._tcp.tel.t-online.de srv @45.90.28.203

; <<>> DiG 9.16.33-Debian <<>> _sips._tcp.tel.t-online.de srv @45.90.28.203
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8152
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;_sips._tcp.tel.t-online.de.    IN      SRV

;; ANSWER SECTION:
_sips._tcp.tel.t-online.de. 30  IN      SRV     30 0 5061 d-eps-110.edns.t-ipnet.de.
_sips._tcp.tel.t-online.de. 30  IN      SRV     20 0 5061 h2-eps-110.edns.t-ipnet.de.
_sips._tcp.tel.t-online.de. 30  IN      SRV     10 0 5061 do-eps-110.edns.t-ipnet.de.

;; Query time: 11 msec
;; SERVER: 45.90.28.203#53(45.90.28.203)
;; WHEN: Mon Jan 09 18:46:26 CET 2023
;; MSG SIZE  rcvd: 192

nico@debian01:~$ dig _sip._udp.tel.t-online.de srv @45.90.28.203

; <<>> DiG 9.16.33-Debian <<>> _sip._udp.tel.t-online.de srv @45.90.28.203
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28569
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;_sip._udp.tel.t-online.de.     IN      SRV

;; ANSWER SECTION:
_sip._udp.tel.t-online.de. 30   IN      SRV     30 0 5060 d-epp-110.edns.t-ipnet.de.
_sip._udp.tel.t-online.de. 30   IN      SRV     10 0 5060 do-epp-110.edns.t-ipnet.de.
_sip._udp.tel.t-online.de. 30   IN      SRV     20 0 5060 h2-epp-110.edns.t-ipnet.de.

;; Query time: 15 msec
;; SERVER: 45.90.28.203#53(45.90.28.203)
;; WHEN: Mon Jan 09 18:48:46 CET 2023
;; MSG SIZE  rcvd: 191

When I turn on that option, this is what I get:

nico@debian01:~$ dig _sips._tcp.tel.t-online.de srv @45.90.28.203

; <<>> DiG 9.16.33-Debian <<>> _sips._tcp.tel.t-online.de srv @45.90.28.203
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49602
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;_sips._tcp.tel.t-online.de.    IN      SRV

;; AUTHORITY SECTION:
_sips._tcp.tel.t-online.de. 3600 IN     SOA     ns1.edns.t-ipnet.de. hostmaster.t-ipnet.net. 2018022700 43200 1800 1209600 21600

;; Query time: 39 msec
;; SERVER: 45.90.28.203#53(45.90.28.203)
;; WHEN: Mon Jan 09 18:50:20 CET 2023
;; MSG SIZE  rcvd: 130

nico@debian01:~$ dig _sip._udp.tel.t-online.de srv @45.90.28.203

; <<>> DiG 9.16.33-Debian <<>> _sip._udp.tel.t-online.de srv @45.90.28.203
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33685
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;_sip._udp.tel.t-online.de.     IN      SRV

;; ANSWER SECTION:
_sip._udp.tel.t-online.de. 823  IN      SRV     20 0 5060 h2-eph-755.edns.t-ipnet.de.
_sip._udp.tel.t-online.de. 823  IN      SRV     10 0 5060 f-eph-754.edns.t-ipnet.de.

;; Query time: 11 msec
;; SERVER: 45.90.28.203#53(45.90.28.203)
;; WHEN: Mon Jan 09 18:50:40 CET 2023
;; MSG SIZE  rcvd: 145

The sips tcp request is missing an answer section completely, while sip udp is missing one entry.

These are required for registering the phone on the net.

 

Thanks for your support,

Don

8replies Oldest first
  • Oldest first
  • Newest first
  • Active threads
  • Popular
  • After two weeks a simple reaction would be nice to hear...

    Anyway, what I came across, making a new "empty" config, everything else in options turned off, no other tweaks done and insisting to use the Nextdns-client for linux for encryption, it is impossible to get an uncrippled answer from your service:

    First answer is okay though:

    ico@raspi2:~ $ dig _sips._tcp.tel.t-online.de srv @127.0.0.1 -p 6053
    
    ; <<>> DiG 9.16.33-Raspbian <<>> _sips._tcp.tel.t-online.de srv @127.0.0.1 -p 6053
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36769
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
    
    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 1232
    ;; QUESTION SECTION:
    ;_sips._tcp.tel.t-online.de.    IN      SRV
    
    ;; ANSWER SECTION:
    _sips._tcp.tel.t-online.de. 30  IN      SRV     30 0 5061 d-eps-110.edns.t-ipnet.de.
    _sips._tcp.tel.t-online.de. 30  IN      SRV     10 0 5061 n-eps-110.edns.t-ipnet.de.
    _sips._tcp.tel.t-online.de. 30  IN      SRV     20 0 5061 h2-eps-110.edns.t-ipnet.de.
    
    ;; Query time: 509 msec
    ;; SERVER: 127.0.0.1#6053(127.0.0.1)
    ;; WHEN: Wed Jan 25 22:58:28 CET 2023
    ;; MSG SIZE  rcvd: 191
    
    

    Succeeding answers result in this:

    nico@raspi2:~ $ dig _sips._tcp.tel.t-online.de srv @127.0.0.1 -p 6053  ; <<>> DiG 9.16.33-Raspbian <<>> _sips._tcp.tel.t-online.de srv @127.0.0.1 -p 6053
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26716
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1  ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 1232
    ;; QUESTION SECTION:
    ;_sips._tcp.tel.t-online.de.    IN      SRV  ;; AUTHORITY SECTION:
    _sips._tcp.tel.t-online.de. 953 IN      SOA     ns1.edns.t-ipnet.de. hostmaster.t-ipnet.net. 2018022700 43200 1800 1209600 21600  ;; Query time: 0 msec
    ;; SERVER: 127.0.0.1#6053(127.0.0.1)
    ;; WHEN: Wed Jan 25 23:09:43 CET 2023
    ;; MSG SIZE  rcvd: 130
    
    


    Interestingly though is, that when I use unencrypted test to you, it works. It doesn't when using AdGuardHome through QUIC. (or any other encrypted mode).

    Well, I might be just some user, that has a problem, but you've banned with this every German T-Com VOIP user,  who likes encrypted DNS and is using your service.

    Solution was to disable encrypted mode, but come on, it is not wanted by you to have different answers using different modes...

    Please invest!!

    Don

    Like
  • Please use `dig +tcp chaos …` for all your test queries so we can see what ECS prefix is sent.

    Like
  • Sure, no problem:

    ; <<>> DiG 9.16.33-Raspbian <<>> +tcp chaos _sips._tcp.tel.t-online.de srv @127.0.0.1 -p 6053
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35818
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 9
    
    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 1232
    ;; QUESTION SECTION:
    ;_sips._tcp.tel.t-online.de.    CH      SRV
    
    ;; ANSWER SECTION:
    _sips._tcp.tel.t-online.de. 30  IN      SRV     20 0 5061 h2-eps-110.edns.t-ipnet.de.
    _sips._tcp.tel.t-online.de. 30  IN      SRV     30 0 5061 d-eps-110.edns.t-ipnet.de.
    _sips._tcp.tel.t-online.de. 30  IN      SRV     10 0 5061 do-eps-110.edns.t-ipnet.de.
    
    ;; ADDITIONAL SECTION:
    client-name.nextdns.io. 0       CH      TXT     "nextdns-cli"
    device-name.nextdns.io. 0       CH      TXT     "YY"
    proto.nextdns.io.       0       CH      TXT     "DOH"
    server.nextdns.io.      0       CH      TXT     "zepto-fra-1"
    profile.nextdns.io.     0       CH      TXT     "XXXX"
    client.nextdns.io.      0       CH      TXT     "XXXX"
    device-id.nextdns.io.   0       CH      TXT     "XXXX"
    smart-ecs.nextdns.io.   0       CH      TXT     "not sent"
    
    ;; Query time: 500 msec
    ;; SERVER: 127.0.0.1#6053(127.0.0.1)
    ;; WHEN: Thu Jan 26 22:45:15 CET 2023
    ;; MSG SIZE  rcvd: 492
    
    nico@raspi2:~ $ dig +tcp chaos _sips._tcp.tel.t-online.de srv @127.0.0.1 -p 6053
    ;; Warning: Message parser reports malformed message packet.
    
    ; <<>> DiG 9.16.33-Raspbian <<>> +tcp chaos _sips._tcp.tel.t-online.de srv @127.0.0.1 -p 6053
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30995
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 9
    
    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 1232
    ;; QUESTION SECTION:
    ;_sips._tcp.tel.t-online.de.    CH      SRV
    
    ;; AUTHORITY SECTION:
    _sips._tcp.tel.t-online.de. 81  IN      SOA     ns1.edns.t-ipnet.de. hostmaster.t-ipnet.net. 2018022700 43200 1800 1209600 21600
    
    ;; ADDITIONAL SECTION:
    server.nextdns.io.      0       CH      TXT     "exoscale-muc-1"
    profile.nextdns.io.     0       CH      TXT     "XXXX"
    client.nextdns.io.      0       CH      TXT     "XXXX"
    client-name.nextdns.io. 0       CH      TXT     "nextdns-cli"
    proto.nextdns.io.       0       CH      TXT     "DOH"
    device-name.nextdns.io. 0       CH      TXT     "YY"
    device-id.nextdns.io.   0       CH      TXT     "XXXX"
    smart-ecs.nextdns.io.   0       CH      TXT     "not sent"
    
    ;; Query time: 20 msec
    ;; SERVER: 127.0.0.1#6053(127.0.0.1)
    ;; WHEN: Thu Jan 26 22:45:58 CET 2023
    ;; MSG SIZE  rcvd: 433
    

    See, this config does not even use ECS. I've restarted nextdns-cli, afterwards first answer is fine, subsequent are missing an answer section.

    The profile has every bit of protection including CNAME filtering set to OFF. Your unencrypted DNS-servers are replying correctly though.

    There must be a bug in your system somewhere....

    Like
    • Donald Musgraves if ECS is not sent, it means it is not enabled in your profile. Are you sure those requests are going to the right profile?

      Like
  • Excuse me, I cannot update the thread title. At first I was assuming, it had to do with ECS enabled or not. But it turned out that this was wrong. I came now to the conclusion, that after a restart of nextdns-cli the right answer only comes ONCE. Every subsquent query has an answer section missing completely. Thats results in VOIP phones losing their registration.

    I've illustrated this behaviour in my last example above!

    Like
    • Donald Musgraves you only reproduce the issue with the CLI? Which version are you running?

      Like
      • R P M
      • R_P_M
      • 8 days ago
      • Reported - view

      Donald Musgraves There must be some problem with the cached response. Maybe try disabling the cache and see if it works then?

      Like
  • YES! You are right, it is a problem with the nextdns-cli cache! After disabling that, subsequent responses are all allright! Now that takes me really further...

    But still, NextDns-QUIC answers using different systems are still wrong!

    That bug is so easily reproducible, you will find the culprit soon I hope. This must be a server-side bug, as all cache has been disabled and other vendors are responding nicely.

    Thanks R P M for pointing me to the cache!!

    Like 1
Like Follow
  • 8 days agoLast active
  • 8Replies
  • 58Views
  • 3 Following