Re: Claro Brazil contact

2024-03-15 Thread Scott Q. 
Thanks, already got confirmation there is an issue.

For all others chasing this, there is a routing issue between Arelion
and Claro. Claro is aware and working on the issue.

On Friday, 15/03/2024 at 17:02 Alessandro Martins wrote:




Hey there,

It seems like Claro's NOC phone number is all good in PeeringDB
- https://www.peeringdb.com/net/2680
Simply dial +552121212900, and a member of the NOC team will promptly
assist you.

Thanks, 











--
Alessandro Martins





On Fri, Mar 15, 2024 at 5:17 PM Scott Q.  wrote:




Thanks, indeed Dany just got back to us via e-mail.

Are you sure the phone number is correct ? +55 is Brazil , 21 is Rio
but it's written 3 times in a row ( +5521212129004230100 ). In any
case, I tried calling the number and it gave an error.


On Friday, 15/03/2024 at 14:11 Pedro Prado wrote:



Hey Scott, I validated those to be correct. They said Dany is the
right contact. Did you try e-mailing him?

Pedro





On 15 Mar 2024, at 15:45, Scott Q.  wrote:

Anyone knows a direct contact for Claro Brazil ?


The phone number for their NOC on PeeringDB doesn't work or make sense
and e-mails are ignored.


Thank you

Re: Claro Brazil contact

2024-03-15 Thread Alessandro Martins 
Hey there,

It seems like Claro's NOC phone number is all good in PeeringDB -
https://www.peeringdb.com/net/2680

Simply dial +552121212900, and a member of the NOC team will promptly
assist you.

Thanks,

--
Alessandro Martins



On Fri, Mar 15, 2024 at 5:17 PM Scott Q.  wrote:

> Thanks, indeed Dany just got back to us via e-mail.
>
> Are you sure the phone number is correct ? +55 is Brazil , 21 is Rio but
> it's written 3 times in a row ( +5521212129004230100 ). In any case, I
> tried calling the number and it gave an error.
>
>
> On Friday, 15/03/2024 at 14:11 Pedro Prado wrote:
>
> Hey Scott, I validated those to be correct. They said Dany is the right
> contact. Did you try e-mailing him?
>
> Pedro
>
> On 15 Mar 2024, at 15:45, Scott Q.  wrote:
>
> Anyone knows a direct contact for Claro Brazil ?
>
> The phone number for their NOC on PeeringDB doesn't work or make sense and
> e-mails are ignored.
>
> Thank you
>
>
>

Re: Claro Brazil contact

2024-03-15 Thread Pedro Prado 


> On 15 Mar 2024, at 20:15, Scott Q.  wrote:
> 
> Thanks, indeed Dany just got back to us via e-mail.
> 
Glad to know!

> Are you sure the phone number is correct ? +55 is Brazil , 21 is Rio but it's 
> written 3 times in a row ( +5521212129004230100 ). In any case, I tried 
> calling the number and it gave an error.
> 
Claro acquired Embratel, an operator whose code is 21 - their number is 
actually 21212900. Then you add Rio and Brazil and get +55 21 21212900. But I 
have no idea about the extra digits…

> 
> On Friday, 15/03/2024 at 14:11 Pedro Prado wrote:
> Hey Scott, I validated those to be correct. They said Dany is the right 
> contact. Did you try e-mailing him?
> 
> Pedro
> 
>> On 15 Mar 2024, at 15:45, Scott Q. > > wrote:
>> 
>> Anyone knows a direct contact for Claro Brazil ?
>> 
>> The phone number for their NOC on PeeringDB doesn't work or make sense and 
>> e-mails are ignored.
>> 
>> Thank you
> 
>

Re: Claro Brazil contact

2024-03-15 Thread Scott Q. 
Thanks, indeed Dany just got back to us via e-mail.

Are you sure the phone number is correct ? +55 is Brazil , 21 is Rio
but it's written 3 times in a row ( +5521212129004230100 ). In any
case, I tried calling the number and it gave an error.


On Friday, 15/03/2024 at 14:11 Pedro Prado wrote:



Hey Scott, I validated those to be correct. They said Dany is the
right contact. Did you try e-mailing him?

Pedro





On 15 Mar 2024, at 15:45, Scott Q.  wrote:

Anyone knows a direct contact for Claro Brazil ?


The phone number for their NOC on PeeringDB doesn't work or make sense
and e-mails are ignored.


Thank you

Re: DNSSEC & WIldcards

2024-03-15 Thread Mark Andrews 
Yep. Look for an upgrade then file a bug report if not fixed by the upgrade.  
It should be < 10 minutes work to fix + tests etc. 

-- 
Mark Andrews

> On 16 Mar 2024, at 05:18, Bjørn Mork  wrote:
> Dennis Burgess  writes:
> 
>> Looks like Bjorn was correct, one two many signatures ☹ Removed one
>> and its all fixed!  Thanks too all that replied!!
> 
> Glad to hear that.  But do note that Mark is right, of course.  The real
> problem is a bug in your name server.  What you have now is a workaround
> as solid as a house made of straw.
> 
> 
> Bjørn

Re: Consolidated Communications contact?

2024-03-15 Thread Bryan Holloway 
Thanks to all who have already responded ... probably should've 
mentioned the AS number, since they appear to have many:


AS25660


On 3/15/24 19:59, Bryan Holloway wrote:
If anyone from Consolidated Communications is lurking, could you please 
contact me off-list?


We have a mutual customer with a strange routing issue between our two 
networks.


Thanks!
     - bryan

Consolidated Communications contact?

2024-03-15 Thread Bryan Holloway 
If anyone from Consolidated Communications is lurking, could you please 
contact me off-list?


We have a mutual customer with a strange routing issue between our two 
networks.


Thanks!
- bryan

Re: DNSSEC & WIldcards

2024-03-15 Thread Bjørn Mork 
Dennis Burgess  writes:

> Looks like Bjorn was correct, one two many signatures ☹ Removed one
> and its all fixed!  Thanks too all that replied!!

Glad to hear that.  But do note that Mark is right, of course.  The real
problem is a bug in your name server.  What you have now is a workaround
as solid as a house made of straw.


Bjørn

RE: DNSSEC & WIldcards

2024-03-15 Thread Dennis Burgess via NANOG 
Looks like Bjorn was correct, one two many signatures ☹  Removed one and its 
all fixed!  Thanks too all that replied!!  

-Original Message-
From: Bjørn Mork  
Sent: Friday, March 15, 2024 12:59 PM
To: Dennis Burgess via NANOG 
Cc: Dennis Burgess 
Subject: Re: DNSSEC & WIldcards

Looks like your DNS server correctly queues up the RRs, but erronously believes 
it can drop data from the Authority section without setting the TC bit.

Reducing the bufsize so the answer doesn't fit makes trucation work:

bjorn@miraculix:~$ dig a www.app.linktechs.net. +dnssec +multiline +norecur 
@139.60.210.20 +bufsize=512 ;; Truncated, retrying in TCP mode.

; <<>> DiG 9.18.24-1-Debian <<>> a www.app.linktechs.net. +dnssec +multiline 
+norecur @139.60.210.20 +bufsize=512 ;; global options: +cmd ;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5946 ;; flags: qr aa; 
QUERY: 1, ANSWER: 3, AUTHORITY: 3, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1280 ;; QUESTION SECTION:
;www.app.linktechs.net. IN A

;; ANSWER SECTION:
www.app.linktechs.net.  3600 IN A 139.60.210.81 www.app.linktechs.net.  3600 IN 
RRSIG A 8 3 3600 (
20240427232616 20240313222616 37041 
linktechs.net.
NYC/4H2VZg12vj+tiWVkEROhXwm7JkBna6RQg6LO8kXr
oosDUpGnxrgOtJYsWYbYfM58opiC1OeAbcaCB9+nctIU
grrwcpuhmvlXYLZi1n/oAmelPldnQ6Hf93HuHi4ULFsS
Qfsoo8sdfjt/YSJ4WxjmsM9LMbZ2CZPMU44a3MdftGW1
fNKmZ1fLtVreP41KmvP6b01lyUMvjrvT26Yq57DgUDTo
iqU5skT+OHzx6ERJkt3tzzwm2pBMvBWFDXC668NtouIW
s3mrhJRBuNW3xSCsroaLQ0vmdml2BqNNh7MZNc38FNMJ
eh+ts3mbMnOOkzlI1Q8gKMMCWv+VRmv2DA== ) 
www.app.linktechs.net.  3600 IN RRSIG A 8 3 3600 (
20240427232616 20240313222616 11340 
linktechs.net.
Th3OcZwOMNUb1zMdipnTnFdgFEaOGJ/VofQOTyxmnNCg
wl+1Q7eiQ89KHAWEDBisxd0S+EHu6/YBWY2srNx5q58P
XIZJ9oQXCqDLzSE884DTQNDEVrSMoKJ9slRU4N4Lj5tT
9LzbODmCM9ytRavOKXJHIddQa0MZT4p9cV8K2HI7XSFX
0rjieKFa7wDRJqhKyqrT3Rh/S93pavhKWUgN3GVO6hkI
H5F67UFpZK7o7nRlyqvM42ep5XaRZS/WJtLuXcTk/QM3
MBPTDWgJ0Bh8qpNuHDOb2XFH2I5dwjeKxuYCzeQzN1hL
gsmw3d1J2pNsYbC40jmi1bZr0bz2fDurIA== )

;; AUTHORITY SECTION:
_acme-challenge.app.linktechs.net. 1200 IN NSEC auto.linktechs.net. TXT RRSIG 
NSEC _acme-challenge.app.linktechs.net. 1200 IN RRSIG NSEC 8 4 1200 (
20240427232616 20240313222616 11340 
linktechs.net.
grjacRLmt+h5UMJkWMgrxeeY4m8kzNCokMsEFAi/10ld
2zcx7IZnB5oljSoZo2ZoqN0DEWVOrORGaU0kAcXDIwmD
89JG728W78+gikb8D+rpcSejfpAO8tRFO9saPSDY72uk
oP0Wle87oMcKmP9EXGcgsTZhd6Dld9qcAlUByGAZC/bi
SL5SDeALjpdqzXPXivP597VyJGakeEEjW0y2SmUOIDcg
6lOcSGX1QdmbaiHyAxHSjBsg4VV2Qpo2Br75xyfw3o1Z
oHMeacsAhhz5HQhtzv9DzULzmtmoA5sQn2VyBm2kcS+S
ZKpKioFnHj9BtOv3dn/F5hrQFhEInNPROw== ) 
_acme-challenge.app.linktechs.net. 1200 IN RRSIG NSEC 8 4 1200 (
20240427232616 20240313222616 37041 
linktechs.net.
bt6W5P4VDC5fs2r/lxwSnI8bhqS2MH7n67Gd2EK6+DDx
HYy9MAmSZEy2OYGg7QHamrWr2I+Bq2Og8A0bRRA5TitQ
VcWyq3b+VpXUPukg7bmXl4KRNGxdAB8NysoOT75yvPTe
Jy1baNzYv9/in6rf8VKXUrKSPUqcAsK3Sz5QHkuzzaIP
d+u5m59DAlobNi17QbRGKIQaXTtgkSHpj4rt61MMEzpB
JDXE5FRLCJ4pqQPm+DcF0ZrKoYqKv/1rYZSVbW3rY0XB
VEBDVy5MJg0YenhbVPcDM9OYh2dfvh5ZvYS6xsXZulv8
mKnjdJo7v6qAzPNvIhymghM+0Tp8INxAjw== )

;; Query time: 120 msec
;; SERVER: 139.60.210.20#53(139.60.210.20) (TCP) ;; WHEN: Fri Mar 15 18:57:20 
CET 2024 ;; MSG SIZE  rcvd: 1326


And directly using tcp also works:

bjorn@miraculix:~$ dig a www.app.linktechs.net. +dnssec +multiline +norecur 
@139.60.210.20 +vc

; <<>> DiG 9.18.24-1-Debian <<>> a www.app.linktechs.net. +dnssec +multiline 
+norecur @139.60.210.20 +vc ;; global options: +cmd ;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29513 ;; flags: qr aa; 
QUERY: 1, ANSWER: 3, AUTHORITY: 3, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1280 ;; QUESTION SECTION:
;www.app.linktechs.net. IN A

;; ANSWER SECTION:
www.app.linktechs.net.  3600 IN A 139.60.210.81 www.app.linktechs.net.  3600 IN 
RRSIG A

Re: Claro Brazil contact

2024-03-15 Thread Pedro Prado 
Hey Scott, I validated those to be correct. They said Dany is the right 
contact. Did you try e-mailing him?

Pedro

> On 15 Mar 2024, at 15:45, Scott Q.  wrote:
> 
> Anyone knows a direct contact for Claro Brazil ?
> 
> The phone number for their NOC on PeeringDB doesn't work or make sense and 
> e-mails are ignored.
> 
> Thank you

Re: DNSSEC & WIldcards

2024-03-15 Thread Mark Andrews 
Wildcards and DNSSEC work fine as long as the nameserver vendor has not stuffed 
up. Too many vendors play fast and loose with the DNS protocol.  Getting this 
correct is not hard but you do need to test before shipping.  Additionally OS 
vendors tend to be way behind current releases from the nameserver vendors. 

-- 
Mark Andrews

> On 16 Mar 2024, at 04:33, Bjørn Mork  wrote:
> 
> Dennis Burgess via NANOG  writes:
> 
>> So have *.app.linktechs.net that I have been trying to get to work, we
>> have DNSSEC on this, and its failing, but cannot for the life of me
>> understand why.  I think it may have something to do with proving it
>> exists as a wildcard, but any DNSSEC experts want to take a stab at it
>> ?
> 
> Not an expert, but Google knows the answer (as always :-)
> 
> bjorn@miraculix:~$ dig a www.app.linktechs.net. +dnssec +multiline @8.8.8.8
> 
> ; <<>> DiG 9.18.24-1-Debian <<>> a www.app.linktechs.net. +dnssec +multiline 
> @8.8.8.8
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 65184
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags: do; udp: 512
> ; EDE: 10 (RRSIGs Missing): (For _acme-challenge.app.linktechs.net/nsec)
> ;; QUESTION SECTION:
> ;www.app.linktechs.net. IN A
> 
> ;; Query time: 156 msec
> ;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)
> ;; WHEN: Fri Mar 15 18:26:16 CET 2024
> ;; MSG SIZE  rcvd: 98
> 
> 
> 
> And they're right.  Your server includes the epected NSEC record, but
> leaves out the associated RRSIG.  Compare this to the
> https://datatracker.ietf.org/doc/html/rfc7129#section-5.3 example:
> 
> 
> bjorn@miraculix:~$ dig a www.app.linktechs.net. +dnssec +multiline 
> @139.60.210.20 
> 
> ; <<>> DiG 9.18.24-1-Debian <<>> a www.app.linktechs.net. +dnssec +multiline 
> @139.60.210.20
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11828
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 1, ADDITIONAL: 1
> ;; WARNING: recursion requested but not available
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags: do; udp: 1280
> ;; QUESTION SECTION:
> ;www.app.linktechs.net. IN A
> 
> ;; ANSWER SECTION:
> www.app.linktechs.net.  3600 IN A 139.60.210.81
> www.app.linktechs.net.  3600 IN RRSIG A 8 3 3600 (
>20240427232616 20240313222616 37041 
> linktechs.net.
>NYC/4H2VZg12vj+tiWVkEROhXwm7JkBna6RQg6LO8kXr
>oosDUpGnxrgOtJYsWYbYfM58opiC1OeAbcaCB9+nctIU
>grrwcpuhmvlXYLZi1n/oAmelPldnQ6Hf93HuHi4ULFsS
>Qfsoo8sdfjt/YSJ4WxjmsM9LMbZ2CZPMU44a3MdftGW1
>fNKmZ1fLtVreP41KmvP6b01lyUMvjrvT26Yq57DgUDTo
>iqU5skT+OHzx6ERJkt3tzzwm2pBMvBWFDXC668NtouIW
>s3mrhJRBuNW3xSCsroaLQ0vmdml2BqNNh7MZNc38FNMJ
>eh+ts3mbMnOOkzlI1Q8gKMMCWv+VRmv2DA== )
> www.app.linktechs.net.  3600 IN RRSIG A 8 3 3600 (
>20240427232616 20240313222616 11340 
> linktechs.net.
>Th3OcZwOMNUb1zMdipnTnFdgFEaOGJ/VofQOTyxmnNCg
>wl+1Q7eiQ89KHAWEDBisxd0S+EHu6/YBWY2srNx5q58P
>XIZJ9oQXCqDLzSE884DTQNDEVrSMoKJ9slRU4N4Lj5tT
>9LzbODmCM9ytRavOKXJHIddQa0MZT4p9cV8K2HI7XSFX
>0rjieKFa7wDRJqhKyqrT3Rh/S93pavhKWUgN3GVO6hkI
>H5F67UFpZK7o7nRlyqvM42ep5XaRZS/WJtLuXcTk/QM3
>MBPTDWgJ0Bh8qpNuHDOb2XFH2I5dwjeKxuYCzeQzN1hL
>gsmw3d1J2pNsYbC40jmi1bZr0bz2fDurIA== )
> 
> ;; AUTHORITY SECTION:
> _acme-challenge.app.linktechs.net. 1200 IN NSEC auto.linktechs.net. TXT RRSIG 
> NSEC
> 
> ;; Query time: 120 msec
> ;; SERVER: 139.60.210.20#53(139.60.210.20) (UDP)
> ;; WHEN: Fri Mar 15 18:27:13 CET 2024
> ;; MSG SIZE  rcvd: 724
> 
> 
> 
> Lots of resolvers will probably just look up that NSEC, get the RRSIG
> and be happy with that.  But your problem is that there always will be a
> number of resolvers not doing that.  So you get arbitrary failures.
> 
> I believe there are so many examples of really bad fallout due to
> wildcards combined with DNSSEC that it's advisable to stay away. Do one
> or the other.  Not both.
> 
> 
> 
> Bjørn

Weekly Global IPv4 Routing Table Report

2024-03-15 Thread Routing Table Analysis Role Account 
This is an automated weekly mailing describing the state of the Global
IPv4 Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG
UKNOF, TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG.

Daily listings are sent to bgp-st...@lists.apnic.net.

For historical data, please see https://thyme.apnic.net.

If you have any comments please contact Philip Smith .

IPv4 Routing Table Report   04:00 +10GMT Sat 16 Mar, 2024

  BGP Table (Global) as seen in Japan.

Report Website: https://thyme.apnic.net
Detailed Analysis:  https://thyme.apnic.net/current/

Analysis Summary


BGP routing table entries examined:  938832
Prefixes after maximum aggregation (per Origin AS):  359054
Deaggregation factor:  2.61
Unique aggregates announced (without unneeded subnets):  458136
Total ASes present in the Internet Routing Table: 75465
Prefixes per ASN: 12.44
Origin-only ASes present in the Internet Routing Table:   64728
Origin ASes announcing only one prefix:   26585
Transit ASes present in the Internet Routing Table:   10737
Transit-only ASes present in the Internet Routing Table:488
Average AS path length visible in the Internet Routing Table:   4.3
Max AS path length visible:  55
Max AS path prepend of ASN (265020)  50
Prefixes from unregistered ASNs in the Routing Table:  1087
Number of instances of unregistered ASNs:  1089
Number of 32-bit ASNs allocated by the RIRs:  43832
Number of 32-bit ASNs visible in the Routing Table:   35997
Prefixes from 32-bit ASNs in the Routing Table:  182589
Number of bogon 32-bit ASNs visible in the Routing Table:19
Special use prefixes present in the Routing Table:1
Prefixes being announced from unallocated address space:569
Number of addresses announced to Internet:   3026729344
Equivalent to 180 /8s, 104 /16s and 57 /24s
Percentage of available address space announced:   81.8
Percentage of allocated address space announced:   81.8
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   99.6
Total number of prefixes smaller than registry allocations:  309574

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   248975
Total APNIC prefixes after maximum aggregation:   73037
APNIC Deaggregation factor:3.41
Prefixes being announced from the APNIC address blocks:  241635
Unique aggregates announced from the APNIC address blocks:99927
APNIC Region origin ASes present in the Internet Routing Table:   14046
APNIC Prefixes per ASN:   17.20
APNIC Region origin ASes announcing only one prefix:   4252
APNIC Region transit ASes present in the Internet Routing Table:   1882
Average APNIC Region AS path length visible:4.4
Max APNIC Region AS path length visible: 32
Number of APNIC region 32-bit ASNs visible in the Routing Table:   9417
Number of APNIC addresses announced to Internet:  760791168
Equivalent to 45 /8s, 88 /16s and 192 /24s
APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
   58368-59391, 63488-64098, 64297-64395, 131072-153913
APNIC Address Blocks 1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
   106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
   116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
   123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8,
   163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8,
   203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8,
   222/8, 223/8,

ARIN Region Analysis Summary


Prefixes being announced by ARIN Region ASes:274840
Total ARIN prefixes after maximum aggregation:   124033
ARIN Deaggregation factor: 2.22
Prefixes being announced from the ARIN address blocks:   279590
Unique aggregates announced from the ARIN address blocks:132782
ARIN Region origin ASes present in the Internet Routing Table:19110
ARIN Prefixes per ASN:

Re: DNSSEC & WIldcards

2024-03-15 Thread Bjørn Mork 
Looks like your DNS server correctly queues up the RRs, but erronously
believes it can drop data from the Authority section without setting the
TC bit.

Reducing the bufsize so the answer doesn't fit makes trucation work:

bjorn@miraculix:~$ dig a www.app.linktechs.net. +dnssec +multiline +norecur 
@139.60.210.20 +bufsize=512
;; Truncated, retrying in TCP mode.

; <<>> DiG 9.18.24-1-Debian <<>> a www.app.linktechs.net. +dnssec +multiline 
+norecur @139.60.210.20 +bufsize=512
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5946
;; flags: qr aa; QUERY: 1, ANSWER: 3, AUTHORITY: 3, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1280
;; QUESTION SECTION:
;www.app.linktechs.net. IN A

;; ANSWER SECTION:
www.app.linktechs.net.  3600 IN A 139.60.210.81
www.app.linktechs.net.  3600 IN RRSIG A 8 3 3600 (
20240427232616 20240313222616 37041 
linktechs.net.
NYC/4H2VZg12vj+tiWVkEROhXwm7JkBna6RQg6LO8kXr
oosDUpGnxrgOtJYsWYbYfM58opiC1OeAbcaCB9+nctIU
grrwcpuhmvlXYLZi1n/oAmelPldnQ6Hf93HuHi4ULFsS
Qfsoo8sdfjt/YSJ4WxjmsM9LMbZ2CZPMU44a3MdftGW1
fNKmZ1fLtVreP41KmvP6b01lyUMvjrvT26Yq57DgUDTo
iqU5skT+OHzx6ERJkt3tzzwm2pBMvBWFDXC668NtouIW
s3mrhJRBuNW3xSCsroaLQ0vmdml2BqNNh7MZNc38FNMJ
eh+ts3mbMnOOkzlI1Q8gKMMCWv+VRmv2DA== )
www.app.linktechs.net.  3600 IN RRSIG A 8 3 3600 (
20240427232616 20240313222616 11340 
linktechs.net.
Th3OcZwOMNUb1zMdipnTnFdgFEaOGJ/VofQOTyxmnNCg
wl+1Q7eiQ89KHAWEDBisxd0S+EHu6/YBWY2srNx5q58P
XIZJ9oQXCqDLzSE884DTQNDEVrSMoKJ9slRU4N4Lj5tT
9LzbODmCM9ytRavOKXJHIddQa0MZT4p9cV8K2HI7XSFX
0rjieKFa7wDRJqhKyqrT3Rh/S93pavhKWUgN3GVO6hkI
H5F67UFpZK7o7nRlyqvM42ep5XaRZS/WJtLuXcTk/QM3
MBPTDWgJ0Bh8qpNuHDOb2XFH2I5dwjeKxuYCzeQzN1hL
gsmw3d1J2pNsYbC40jmi1bZr0bz2fDurIA== )

;; AUTHORITY SECTION:
_acme-challenge.app.linktechs.net. 1200 IN NSEC auto.linktechs.net. TXT RRSIG 
NSEC
_acme-challenge.app.linktechs.net. 1200 IN RRSIG NSEC 8 4 1200 (
20240427232616 20240313222616 11340 
linktechs.net.
grjacRLmt+h5UMJkWMgrxeeY4m8kzNCokMsEFAi/10ld
2zcx7IZnB5oljSoZo2ZoqN0DEWVOrORGaU0kAcXDIwmD
89JG728W78+gikb8D+rpcSejfpAO8tRFO9saPSDY72uk
oP0Wle87oMcKmP9EXGcgsTZhd6Dld9qcAlUByGAZC/bi
SL5SDeALjpdqzXPXivP597VyJGakeEEjW0y2SmUOIDcg
6lOcSGX1QdmbaiHyAxHSjBsg4VV2Qpo2Br75xyfw3o1Z
oHMeacsAhhz5HQhtzv9DzULzmtmoA5sQn2VyBm2kcS+S
ZKpKioFnHj9BtOv3dn/F5hrQFhEInNPROw== )
_acme-challenge.app.linktechs.net. 1200 IN RRSIG NSEC 8 4 1200 (
20240427232616 20240313222616 37041 
linktechs.net.
bt6W5P4VDC5fs2r/lxwSnI8bhqS2MH7n67Gd2EK6+DDx
HYy9MAmSZEy2OYGg7QHamrWr2I+Bq2Og8A0bRRA5TitQ
VcWyq3b+VpXUPukg7bmXl4KRNGxdAB8NysoOT75yvPTe
Jy1baNzYv9/in6rf8VKXUrKSPUqcAsK3Sz5QHkuzzaIP
d+u5m59DAlobNi17QbRGKIQaXTtgkSHpj4rt61MMEzpB
JDXE5FRLCJ4pqQPm+DcF0ZrKoYqKv/1rYZSVbW3rY0XB
VEBDVy5MJg0YenhbVPcDM9OYh2dfvh5ZvYS6xsXZulv8
mKnjdJo7v6qAzPNvIhymghM+0Tp8INxAjw== )

;; Query time: 120 msec
;; SERVER: 139.60.210.20#53(139.60.210.20) (TCP)
;; WHEN: Fri Mar 15 18:57:20 CET 2024
;; MSG SIZE  rcvd: 1326


And directly using tcp also works:

bjorn@miraculix:~$ dig a www.app.linktechs.net. +dnssec +multiline +norecur 
@139.60.210.20 +vc

; <<>> DiG 9.18.24-1-Debian <<>> a www.app.linktechs.net. +dnssec +multiline 
+norecur @139.60.210.20 +vc
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29513
;; flags: qr aa; QUERY: 1, ANSWER: 3, AUTHORITY: 3, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1280
;; QUESTION SECTION:
;www.app.linktechs.net. IN A

;; ANSWER SECTION:
www.app.linktechs.net.  3600 IN A 139.60.210.81
www.app.linktechs.net.  3600 IN RRSIG A 8 3 3600 (
20240427232616 20240313222616 37041 
linktechs.net.
NYC/4H2VZg12vj+tiWVkEROhXwm7JkBna6RQg6LO8kXr
oosDUpGnxrgOtJYsWYbYfM58opiC1OeAbcaCB9+nctIU
grrwcpuhmvlXYLZi1

Re: DNSSEC & WIldcards

2024-03-15 Thread Mark Andrews 
The authority section is the correct section for the NSEC. 

Ask the question using TCP.  I suspect that the server isn’t truncating the UDP 
response correctly.  If I’m right you will get RRSIGs for the NSEC added to the 
additional section. If not the zone needs to be resigned as they are missing.  
I’m answering from my phone or else I would look it up myself. 

-- 
Mark Andrews

> On 16 Mar 2024, at 04:36, Matthew Pounsett  wrote:
> 
> 
> 
> 
>> On Fri, Mar 15, 2024 at 11:26 AM Dennis Burgess via NANOG  
>> wrote:
>> So have *.app.linktechs.net that I have been trying to get to work, we have 
>> DNSSEC on this, and its failing, but cannot for the life of me understand 
>> why.  I think it may have something to do with proving it exists as a 
>> wildcard, but any DNSSEC experts want to take a stab at it ? 
>> 
> 
> As others have mentioned, the DNS-operations list would be a better place to 
> get help:  
> 
> But, right off the top I can see that your name server is returning the NSEC 
> record in the wrong section of the response.
>

Re: DNSSEC & WIldcards

2024-03-15 Thread Bjørn Mork 
Matthew Pounsett  writes:

> But, right off the top I can see that your name server is returning the
> NSEC record in the wrong section of the response.

No, the Authority section is correct here.  See:
https://datatracker.ietf.org/doc/html/rfc4035#section-3.1.3.3

But the RRSIG is missing.


Bjørn

Re: DNSSEC & WIldcards

2024-03-15 Thread Matthew Pounsett 
On Fri, Mar 15, 2024 at 11:26 AM Dennis Burgess via NANOG 
wrote:

> So have *.app.linktechs.net that I have been trying to get to work, we
> have DNSSEC on this, and its failing, but cannot for the life of me
> understand why.  I think it may have something to do with proving it exists
> as a wildcard, but any DNSSEC experts want to take a stab at it ?
>

As others have mentioned, the DNS-operations list would be a better place
to get help:  

But, right off the top I can see that your name server is returning the
NSEC record in the wrong section of the response.


>

Re: DNSSEC & WIldcards

2024-03-15 Thread Bjørn Mork 
Dennis Burgess via NANOG  writes:

> So have *.app.linktechs.net that I have been trying to get to work, we
> have DNSSEC on this, and its failing, but cannot for the life of me
> understand why.  I think it may have something to do with proving it
> exists as a wildcard, but any DNSSEC experts want to take a stab at it
> ?

Not an expert, but Google knows the answer (as always :-)

bjorn@miraculix:~$ dig a www.app.linktechs.net. +dnssec +multiline @8.8.8.8

; <<>> DiG 9.18.24-1-Debian <<>> a www.app.linktechs.net. +dnssec +multiline 
@8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 65184
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
; EDE: 10 (RRSIGs Missing): (For _acme-challenge.app.linktechs.net/nsec)
;; QUESTION SECTION:
;www.app.linktechs.net. IN A

;; Query time: 156 msec
;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)
;; WHEN: Fri Mar 15 18:26:16 CET 2024
;; MSG SIZE  rcvd: 98



And they're right.  Your server includes the epected NSEC record, but
leaves out the associated RRSIG.  Compare this to the
https://datatracker.ietf.org/doc/html/rfc7129#section-5.3 example:


bjorn@miraculix:~$ dig a www.app.linktechs.net. +dnssec +multiline 
@139.60.210.20 

; <<>> DiG 9.18.24-1-Debian <<>> a www.app.linktechs.net. +dnssec +multiline 
@139.60.210.20
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11828
;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1280
;; QUESTION SECTION:
;www.app.linktechs.net. IN A

;; ANSWER SECTION:
www.app.linktechs.net.  3600 IN A 139.60.210.81
www.app.linktechs.net.  3600 IN RRSIG A 8 3 3600 (
20240427232616 20240313222616 37041 
linktechs.net.
NYC/4H2VZg12vj+tiWVkEROhXwm7JkBna6RQg6LO8kXr
oosDUpGnxrgOtJYsWYbYfM58opiC1OeAbcaCB9+nctIU
grrwcpuhmvlXYLZi1n/oAmelPldnQ6Hf93HuHi4ULFsS
Qfsoo8sdfjt/YSJ4WxjmsM9LMbZ2CZPMU44a3MdftGW1
fNKmZ1fLtVreP41KmvP6b01lyUMvjrvT26Yq57DgUDTo
iqU5skT+OHzx6ERJkt3tzzwm2pBMvBWFDXC668NtouIW
s3mrhJRBuNW3xSCsroaLQ0vmdml2BqNNh7MZNc38FNMJ
eh+ts3mbMnOOkzlI1Q8gKMMCWv+VRmv2DA== )
www.app.linktechs.net.  3600 IN RRSIG A 8 3 3600 (
20240427232616 20240313222616 11340 
linktechs.net.
Th3OcZwOMNUb1zMdipnTnFdgFEaOGJ/VofQOTyxmnNCg
wl+1Q7eiQ89KHAWEDBisxd0S+EHu6/YBWY2srNx5q58P
XIZJ9oQXCqDLzSE884DTQNDEVrSMoKJ9slRU4N4Lj5tT
9LzbODmCM9ytRavOKXJHIddQa0MZT4p9cV8K2HI7XSFX
0rjieKFa7wDRJqhKyqrT3Rh/S93pavhKWUgN3GVO6hkI
H5F67UFpZK7o7nRlyqvM42ep5XaRZS/WJtLuXcTk/QM3
MBPTDWgJ0Bh8qpNuHDOb2XFH2I5dwjeKxuYCzeQzN1hL
gsmw3d1J2pNsYbC40jmi1bZr0bz2fDurIA== )

;; AUTHORITY SECTION:
_acme-challenge.app.linktechs.net. 1200 IN NSEC auto.linktechs.net. TXT RRSIG 
NSEC

;; Query time: 120 msec
;; SERVER: 139.60.210.20#53(139.60.210.20) (UDP)
;; WHEN: Fri Mar 15 18:27:13 CET 2024
;; MSG SIZE  rcvd: 724



Lots of resolvers will probably just look up that NSEC, get the RRSIG
and be happy with that.  But your problem is that there always will be a
number of resolvers not doing that.  So you get arbitrary failures.

I believe there are so many examples of really bad fallout due to
wildcards combined with DNSSEC that it's advisable to stay away. Do one
or the other.  Not both.



Bjørn

Re: DNSSEC & WIldcards

2024-03-15 Thread John Levine 
It appears that Niels Bakker  said:
>* nanog@nanog.org (Dennis Burgess via NANOG) [Fri 15 Mar 2024, 16:26 CET]:
>>So have *.app.linktechs.net that I have been trying to get to work, 
>>we have DNSSEC on this, and its failing, but cannot for the life of 
>>me understand why.  I think it may have something to do with proving 
>>it exists as a wildcard, but any DNSSEC experts want to take a stab 
>>at it ?
>
>There are better mailing lists to ask this question (like 
>dns-operations at dns-oarc.net) but have you checked 
>https://dnsviz.net/d/www.app.linktechs.net/dnssec/ ?

I agree there are better places to ask, but here's a quick
diagnosis: your nameserver is returning the wrong answer.

What kind of server is it? Any modern nameserver should automatically
return the correct DNSSEC stuff for wildcard responses.

R's,
John

Re: DNSSEC & WIldcards

2024-03-15 Thread Niels Bakker 

* nanog@nanog.org (Dennis Burgess via NANOG) [Fri 15 Mar 2024, 16:26 CET]:
So have *.app.linktechs.net that I have been trying to get to work, 
we have DNSSEC on this, and its failing, but cannot for the life of 
me understand why.  I think it may have something to do with proving 
it exists as a wildcard, but any DNSSEC experts want to take a stab 
at it ?


There are better mailing lists to ask this question (like 
dns-operations at dns-oarc.net) but have you checked 
https://dnsviz.net/d/www.app.linktechs.net/dnssec/ ?



-- Niels.

Claro Brazil contact

2024-03-15 Thread Scott Q. 
Anyone knows a direct contact for Claro Brazil ?

The phone number for their NOC on PeeringDB doesn't work or make sense
and e-mails are ignored.

Thank you

DNSSEC & WIldcards

2024-03-15 Thread Dennis Burgess via NANOG 
So have *.app.linktechs.net that I have been trying to get to work, we have 
DNSSEC on this, and its failing, but cannot for the life of me understand why.  
I think it may have something to do with proving it exists as a wildcard, but 
any DNSSEC experts want to take a stab at it ?


Dennis Burgess