Re: Mailing list SPF Failure

[Bjørn Mork]

"Scott Q."  writes:

> Anyone else getting SPF failures on all messages sent to the list
> ?
>
> I see them all originating from 50.31.151.76 but nanog.org's SPF
> record doesn't list that as allowed.

I see the same.  nanog.org mail is originated from
2001:1838:2001:8:0:0:0:20 or 50.31.151.76, and the SPF record is
currently

 "v=spf1 a include:_spf.google.com ~all"

Neither of those are Google addresses so it's a soft fail.


Bjørn

Re: Anyone got a contact at OpenAI. They have a spider problem.

[Bjørn Mork]

"John Levine"  writes:

> PS: If you were wondering what they're using to train GPT-5, well, now you 
> know.

And it's not very trainable, it seems?  I believe most amoebas respond
better to 3 million identical events...


Bjørn

Re: DNSSEC & WIldcards

[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

[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

Re: DNSSEC & WIldcards

[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

[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: puck not responding

[Bjørn Mork]

George Herbert  writes:

> If it wasn’t for how clunky they are with email sites, I’d suggest
> moving to a cloud somewhere.  But …

I believe statistics point in favour of the single puck.nether.net
host

BTW, for anyone else taking advantage of the excellent secondary service
provided by puck: You might want to update your AXFR ACLs.  It seems the
IPv6 address has changed.

I must admit that such transfer failures go unnoticed due to the large
volume of unwanted requests.  So I appreciate the extra effort sending
an email warning when a zone i disabled.

Thanks for running all these high quality services!


Bjørn

Re: ru tld down?

[Bjørn Mork]

darkde...@darkdevil.dk writes:

> With this example, you are asking why neither GTLD-SERVERS.NET nor
> NSTLD.COM has been DNSSEC signed?

That's a good point.  Yes, I guess I do.

I'm sure there is a good reason for all these examples.  I just need to
have it fed with a tiny spoon :-)



Bjørn

Re: ru tld down?

[Bjørn Mork]

Unrelated question, but this error made me notice:  Why do they put
their DNS servers in an unsigned zone?  I can't figure out a good reason
to do that when you have all the signing infrastructure in place.  But I
guess there must be a reason?


Bjørn

Re: Charter DNS servers returning invalid IP addresses

[Bjørn Mork]

"Jason J. Gullickson via NANOG"  writes:

> I've been working for a week or so to solve a problem with DNS
> resolution for Charter customers for our domain bonesinjars.com.  I've
> reached-out to Charter directly but since I'm not a customer I
> couldn't get any help from them.  I was directed by a friend to this
> list in hopes that there may be able to reach a Charter/Spectrum
> engineer who might be able to explain and/or resolve this one.
>
> A dig against Google's DNS servers correctly returns 4 A records:
>
> dig bonesinjars.com 8.8.8.8

Guess you wanted 

  dig bonesinjars.com @8.8.8.8

?

> ;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)

This is not 8.8.8.8

> dig bonesinjars.com 24.196.64.53

still missing @

> ;; SERVER: 127.0.0.53#53(127.0.0.53)

This is not 24.196.64.53


Bjørn

Re: JunOS/FRR/Nokia et al BGP critical issue

[Bjørn Mork]

Eugeniu Patrascu  writes:
> On Fri, Sep 1, 2023 at 12:56 PM Bjørn Mork  wrote:
>
>> But there's obviously not been enough thought applied to realize that
>> optional transitive attributes must be considered evil by default. They
>> can only be used after extremely careful parsing.
>>
>
> Yeah, no.
> The logic is that if you understand them, you treat them according to
> whatever routing policy you have and then pass them along.

That's where you get into problems, depending on your defintition of
"understand" and "treat".  This implies parsing unvalidated input.

Understanding RFC compliant attributes is a minor part of that task.
The real problem is dealing with absolutely anything, including values
specifically designed to attack your parser, or policy, or whatever logic
you apply to the attribute value.

> If you don't,
> you just pass them along and that's it. Nothing more, nothing less.

This is obviously not a problem.

You may be acting as a proxy for attacking your peers, but there's
nothing you can do about that without breaking the protocol.

>> This is the BGP version of
>>
>>  select * from mytable where field = $unvalidated_user_input;
>>
>
> No here as well. Because passing along a transitive attribute you don't
> understand does not affect you in any way.

I didn't say so either.

Those who _believe_ they understand it is the problem.

And I'm slowly starting to see why we still have so many implementations
where the optional transitive problem has been pretty much ignored.


Bjørn

Re: JunOS/FRR/Nokia et al BGP critical issue

[Bjørn Mork]

Nick Hilliard  writes:
> Bjørn Mork wrote on 01/09/2023 08:17:
>> Sounds familiar.
>> https://supportportal.juniper.net/s/article/BGP-Malformed-AS-4-Byte-Transitive-Attributes-Drop-BGP-Sessions?language=en_US
>> You'd think a lot of thought has gone into error handling for
>> optional
>> transitive attributes since then, but...
>
> A good deal of thought has gone into the problem, and this is where
> rfc7606 came from. Treat-as-withdraw for the NLRI in question is the
> default option with this approach, and should be deployed universally.

Yes.

But there's obviously not been enough thought applied to realize that
optional transitive attributes must be considered evil by default. They
can only be used after extremely careful parsing.

This is the BGP version of

 select * from mytable where field = $unvalidated_user_input;

I was hoping we'd moved past that point in the software development
history.


Bjørn

Re: JunOS/FRR/Nokia et al BGP critical issue

[Bjørn Mork]

Mike Lyon  writes:

> https://blog.benjojo.co.uk/post/bgp-path-attributes-grave-error-handling?fbclid=IwAR13ePY43Vf3u4X8PDyCDT39DtyXczAKkv6CGXOQbcQv90Y3aIAmTkJxn7k_aem_Ad0hzj2Mh_WlbFZug-vGdlJJdXr2Xo0RFIsPwAU2GviPz6xZDib76YHwFuzU7E0_sJk=Zxz2cZ

Sounds familiar. 

https://supportportal.juniper.net/s/article/BGP-Malformed-AS-4-Byte-Transitive-Attributes-Drop-BGP-Sessions?language=en_US

You'd think a lot of thought has gone into error handling for optional
transitive attributes since then, but...



Bjørn

Re: DNS resolution for hhs.gov

[Bjørn Mork]

Interestingly enough, the company behind this mess decided to sign it:

 bjorn@canardo:~$ dig dhhs.gov @158.74.30.99 +nsid|grep NSID
 ; NSID: 4c 65 69 64 6f 73 20 62 75 69 6c 64 20 57 2e 56 45 52 4e 41 20 32 30 
32 33 ("Leidos build W.VERNA 2023")


Guessing this was done by "security professionals" from
https://www.leidos.com/




Bjørn

Mark Andrews  writes:

> The nameservers are not answering all in scope questions being sent to the 
> servers.  Something is blocking or not generating NXDOMAIN responses.  This 
> impacts on QNAME minimisation queries that usually elicit a NXDOMAIN 
> response.  This happens irrespective of DNSSEC records being requested so I 
> doubt that it is a fragmentation issue.
>
> Both _.dhhs.gov  and foobar.dhhs.gov 
>  time out but dhhs.gov  itself 
> doesn’t.
>
> % dig _.dhhs.gov @158.74.30.103 +dnssec
> ;; communications error to 158.74.30.103#53: timed out
> ;; communications error to 158.74.30.103#53: timed out
> ;; communications error to 158.74.30.103#53: timed out
>
> ; <<>> DiG 9.19.11-dev <<>> _.dhhs.gov @158.74.30.103 +dnssec
> ;; global options: +cmd
> ;; no servers could be reached
>
> % dig dhhs.gov @158.74.30.103 +dnssec
>
> ; <<>> DiG 9.19.11-dev <<>> dhhs.gov @158.74.30.103 +dnssec
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18125
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
> ;; WARNING: recursion requested but not available
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags: do; udp: 4096
> ; COOKIE: d939ecfdb6cd2d902678cca26435eb2dd6fcebd65fe5c58f (good)
> ;; QUESTION SECTION:
> ;dhhs.gov. IN A
>
> ;; ANSWER SECTION:
> dhhs.gov. 9000 IN A 52.7.111.176
> dhhs.gov. 9000 IN RRSIG A 8 2 9000 20230416000149 20230410230149 11710 
> dhhs.gov. YCEsecATdJEHs3OtxQs/kE2A/37/mzgUpGLzQwrPP9xqaGmBq2mDteKx 
> QyUnh0JuURBq0Qy1htxsOD9kX4dxSxUNCEO7/KHw0AOoIbnh2+GL8kc3 
> jKB2jkcN+whA9+CqThto020nLSCXcgdm7qOfyNBUFICoYNtVrd7/lLCJ kho=
> dhhs.gov. 9000 IN RRSIG A 8 2 9000 20230416000149 20230410230149 21469 
> dhhs.gov. OkEdR/ofhV+JogwAkZtLmHyxn3pK2E4zaGUV786kKbtQrI6SzetCk+sC 
> Db3W0LrYRZy1BEqqxZeRnLXVEjyyyKfnYMRPtoP3sCTLPuuDeu8oDmhw 
> eniXLbJ10od6YWywgQDl2bYrTLEt6R8+TGG7up446TGgRk9wOV/uU2Jb d+U=
>
> ;; Query time: 308 msec
> ;; SERVER: 158.74.30.103#53(158.74.30.103) (UDP)
> ;; WHEN: Wed Apr 12 09:20:13 AEST 2023
> ;; MSG SIZE  rcvd: 417
>
> % dig foobar.dhhs.gov @158.74.30.103 +dnssec
> ;; communications error to 158.74.30.103#53: timed out
> ;; communications error to 158.74.30.103#53: timed out
> ;; communications error to 158.74.30.103#53: timed out
>
> ; <<>> DiG 9.19.11-dev <<>> foobar.dhhs.gov @158.74.30.103 +dnssec
> ;; global options: +cmd
> ;; no servers could be reached
>
> % dig foobar.dhhs.gov @158.74.30.103 
> ;; communications error to 158.74.30.103#53: timed out
> ;; communications error to 158.74.30.103#53: timed out
> ;; communications error to 158.74.30.103#53: timed out
>
> ; <<>> DiG 9.19.11-dev <<>> foobar.dhhs.gov @158.74.30.103
> ;; global options: +cmd
> ;; no servers could be reached
>
> % 
>
>> On 12 Apr 2023, at 01:12, Samuel Jackson  wrote:
>> 
>> I wanted to run this by everyone to make sure I am not the one losing my 
>> mind over this.
>> 
>> A dig +trace cob.cms.hhs.gov fails for me as it looks like the NS for 
>> hhs.gov does not seem to resolve the hostname.
>> 
>> However dig +trace cms.hhs.gov resolves and so does dig +trace 
>> eclkc.ohs.acf.hhs.gov
>> 
>> However if I simply ask my local resolver to resolve cob.cms.hhs.gov, it 
>> works. Any thoughts on why this is the case?
>> 
>> Thanks,
>> 

Re: Spamhaus flags any IP announced by our ASN as a criminal network

[Bjørn Mork]

Brandon Zhi  writes:

> Well, those prefixes are not for their VPS hosting service (which cause a
> lot of complaint). Just like there are many IP addresses under the
> telecommunication company, the entire ASN cannot be "blocked" just because
> there is a complaint on one IP address

April came early this year.


Bjørn

Re: Random shower thought: GBIC with LC connector...

[Bjørn Mork]

Maybe you're thinking of X2, looking similar to GBIC but even bigger?
There were converters taking 2 gig SFPs in one X2 slot.

Don't think either GBIC to SFP or GBIC with LC makes much sense.  The
alternatives were dirt cheap and easily available by the time these
could have been products.


Bjørn

Matt Erculiani  writes:

> I feel like I've seen GBIC sleeves that accept SFP modules very similar to
> QSFP+ CVRs, but I can't seem to find any evidence of these ever existing,
> so perhaps I'm misremembering.
>
> -Matt
>
> On Tue, Nov 15, 2022 at 9:23 AM Mel Beckman  wrote:
>
>> Oh. And it’s not “OCD”. It’s “CDO”, with letters in ascending sequence. :)
>>
>> -mel via cell
>>
>> > On Nov 15, 2022, at 8:18 AM, Mel Beckman  wrote:
>> >
>> > No. GBIC stands for Great Big Inserted Cartridge. LC stands for Little
>> Connector. Thus they are not compatible.
>> >
>> > -mel via cell
>> >
>> >> On Nov 15, 2022, at 7:59 AM, Warren Kumari  wrote:
>> >>
>> >> 
>> >> Hi there all,
>> >>
>> >> While looking through my big box of random optics I suddenly realized
>> that I'd never seen a GBIC with an LC connector, and I started wondering if
>> anyone else had / if such a thing actually exists.
>> >>
>> >> Yes, I realize that this would be a fairly niche device - if you
>> arrived somewhere with a device that took GBICs and there was existing
>> fiber with LC connectors you could just replace the patch cable or use an
>> LC-SC convertor, but that doesn't really satisfy my curiosity.
>> >>
>> >> A quick look through the GBIC MSA / SFF documentation implies that such
>> a thing *could* probably exist (there is a defined value for the 'LC'
>> connector), but I wasn't able to actually find any. It might not actually
>> be compliant with the specs (the document I found only lists SC fiber or
>> copper (coax with BNC, TNC or DB-9?!)), but that doesn't mean that no-one
>> made them.
>> >>
>> >> So, has anyone seen a regular (30mm/1.2") GBIC with LC connectors? And,
>> if so, "pics or it didn't happen"... :-)
>> >>
>> >> Obviously I don't have an actual use for this, it's just to satisfy my
>> (OCD) curiosity...
>> >> W
>> >>
>> >>
>>

Re: Router ID on IPv6-Only

[Bjørn Mork]

Jeff Tantsura  writes:

> Looking at the fix, Donald has only removed IPV4_CLASS_DE(a) 
> uint32_t)(a)) & 0xe000) == 0xe000)
> validation but kept INADDR_ANY. 
> I’ll bring up RFC6286 to him

I believe it is implementing the RFC6286 requirements. INADDR_ANY is
((in_addr_t) 0x), which is the only illegal value.


Bjørn

Re: Router ID on IPv6-Only

[Bjørn Mork]

Jeff Tantsura  writes:

> Indeed, someone was recently complaining that FRR is unhappy with a
> peer with router-id from class E range…

This made me curious enough to dig up the fix.  If anyone else is interested:
https://github.com/FRRouting/frr/commit/b5c2113e47f846d0c48fb4ef63e29bf96bd2fbe2


Bjørn

Re: Router ID on IPv6-Only

[Bjørn Mork]

Saku Ytti  writes:

> On Thu, 8 Sept 2022 at 10:01, Bjørn Mork  wrote:
>
>> Why would you do it differently than for dual-stack routers, except that
>> you skip the step where you configure the ID as a loopback address?
>
> Because you may not have an option, if you're IPv6 only, vendors (e.g.
> junos) may expect you to punch it manually. Of course most of us punch
> it manually as loopback0 IPv4 to have more control over outcome.
> Question is legitimate and represents change where previously used
> mechanisms do not apply, therefore OP is right to ask 'well what
> should I do now'.

I'm not used to punching anything, so I probably have too simple a view
of the world.

But I still don't understand how this changes the ID allocation scheme,
which is how I understood the question.  I assume the punched value was
based on input from somewhere?


Bjørn

Re: Router ID on IPv6-Only

[Bjørn Mork]

Crist Clark  writes:

> During some IPv6 numbering discussions at work today, someone had a
> question that I hadn't really considered before. How to choose 32-bit
> router IDs for IPv6-only routers.

Why would you do it differently than for dual-stack routers, except that
you skip the step where you configure the ID as a loopback address?

Of course you don't have care about routing the 32bit IDs anymore
either.  But that doesn't really change anything either.  Except that
can skip even more configuration.

It's obviously possible to connect the ID to some IPv6 address on the
router, as long as you understand the structure of that allocation and
can select the right bits or hash to make it unique.  But if you don't
do that for dual-stack today, then why care?  Or if you do it for
dual-stack, then what changed?


Bjørn

Re: FCC proposes higher speed goals (100/20 Mbps) for USF providers

[Bjørn Mork]

Michael Thomas  writes:
> On 5/23/22 11:49 AM, Aaron Wendel wrote:
>> The Fiber Broadband Association estimates that the average US
>> household will need more than a gig within 5 years.  Why not just
>> jump it to a gig or more?
>
> Really? What is the average household doing to use up a gig worth of
> bandwidth?

I don't think this "need" is based on using up all the available
bandwitdh, but about speed expectations.  Customers want to download the
same amount of data as before, only faster.  Increasing the subscriber
port bandwidth allows the ISP to oversubscribe their access network even
more, so the cost doesn't necessarily increase much.  You get faster
downloads for "free".  Customers will want that.

Don't know how many of you on the wrong side of the pond followed
RIPE84? There was an interesting talk there from Init7 in Switzerland on
their experiences delivering 25 gig FTTH:
https://ripe84.ripe.net/archives/video/797/

I noticed in particular the "Monthly volume won't change" on one of the
slides..

Dealing with extreme syncronized peaks, like a popular game launch for
example, will be harder with higher bandwidths.  But we do have CDNs for
efficient distribution of the same content to many ports. You'll just
have to move those further out in the access network.


Bjørn

Re: opendkim

[Bjørn Mork]

Bjørn Mork  writes:

> Any hints on how to configure sendmail to avoid this are appreciated.

This turned out to be simple.  Should have looked first, as usual.

The sendmail config problem was Debian specific, caused by

dnl # add .' to mustquote chars (and match the binary default)
changequote([, ])dnl
define([confMUST_QUOTE_CHARS], [.'])dnl
changequote(`, ')dnl

in /usr/share/sendmail/cf/ostype/debian.m4



Bjørn

opendkim (was: Re: Gmail (thus Nanog) rejecting ipv6 email)

[Bjørn Mork]

"John Levine"  writes:
> It appears that Michael Thomas  said:
>>
>>On 4/3/22 12:12 PM, Bjørn Mork wrote:
>>> On a slightly related subject... This DKIM failure surprised me, but at
>>> least I verified that many NANOG subscribers have mailservers returning
>>> DMARC failure reports ;-)
>>
>>Oh wow, you should report that to Murray.
>
> It's on Github, so you can open an issue and if you're
> feeling inspired a fork and a patch.  There's currently
> 67 open issues and 15 pull requests so don't hold your breath.
>
> https://github.com/trusteddomainproject/OpenDKIM

There is absolutely nothing wrong with opendkim.

Sorry for this off-topic noise.  opendkim is an excellent tool, which
helped me find the real problem with a simple "Diagnostics yes" in the
config file.

My problem was caused by bad interaction between nullmailer and
sendmail. Turns that out nullmailer removes quotes around the
display-name unless required, while sendmail adds quotes it consider
necessary.  The end-result is a Cc header looking exacly like the one I
sent.  Only problem is that it wasn't that header opendkim got.

1) I submitted this to nullmailer:

  Cc: John Levine ,
  "North American Network Operators' Group" 

2) nullmailer forwarded this to sendmail:

  Cc: John Levine ,
  North American Network Operators' Group 

3) opendkim signed the mail using the unquoted Cc header

4) sendmail added quotes and forwarded this:

  Cc: John Levine ,
  "North American Network Operators' Group" 

5) validation failed since the header signature was based on the
  unquoted version.


The header modifications in transit is the real bug.  IMHO neither
nullmailer nor sendmail should change the Cc header here. They should
rather reject the mail if they don't like the headers.  But I can't see
any reasons for that.  Both the quoted and the unquoted versions are
fine according to my understanding of RFC5322.

Any hints on how to configure sendmail to avoid this are appreciated.

I can always patch nullmailer. But the same problem can be triggerd by
any client submitting an unquoted display-name with an apostrophe to
sendmail. Possibly also other characters which are allowed in an atom.

I do understand why most people just go with gmail...




Bjørn

Re: Gmail (thus Nanog) rejecting ipv6 email

[Bjørn Mork]

On a slightly related subject... This DKIM failure surprised me, but at
least I verified that many NANOG subscribers have mailservers returning
DMARC failure reports ;-)

Bjørn Mork  writes:

> Authentication-Results: mx.google.com;
>  dkim=fail header.i=@mork.no header.s=b header.b=NB0BT8Ez;
>  spf=pass (google.com: best guess record for domain of bj...@miraculix.mork.no
>  designates 2001:41c8:51:8a:feff:ff:fe00:e5 as permitted sender)
>  smtp.mailfrom=bj...@miraculix.mork.no; 
>  dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mork.no
> Received: from canardo.dyn.mork.no ([IPv6:2a01:799:c9f:8600:0:0:0:1])
>  (authenticated bits=0)
>  by louie.mork.no (8.15.2/8.15.2) with ESMTPSA id 233IGnGC342047
>  (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=OK);
>  Sun, 3 Apr 2022 19:16:50 +0100
> Received: from miraculix.mork.no ([IPv6:2a01:799:c9f:8602:8cd5:a7b0:d07:d516])
>  (authenticated bits=0)
>  by canardo.dyn.mork.no (8.15.2/8.15.2) with ESMTPSA id 233IGnKb1147676
>  (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=OK);
>  Sun, 3 Apr 2022 20:16:49 +0200
> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mork.no; s=b;
>  t=1649009809; bh=ZByFGHIiZPQYmJjQnCv16CXFZhKG8U3fTayR+Mx3piY=;
>  h=From:To:Cc:Subject:References:Date:Message-ID:From;
>  b=NB0BT8EzJBl2E3jzDaz7QY4C/utMGKFF+HCs8qjQFoHA4JHTD21ZkTk34jp2VOiJ0
>  pYWHUNXCNaEBK44Hr4U96h5pfXor+dqo0cSuRPTLNnRsoLAQg2kqmQkvylagdeezZc
>  4p+jQEQv5La2KbjzEIvW6iSGwwe4ltT9hu7h0H8U=
> Received: (nullmailer pid 389787 invoked by uid 1000);
>  Sun, 03 Apr 2022 18:16:48 -
> From: =?utf-8?Q?Bj=C3=B8rn_Mork?= 
> To: Randy Bush 
> Cc: John Levine ,
> "North American Network Operators' Group" 
> Subject: Re: Gmail (thus Nanog) rejecting ipv6 email
> Organization: m
> References: <875ynqcvsl@miraculix.mork.no>
>  <20220403164123.4ce413a4b...@ary.qy> 
> Date: Sun, 03 Apr 2022 20:16:48 +0200
> In-Reply-To:  (Randy Bush's message of "Sun, 03
>  Apr 2022 10:50:06 -0700")
> Message-ID: <87v8vqav73@miraculix.mork.no>


Did a little testing, and it looks like opendkim create a bogus
signature if a quoted-string diplay name in a To or Cc headers contains
an apostrophe. Not good at all.


Bjørn

Re: Gmail (thus Nanog) rejecting ipv6 email

[Bjørn Mork]

Randy Bush  writes:

> i try to keep a list of goog's ipv6 email space and don't deliver to it;
> rather using ipv4 instead.  unfortunately, goog does not cooperate with
> dnswl.org, so this can not be automated.

How about using their SPF records as automation input?  Their MXes are
inside those blocks right now at least.


Bjørn

Re: Gmail (thus Nanog) rejecting ipv6 email

[Bjørn Mork]

I didn't know anyone still cared?

Google has been trying to move away from Internet email for many years
now.  Just let them.  There is no way you can "fix" that problem on your
side.

If you care about specific recipients, then inform them that Google
randomly throws away some of their legitimate email. Send a paper mail
or phone them if necessary.  That's pretty much all you can do.  If
those recipients continue to use gmail, then that's their decision and
problem.

I assume NANOG is informed about this now.


Bjørn

Re: MAP-T

[Bjørn Mork]

JORDI PALET MARTINEZ via NANOG  writes:

> It comes from actual measurements in residential networks that already
> offer IPv6.
>
> In typical residential networks, a very high % of the traffic is
> Google/Youtube, Netflix, Facebook, CDNs, etc., which all are IPv6
> enabled.

I wonder about that...

In our small corner of the world, Tore has these useful measurements
from a dual stack "high volume" web site (a local newspaper).  This is a
mix of enterprise and residential users on all types of access
(ethernet, HFC, GPON, DSL, pigeon):
https://munin.fud.no/vg.no/www.vg.no/vg_ds_telenor.html

These users have had native dual stack (DHCPv6-PD + DHCP) for 5+ years.
And most of them use their operator provided CPEs where dual-stack is
enabled by default. Still, as you can see, only 50% of the clients end
up using IPv6.  I don't know why, but assume this is caused by the
client systems behind the CPE.  Either they don't support IPv6 or the
users have disabled it.

> Typically, is also similar in mobile networks, and this has been
> confirmed also by measurements in v6ops mailing list, for example from
> T-Mobile. If I recall correctly that was 3-4 years ago and was already
> 75% IPv6 traffic.

Yes, for traditional mobile (i.e handsets) the picture is completely
different.  Same view shows an average of 85% IPv6 on mobile access:
https://munin.fud.no/vg.no/www.vg.no/vg_ds_telenor_mobil.html

Note that the last 3G cell was switched off in January 2021 in this
network, eliminating any client older than 10 years in practice (2G is
still supported, but... well, it's not going to show up on traffic
volume measurments).

> Enterprises usually have a lower IPv6 %, so actual numbers in a given
> ISP my depend on the ratio of enterprise/residential customers. It may
> also depend on the case of residentials, on the age of SmartTVs, which
> may not be IPv6 enabled.

Yes, this will also affect the first measurement since it is a mix of
enterprise/residential.  But the majority is residential, as this
relative volume by time of day clearly shows: 
https://munin.fud.no/vg.no/www.vg.no/vg_ipv6_telenor.html

In any case, I'll claim it's hard for a fixed access provider to achive
much more than 50% IPv6 volume today.  We'll have to start disabling
IPv4 to get better results than that.

Mobile is a different animal, with client systems being replaced
constantly.



Bjørn

Re: DMARC ViolationAS21299 - 46.42.196.0/24 ASN prepending 255 times

[Bjørn Mork]

Paschal Masha  writes:

> :) probably the longest prepend in the world.
>
> A thought though, is it breaking any standard or best practice procedures?

Don't think so.  But there is this draft suggesting max 5:
https://datatracker.ietf.org/doc/draft-ietf-grow-as-path-prepending/


Bjørn

Re: V6 still not supported

[Bjørn Mork]

Owen DeLong via NANOG  writes:

> Virtually every useful flow of packets in one direction requires a
> relatively symmetrical flow of packets in the other direction.

Packet captures are useful without anything being returned. It's not
uncommon to use some sort of unidirectional tunnel to transport captures
over an IP-network.

Same goes for logging. Traditional udp syslog is a one-way street.

And I'm sure there are more examples.

Not that I think it matters in this discussion, which appears more
circular than bidirectional.


Bjørn

Re: Russia to disconnect from global Internet

[Bjørn Mork]

Stephane Bortzmeyer  writes:

> And yet noone says that the USA are disconnecting from the Internet.

Exactly.  They've never connected to it.


Bjørn

Re: Certificates for DoT and DoH?

[Bjørn Mork]

John Todd  writes:

> To validate that the addresses were “ours” or at least under our
> control, there were still some hoops to jump through other than the
> standard validation of registry data. For example, we had to activate
> web servers and objects on our anycast network to answer specific
> queries during some of the check processes.
>
> TL;DR: Digicert is still the only player for v6 signing, and it will
> not be entirely hands-free to manage but also not overly difficult.

Thanks a lot!  This is incredibly useful.

Yes, we are sort of prepared for the web server hoops. Not trivial since
our addresses aren't normally reachable from the Internet, even if they
are public and advertised.  We are only providing AS internal DNS
resolver service. Dropping outside traffic is an easy way to add some
protection.  But that's just one more hoop.

The technical challenges are nothing anyway. Getting permission from
sourcing to buy something from a new partner will be far worse... So I
will go another round with our existing partners first.

Thanks again.



Bjørn

Re: Certificates for DoT and DoH?

[Bjørn Mork]

Bill Woodcock  writes:

>> Does this mean that DigiCert is the only alternative?
>
> I assume not, but we’d already used them for other things, and they
> didn’t have a problem doing it, so we didn’t shop any further.

Makes sense.  That's how I started as well.  But we are using Buypass,
and for some unknown reason they did have a problem doing it.


>> And do they really have this offer for ordinary users, or is this also some 
>> special
>> arrangement for big players only?
>
> No, we didn’t have to do anything special, to the best of my knowledge.

Good to know.  Thanks

>> That does make me wonder how they verify that I'm the rightful owner of
>> "sites, IP addresses, common names, etc.".  In particular, "etc" :-)
>> Or you could ask yourself if you trust a CA with such an offer...
>
> Yep.  DANE is the correct answer.  CAs are not.  But that’s been true
> for a very long time, and people are still trying to pretend that CAs
> know what’s what.


Agree 100%.

Now I'm going to ask another stupid question:  How would DANE work for
DoT/DoH?  Having TLSA records in in-addr.arpa and ip6.arpa?


Bjørn

Re: Certificates for DoT and DoH?

[Bjørn Mork]

David Guo  writes:

> You don't need a certificate for your IP address if your DoT and DoH
> use domains.

Sorry if I'm slow, but isn't that a chicken-and-egg problem?

We're going to provide this as an add-on to our standard ISP resolver
service.  Most clients will pick up the addresses from DHCP/DHCPv6.
Very few are configuring DNS resolvers manually, and those who do are
using other providers.  Like you :-)

> For certificates with IPv4 address, we use ZeroSSL / GoGetSSL, both
> are SubCA with Sectigo, which works fine.

Thanks.  That's interesting. I didn't know ZeroSSL offered this.  And
GoGetSSL has better docs than most.  

But we can't run a resolver service without IPv6 in 2022.  Did you ever
get any explanation of this restriction?  Shouldn't be much
harder/different to validate an IPv6 address if you can validate an IPv4
address.

> For IPv6 address, we used Digicert but it's too expensive, so we give up ☹

Hard to claim it's too expensive if no one else thinks it's worth
offering a similar service...

> Our DoT/DoH service is https://dns.sb/

Nice.  Good to have more examples to look at.  


Bjørn

Certificates for DoT and DoH?

[Bjørn Mork]

Any recommendations for a CA with a published policy allowing an IP
address SAN (Subject Alternative Name)?

Preferably someone using ACME with a simple RFC 8738 reference. Let's
Encrypt had this in their TODO list for a while, but it was removed and
the project was put on hold:
https://github.com/letsencrypt/boulder/pull/4920#issuecomment-832104881
https://community.letsencrypt.org/t/planned-rfc-8738-support-pulled/152057

And I've been unable to find any other CAs with RFC 8738 support either.
Most of them don't even bother documenting it as unsupported. All I've
found is this answer from Buypass:
https://community.buypass.com/t/h7hm76w/buypass-support-for-rfc-8738

So what do people use for DoT and DoH?

I see that Google got a certificate from their own CA.  No surprise...

Version: 3 (0x2)
Serial Number:
9c:d9:a2:0f:fe:dd:2b:0a:12:00:00:00:00:03:6f:0b
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = US, O = Google Trust Services LLC, CN = GTS CA 1C3
Validity
Not Before: Feb 17 11:34:59 2022 GMT
Not After : May 12 11:34:58 2022 GMT
Subject: CN = dns.google
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (2048 bit)
Modulus:
00:ec:43:69:7c:2b:7d:99:d5:f3:79:d7:b8:54:bd:
6e:61:7b:8d:50:c5:bb:86:6c:a3:60:27:3e:22:c6:
45:00:68:a2:d2:2e:c9:c2:8f:8e:58:0e:93:0a:a4:
ff:2d:5c:71:d9:0a:5b:f3:1c:ce:79:d2:71:5c:20:
4a:34:21:c1:fa:c3:92:bd:e8:7e:bd:93:79:ef:ad:
0b:74:e0:21:f6:22:4e:9c:39:01:48:49:bc:a0:db:
98:0b:ab:4c:df:99:b1:30:92:09:0d:f8:ea:0f:7f:
85:65:55:e7:9f:ba:88:4a:ca:93:04:71:8d:13:f7:
3b:e3:36:ee:fc:b7:b9:fc:e5:5a:a8:7b:22:ce:0a:
dd:4b:36:ee:d9:8f:09:d4:2e:3f:48:5e:f8:7c:71:
2d:65:26:29:67:b9:c7:b2:77:8a:60:20:4f:dd:74:
00:49:c5:6f:3b:19:d0:ea:f8:78:ef:86:02:37:be:
3d:2e:d1:14:18:22:22:e6:94:65:bb:9d:37:b8:61:
8b:2c:fc:85:bc:04:01:56:74:04:b9:86:dc:59:9a:
75:9d:de:d9:65:67:5d:9f:75:f3:6d:8a:4f:61:d2:
c5:b5:e1:dd:2e:54:78:8a:a8:39:ab:d1:0c:97:4d:
bc:7d:f2:64:cb:d3:21:5a:f0:70:03:08:a6:f4:21:
4c:63
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage: 
TLS Web Server Authentication
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Subject Key Identifier: 
A6:21:3C:08:17:99:1E:DE:2D:F5:EB:C8:90:C9:71:D2:E9:53:1D:EE
X509v3 Authority Key Identifier: 

keyid:8A:74:7F:AF:85:CD:EE:95:CD:3D:9C:D0:E2:46:14:F3:71:35:1D:27

Authority Information Access: 
OCSP - URI:http://ocsp.pki.goog/gts1c3
CA Issuers - URI:http://pki.goog/repo/certs/gts1c3.der

X509v3 Subject Alternative Name: 
DNS:dns.google, DNS:dns.google.com, DNS:*.dns.google.com, 
DNS:.google, DNS:dns64.dns.google, IP Address:8.8.8.8, IP Address:8.8.4.4, 
IP Address:2001:4860:4860:0:0:0:0:, IP Address:2001:4860:4860:0:0:0:0:8844, 
IP Address:2001:4860:4860:0:0:0:0:6464, IP Address:2001:4860:4860:0:0:0:0:64
X509v3 Certificate Policies: 
Policy: 2.23.140.1.2.1
Policy: 1.3.6.1.4.1.11129.2.5.3

X509v3 CRL Distribution Points: 

Full Name:
  URI:http://crls.pki.goog/gts1c3/zdATt0Ex_Fk.crl

[cut]


But this is not an option for anyone else according to
https://pki.goog/faq/#faq-29 :

   How can I get a certificate from Google Trust Services? 

   At this time, the only way to get a certificate from Google Trust
   Services is via an Alphabet or Google product.


I guess it's easy to push for DoT and DoH when you can create rules like
that.


Both Quad9 and Cloudflare got their certificates from DigiCert:

Version: 3 (0x2)
Serial Number:
05:45:06:fe:17:98:52:bb:fa:c1:a7:3d:cd:80:39:7b
Signature Algorithm: ecdsa-with-SHA384
Issuer: C = US, O = DigiCert Inc, CN = DigiCert TLS Hybrid ECC SHA384 
2020 CA1
Validity
Not Before: Jul 27 00:00:00 2021 GMT
Not After : Aug  4 23:59:59 2022 GMT
Subject: C = US, ST = California, L = Berkeley, O = Quad9, CN = 
*.quad9.net
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:7d:8b:d7:1d:03:85:0d:18:25:b3:34:1c:29:a1:
27:d4:ac:01:25:48:8a:a0:f1:ea:02:b9:d8:51:2c:

Re: VPN recommendations?

[Bjørn Mork]

Sabri Berisha  writes:

> I read on some mailing list that Meraki likes to ping 8.8.8.8 every
> second... :)

That's probably to be fair with the quad-x dns providers since they
alrady were abusing 1.1.1.1.

Makes me wonder what Meraki uses 9.9.9.9 for :-)


Bjørn

Re: Slack.com DNSSEC on Feb 12th 15:00 UTC

[Bjørn Mork]

RFC1912 says

   Wildcard As and CNAMEs are possible too, and are really confusing to
   users, and a potential nightmare if used without thinking first.

You know the nightmare is real.  You've been there.

So why the heck do you insist on keeping that wildcard?  Nobody else use
wildcard A records.  There is no reason.  It's a loaded footgun.

I assume you know which names you are going to serve?


Bjørn

Re: What do you think about the "cloudification" of mobile?

[Bjørn Mork]

I don't know what that article says, but cloudification of the mobile
core has been a thing for a while.  We have this: https://wgtwo.com/

Disclaimer:  I'm working for Telenor and spouse is working for Cisco.
WG2 is a joint venture between Cisco, Telenor and Digital Alpha.


Bjørn

Re: SOHO IPv6 switches

[Bjørn Mork]

Brandon Martin  writes:

> The Netgear GS108T is my typical go-to "not a dumb switch".  8 ports
> for about $80.
>
> Make sure you get the v3 if you want most of the modern IPv6 L2
> features (you also get some very limited L3 capabilities). 

Extra bonus with the GS108Tv3, and anything else based on the RTL8380,
is that you can run OpenWrt on it.


Bjørn

Re: Anyone seeing ping corruption?

[Bjørn Mork]

Masataka Ohta  writes:

> No, an ICMP echo reply does not include the entire request packets

RFC792:
  The data received in the echo message must be returned in the echo
  reply message.

Re: .bv ccTLD

[Bjørn Mork]

Jaap Akkerhuis  writes:

> SIDN and NORID once considered to market .BV together:
> 

The rest of the story is here:
https://www.norid.no/en/aktuelt/plans-to-utilize-bv-shelved-en/


Bjørn

Re: multihoming

[Bjørn Mork]

Christopher Morrow  writes:

> Also, for completeness, MP-TCP clearly does not help UDP or ICMP flows...
> nor IPSEC nor GRE nor...
> unless you HTTP over MP-TCP and encap UDP/ICMP/GRE/IPSEC over that!

IP over DNS has been a thing forever.  IP over DoH should work just
fine.

> Talk about layer violations! talk about fun!

Yes, fun...


Bjørn

Re: DNS pulling BGP routes?

[Bjørn Mork]

Masataka Ohta  writes:
> William Herrin wrote:
>
 This is quite common to tie an underlying service announcement to BGP
 announcements in an Anycast or similar environment.
>>>
>>> Yes, that is a commonly seen mistake with anycast.
>> You don't know what you're talking about.
>
> I do but you don't.

https://datatracker.ietf.org/doc/html/rfc4786#section-4.4.1

Not a mistake. BCP.



Bjørn

Re: Better description of what happened

[Bjørn Mork]

Tom Beecher  writes:

>  Even if the external
> announcements were not withdrawn, and the edge DNS servers could provide
> stale answers, the IPs those answers provided wouldn't have actually been
> reachable

Do we actually know this wrt the tools referred to in "the total loss of
DNS broke many of the tools we’d normally use to investigate and resolve
outages like this."?  Those tools aren't necessarily located in any of
the remote data centers, and some of them might even refer to resources
outside the facebook network.

Not to mention that keeping the DNS service up would have prevented
resolver overload in the rest of the world.

Besides, the disconnected frontend servers are probably configured to
display a "we have a slight technical issue. will be right back" notice
in such situations.  This is a much better user experience that the
"facebook?  never heard of it" message we got on monday.

yes, it makes sense to keep your domains alive even if your network
isn't.  That's why the best practice is name servers in more than one
AS.




Bjørn

Re: Facebook post-mortems...

[Bjørn Mork]

Masataka Ohta  writes:
> Bjørn Mork wrote:
>
>> Removing all DNS servers at the same time is never a good idea, even in
>> the situation where you believe they are all failing.
>
> As I wrote:
>
> : That facebook use very short expiration period for zone
> : data is a separate issue.
>
> that is a separate issue.

Sorry, I don't understand what you're getting at.  The TTL is not an
issue. An infinite TTL won't save you if all authoritative servers are
unreachable.  It will just make things worse in almost every other error
scenario.

The only solution to the problem of unreachable authoritative DNS
servers is:  Don't do that.

>> This is a very hard problem to solve.
>
> If that is their policy, it is just a policy to enforce and not
> a problem to solve.

The policy is there to solve a real problem.

Serving stale data from a single disconnected anycast site is a problem.
A disconnected site is unmanaged and must make autonomous decisions.
That pre-programmed decision is "just policy".  Should you withdraw the
DNS routes or not?  Serve stale or risk meltdown?

I still don't think there is an easy and obviously correct answer.  But
they do of course need to add a safety net or two if they continue with
the "meltdown" policy.


Bjørn

Re: Facebook post-mortems...

[Bjørn Mork]

Masataka Ohta  writes:

> As long as name servers with expired zone data won't serve
> request from outside of facebook, whether BGP routes to the
> name servers are announced or not is unimportant.

I am not convinced this is true.  You'd normally serve some semi-static
content, especially wrt stuff you need yourself to manage your network.
Removing all DNS servers at the same time is never a good idea, even in
the situation where you believe they are all failing.

The problem is of course that you can't let the servers take the
decision to withdraw from anycast if you want to prevent this
catastrophe.  The servers have no knowledge of the rest of the network.
They only know that they've lost contact with it.  So they all make the
same stupid decision.

But if the servers can't withdraw, then they will serve stale content if
the data center loses backbone access. And with a large enough network
then that is probably something which happens on a regular basis.

This is a very hard problem to solve.

Thanks a lot to facebook for making the detailed explanation available
to the public.  I'm crossing my fingers hoping they follow up with
details about the solutions they come up with.  The problem affects any
critical anycast DNS service. And it doesn't have to be as big as
facebook to be locally critical to an enterprise, ISP or whatever.



Bjørn

Re: Facebook post-mortems...

[Bjørn Mork]

Jean St-Laurent via NANOG  writes:

> Let's check how these big companies are spreading their NS's.
>
> $ dig +short facebook.com NS
> d.ns.facebook.com.
> b.ns.facebook.com.
> c.ns.facebook.com.
> a.ns.facebook.com.
>
> $ dig +short google.com NS
> ns1.google.com.
> ns4.google.com.
> ns2.google.com.
> ns3.google.com.
>
> $ dig +short apple.com NS
> a.ns.apple.com.
> b.ns.apple.com.
> c.ns.apple.com.
> d.ns.apple.com.
>
> $ dig +short amazon.com NS
> ns4.p31.dynect.net.
> ns3.p31.dynect.net.
> ns1.p31.dynect.net.
> ns2.p31.dynect.net.
> pdns6.ultradns.co.uk.
> pdns1.ultradns.net.
>
> $ dig +short netflix.com NS
> ns-1372.awsdns-43.org.
> ns-1984.awsdns-56.co.uk.
> ns-659.awsdns-18.net.
> ns-81.awsdns-10.com.

Just to state the obvious: Names are irrelevant. Addresses are not.

These names are just place holders for the glue in the parent zone
anyway.  If you look behind the names you'll find that Apple spread
their servers between two ASes. So they are not as vulnerable as Google
and Facebook.


Bjørn

Re: IPv6 woes - RFC

[Bjørn Mork]

Masataka Ohta  writes:

> That IPv6 will be disaggregated into /40 or even /32 is disastrous.

It won't.

No ISPs will deaggregate anything.

Some multi-site enterprises might assign a /48 per remote site from
their single prefix, and want those /48s routed via some transit peers.
But this does not imply that their prefix is split into the maximum
number of /48s. The number of routes is limited to the number of
separate network sites.  There is no need to worry about this number
ever exceeding the number of IPv4 prefixes.

And those /48s will most likely be filtered out of the global table
forever.  Enterprises wanting such a configuration will depend on
special transit agreements to carry and aggregate them for the rest of
the world.  This is not a problem.

There are real issues with dual-stack, as this thread started out with.
I don't think there is a need neither to invent IPv6 problems, nor to
promote IPv6 advantages.  What we need is a way out of dual-stack-hell.





Bjørn

Re: IPv6 woes - RFC

[Bjørn Mork]

Owen DeLong via NANOG  writes:

> The addresses aren’t the major cost of providing IPv4 services.
>
> CGN boxes, support calls, increasing size of routing table = buying new 
> routers, etc.

You're counting dual-stack costs as if IPv4 was the optional protocol.
That's a fantasy world.  Time to get out of la-la land now.

Your edge routers can do CGN for all connected users just fine. Yes,
there is still a cost both in resources and management, but you'll have
to weigh that against the cost of doing dual-stack on the same box.  I'm
not convinced dual-stack wins.

Don't know what you're thinking of wrt support calls, but dual-stack has
some failure modes which are difficult to understand for both end users
and support.  NAT is pretty well understood in comparison.

Your routing tables won't grow with IPv4 or CGN.  They grow when you add
IPv6.

> Increased cost of developers having to work around NAT and NAT
> becoming ever more complex with multiple layers, etc.

And this can be avoided by reconfiguring the local network somehow?  Or
are we talking about an Internet without IPv4?  This is even more
fantastic than the idea that IPv4 is optional in the local network.

> All of these are the things driving the ever increasing cost of IPv4
> services, not just the cost of the addresses.

Yes, the cost of addresses is not prohibitive, and there is no
indication it will be.

The consolidation of hosting services have reduced the need for globally
routable addresses.  You don't host your own mail server and web server
anymore, even if you're a large organisation.  Most ISPs haven't yet
taken advantage of this.  They are still giving globally routable IPv4
addresses to customers which have no need for that.  These addresses can
be re-allocated for CGN if there is a need. This is obviously still not
free, but it does limit the price of fresh IPv4 addresses.

The other costs you list will not affect an IPv4 only shop at all.


Bjørn

Re: IPv6 woes - RFC

[Bjørn Mork]

Owen DeLong via NANOG  writes:

> This is my point… That is why I think an announcement of “On X date,
> we will begin charging extra for IPv4 services and define Internet Access
> to be IPv6” by a couple of the larger eyeball ISPs would light a pretty
> big fire under those laggards.
>
> Think about it… Amazon doesn’t want to lose access to Comcast, T-Mobile,
> Verizon Wireless, and/or AT eyeballs any more than those ISPs want
> to deal with the call center consequences if they turn off IPv4 before those
> content providers are ready.

By all means, let's just escalate the peering wars between eyeball
networks and content providers.  That will solve all our problems.



Bjørn

Re: IPv6 woes - RFC

[Bjørn Mork]

Saku Ytti  writes:

> On Tue, 7 Sept 2021 at 19:51, Owen DeLong  wrote:
>
>> Hopefully this idea that “you need to do IPv4 anyhow” will die some day soon.
>
> Fully agreed, I just don't see the driver. But I can imagine a
> different timeline where in 2000 several tier1 signed mutual binding
> contracts to drop IPv4 at the edge in 2020. And no one opposed,
> because 20 years before was 1980, and 20 years in the future IPv4
> wont' anymore be a thing, it's clear due to exponential growth.
>
> And we'd all be enjoying a much simplified stack and lower costs all
> around (vendor, us, customers).

I started wondering if there are areas where we can disable IPv4 today.

Ideas like Tore documented in RFC 7755 are certainly possible without
any negative effects, and hopefully with reduced costs compared to a
full dual-stack environment. But it is still based on the assumption
that any interface facing the Internet must be dual-stack.

The next thought was SMTP and authoritative DNS servers.  Running IPv6
only in a real production environment should be possible as long as you
keep IPv4 on at least one of the servers.

But you don't have to look far before you hit snags like this:
https://www.norid.no/en/om-domenenavn/regelverk-for-no/vedlegg-f/

So although I techincally could run IPv6 only on all but one of the DNS
servers, this would violate current policy.  Oddly enough, running IPv4
only on all servers is allowed.  Go figure.

> Why is this not possible now? Why would we not sign this mutual
> agreement for 2040? Otherwise we'll be having this same discussion in
> 2040.

Signing such a contract would be pretty stupid from a commercial pov.
The growth isn't exponential anymore.  It's linear at best.  You can
probably run just fine with an IPv4 only network after 2040.  Not so
sure about the IPv6 only network.


Bjørn

Re: IPv6 woes - RFC

[Bjørn Mork]

JORDI PALET MARTINEZ via NANOG  writes:

> It is simple, most of your traffic will use IPv6. Depending on your
> network/customer base 65-85%.
>
> You need less and less IPv4 addresses in the NAT64, less NAT64 boxes.
>
> Less resources to operate IPv6-only vs dual-stack.
>
> And because the IPv6 traffic is going up more and more with the time,
> you can keep reducing IPv4 addresses and NAT64 boxes. If you are using
> boxes that can be used for other functionalities, you even "recover"
> part of you initial investment.

You're assuming that IPv6 is required.  There is no reason do do that in
the current Internet.  IPv6 is still optional. The number of users who
care about IPv6 access is very close to 0 and dropping.

And as demonstrated in this thread: Even the few who still do care are
not willing to pay extra, or sacrifice anything, for IPv6.  They will
run off to your competitor as soon as they discover the price is lower
there. Which it will be since they saved a lot by building and running
an IPv4 only access network.



Bjørn

Re: IPv6 woes - RFC

[Bjørn Mork]

JORDI PALET MARTINEZ via NANOG  writes:

> All this is resolved using IPv6-only and IPv4aaS, the same way as
> cellular providers are doing with 464XLAT.

Sure, there are a gazillion ways to provde edge access to both IPv4 and
IPv6.  You can pick anyone you like.  But the extra layers still do not
come for free.

And cellular providers give you a single /64.  Not even useful as IPv6
access for anything larger than a single handset.  Extending that /64 to
something you can use is non-trivial.  How many providers have actually
done that?

And how many end users cared?




Bjørn

Re: IPv6 woes - RFC

[Bjørn Mork]

Saku Ytti  writes:
> On Mon, 6 Sept 2021 at 10:20, Bjørn Mork  wrote:
>
>> Adding new access infrastructure of any sort (Fixed Wireless is the
>> hype...)?  Why would you want to continue being stupid even if you
>> implemented dual-stack for all your fibre, hfc and dsl customers?  You
>> can save a lot by dropping dual-stack complexities in PGWs and FWA CPEs,
>> even if we assume most of the fibre/hfc/dsl value chain is reused.
>
> Can you? You need to offer IPv4 anyhow and all the complexities
> related to that, i.e. some stateful box. Why would I offer in addition
> to that IPv6, which is not being requested by anyone. And by anyone I
> mean anyone I want as customer, as those who request it, are probably
> going to be expensive to support and I need to subsidise those with my
> regular customers, so I'd rather not cater to those.


Exactly. The existing dual-stack deployments will die out as access
infra-structure is replaced.



Bjørn

Re: IPv6 woes - RFC

[Bjørn Mork]

Saku Ytti  writes:

> I absolutely HATE testing, developing and supporting IPv4+IPv6, more
> than doubling my time, adding 3rd stack would actually not increase
> cost that much, it's the 1=>2 which is fantastically expensive. And
> costs are transferred to customers.

+1

> Those who have not done _anything_ with IPv6, have done the right
> thing from business POV, they've had lowest cost, least issues and
> have had other people pay for the improvements of the stack. And even
> today, I see no business sense deploying IPv6.

The state is not static.  The difference is there for any (partially)
new deployment.

Adding new access infrastructure of any sort (Fixed Wireless is the
hype...)?  Why would you want to continue being stupid even if you
implemented dual-stack for all your fibre, hfc and dsl customers?  You
can save a lot by dropping dual-stack complexities in PGWs and FWA CPEs,
even if we assume most of the fibre/hfc/dsl value chain is reused.



Bjørn

Re: IPv6 woes - RFC

[Bjørn Mork]

Saku Ytti  writes:

> I view IPv6 as the biggest mistake of my career and feel responsible
> for this horrible outcome and I do apologise to Internet users for
> it. This dual-stack is the worst possible outcome, and we've been here
> over two decades, increasing cost and reducing service quality. We
> should have performed better, we should have been IPv6 only years ago.

I believe this is slowly sinking in among the technology evangelists and
geeks who managed to drive the half-assed dual-stack transition a decade
or two ago. No one will argue for dual-stack anymore.

So where does that put us in a decade or two?  Which protocol is
optional?



Bjørn

Re: Where to get IPv4 block these day

[Bjørn Mork]

Randy Bush  writes:

> what i love most about the why ipv6 {has not deployed | does not work
> for me | must be used immediately if not sooner | ...} is that it
> provides such a rich field for posting to nanog etc.  and folk think of
> new brilliant discussion points every day.  

+1

The endless repetitions brings back that warm fuzzy USENET-feeling.
Thanks NANOG!


Bjørn

Re: FreeBSD's ping Integrates IPv6

[Bjørn Mork]

Mark Tinka  writes:

> Been nearly 14 years since I last operated a Linux machine.

I seriously doubt that.  You're just not aware of it.


Bjørn

Re: NAT devices not translating privileged ports

[Bjørn Mork]

Fernando Gont via NANOG  writes:

> What has been reported to us is that some boxes do not translate the
> src port if it's a privileged port.
>
> IN such scenarios, NTP implementations that always use src port=123,
> dst port=123 might be in trouble if there are multiple NTP clients
> behind the same NAT device

This problem used to be very common for 500/udp.  Ref
https://datatracker.ietf.org/doc/html/rfc3715#section-2.3


Bjørn

Re: amazon.com multiple SPF records

[Bjørn Mork]

Jean St-Laurent via NANOG  writes:

> What is spf2.0/pra ?

https://datatracker.ietf.org/doc/html/rfc4406

It doesn't say April 1st, but it is pretty close


Bjørn

Re: DANE of SMTP Survey

[Bjørn Mork]

Jeroen Massar via NANOG  writes:

> For many organisations DNSSEC is 'scary' and a burden as it feels
> 'fragile' for them.

For "many"?  Can you name one that doesn't feel like that?

https://www.arin.net/vault/announcements/2019/20190204.html
https://www.ripe.net/support/service-announcements/dnssec-validation-problem-with-ripe.net

DNSSEC *is* scary, fragile and a burden.  The question is whether the
alternatives are worse.


Bjørn

Re: Juniper hardware recommendation

[Bjørn Mork]

Adam Thompson  writes:


>   * Skip the MX 2k/10k series – they don’t support SFP+ interfaces!

https://apps.juniper.net/hct/model/?component=MX2K-MPC6E
https://apps.juniper.net/hct/model/?component=MIC6-10G


Bjørn

Re: Myanmar internet - something to think about if you're having a bad day

[Bjørn Mork]

scott  writes:

> Telenor and Ooredoo, it's time to do the right thing.

Wrt Telenor, please see the info posted at
https://www.telenor.com/sustainability/responsible-business/human-rights/mitigate/human-rights-in-myanmar/directives-from-authorities-in-myanmar-february-2021/


Bjørn

Time to validate the TLS configuration on your SMTP servers (was: Re: AS5 ipv6 hijack?)

[Bjørn Mork]

OK, so that email bounced.  Or will eventually because this does not go
away with someone doing something:

  ... Deferred: 403 4.7.0 TLS handshake failed.

I am posting this in public because it unfortunately is a very common
problem.

Debian buster was released on July 6th, 2019. It includes openssl 1.1.1
with this configuration update among number of other improvements:

openssl (1.1.1~~pre6-1) experimental; urgency=medium

  * New upstream version
  * Increase default security level from 1 to 2. This moves from the 80 bit
security level to the 112 bit securit level and will require 2048 bit RSA
and DHE keys.

 -- Kurt Roeckx   Tue, 01 May 2018 16:00:55 +0200


I assume similar policies have been applied to all modern and maintained
operating systems by now.

Everyone should verify their own SMTP servers to avoid losing email due
to TLS failures.  Doing so is simple from e.g Debian:


bjorn@canardo:/usr/local/src/openwrt$ cd

   
bjorn@canardo:~$ host interhost.net 

   
interhost.net has address 185.18.204.66
interhost.net mail is handled by 10 pineapp.interhost.co.il.

bjorn@canardo:~$ openssl s_client -quiet -connect pineapp.interhost.co.il:25 
-starttls smtp
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global 
Root CA
verify return:1
depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = RapidSSL RSA CA 
2018
verify return:1
depth=0 CN = *.interhost.co.il
verify return:1
139901908640896:error:141A318A:SSL routines:tls_process_ske_dhe:dh key too 
small:../ssl/statem/statem_clnt.c:2150:


The fix obviously depends on the server, but is usually as simple as
regnerating the DH parameters.  See for example
https://forums.freebsd.org/threads/sendmail-dh-key-too-small.51985/



Bjørn

Re: AS5 ipv6 hijack?

[Bjørn Mork]

Dmitry Sherman  writes:

> I see ipv6 bgp hijack of our prefixes via AS5.

Or misunderstood prepending attempt, like hijacks from low AS numbers
often are?



Bjørn

Re: login.authorize.net has A and CNAME records

[Bjørn Mork]

Mark Andrews  writes:

> It shouldn’t matter.  Only non-rfc-compliant servers allow A and CNAME
> to co-exist at the same name.  That combination was prohibited by RFC
> 1034.

Right.  Thanks.  I confused myself multiple times here ;-)


The issue seems to be that the cloudflare servers takes a shortcut and
convert the CNAME to A, dropping the intermediate CNAME.   That's
obviously not OK.


So it looks correct when you do:


bjorn@miraculix:/tmp$ dig CNAME login.authorize.net 
@ns0210.secondary.cloudflare.com

; <<>> DiG 9.16.13-Debian <<>> CNAME login.authorize.net 
@ns0210.secondary.cloudflare.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52372
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;login.authorize.net.   IN  CNAME

;; ANSWER SECTION:
login.authorize.net.300 IN  CNAME   
login.authorize.net.cdn.cloudflare.net.

;; Query time: 28 msec
;; SERVER: 162.159.33.85#53(162.159.33.85)
;; WHEN: Wed Apr 07 10:01:23 CEST 2021
;; MSG SIZE  rcvd: 97

bjorn@miraculix:/tmp$ dig A login.authorize.net.cdn.cloudflare.net 
@ns0210.secondary.cloudflare.com

; <<>> DiG 9.16.13-Debian <<>> A login.authorize.net.cdn.cloudflare.net 
@ns0210.secondary.cloudflare.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54740
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;login.authorize.net.cdn.cloudflare.net.IN A

;; ANSWER SECTION:
login.authorize.net.cdn.cloudflare.net. 300 IN A 104.18.8.127
login.authorize.net.cdn.cloudflare.net. 300 IN A 104.18.9.127

;; Query time: 28 msec
;; SERVER: 162.159.33.85#53(162.159.33.85)
;; WHEN: Wed Apr 07 10:01:41 CEST 2021
;; MSG SIZE  rcvd: 99



But not when you query for A directly:



bjorn@miraculix:/tmp$ dig A login.authorize.net @ns0210.secondary.cloudflare.com

; <<>> DiG 9.16.13-Debian <<>> A login.authorize.net 
@ns0210.secondary.cloudflare.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26197
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;login.authorize.net.   IN  A

;; ANSWER SECTION:
login.authorize.net.300 IN  A   104.18.9.127
login.authorize.net.300 IN  A   104.18.8.127

;; Query time: 24 msec
;; SERVER: 162.159.33.85#53(162.159.33.85)
;; WHEN: Wed Apr 07 10:02:25 CEST 2021
;; MSG SIZE  rcvd: 80



So a Cloudflare bug.



Bjørn

Re: login.authorize.net has A and CNAME records

[Bjørn Mork]

Bjørn Mork  writes:

> Seth Mattinen  writes:
>> On 4/6/21 11:35 AM, Arne Jensen wrote:
>>> login.authorize.net. is a CNAME, but does not have any A records itself.
>>
>>
>> This one returns A records:
>
> Looks like they host DNS on both cloudflare and akami, but zone contents
> are different on the two platforms:
>
>  bjorn@miraculix:~$ for s in $(dig +short ns authorize.net|sort); do echo -n 
> "$s: ";dig +short login.authorize.net @$s|xargs; done
>  a10-64.akam.net.: login.authorize.net.cdn.cloudflare.net.
>  a1-190.akam.net.: login.authorize.net.cdn.cloudflare.net.
>  a2-65.akam.net.: login.authorize.net.cdn.cloudflare.net.
>  a9-64.akam.net.: login.authorize.net.cdn.cloudflare.net.
>  ns0090.secondary.cloudflare.com.: 104.18.8.127 104.18.9.127
>  ns0210.secondary.cloudflare.com.: 104.18.9.127 104.18.8.127

Doh! I should know better.  Sorry, ignore that.  Don't ask for A records
if you want to see CNAMEs..


Bjørn

Re: login.authorize.net has A and CNAME records

[Bjørn Mork]

Seth Mattinen  writes:
> On 4/6/21 11:35 AM, Arne Jensen wrote:
>> login.authorize.net. is a CNAME, but does not have any A records itself.
>
>
> This one returns A records:

Looks like they host DNS on both cloudflare and akami, but zone contents
are different on the two platforms:

 bjorn@miraculix:~$ for s in $(dig +short ns authorize.net|sort); do echo -n 
"$s: ";dig +short login.authorize.net @$s|xargs; done
 a10-64.akam.net.: login.authorize.net.cdn.cloudflare.net.
 a1-190.akam.net.: login.authorize.net.cdn.cloudflare.net.
 a2-65.akam.net.: login.authorize.net.cdn.cloudflare.net.
 a9-64.akam.net.: login.authorize.net.cdn.cloudflare.net.
 ns0090.secondary.cloudflare.com.: 104.18.8.127 104.18.9.127
 ns0210.secondary.cloudflare.com.: 104.18.9.127 104.18.8.127

Interesting enough the serial number is consistent though:

 bjorn@miraculix:~$ for s in $(dig +short ns authorize.net|sort); do echo -n 
"$s: ";dig +short soa authorize.net @$s; done
 a10-64.akam.net.: ns1.dnsvisa.com. premiumdns.support.neustar. 2019103361 600 
300 1209600 300
 a1-190.akam.net.: ns1.dnsvisa.com. premiumdns.support.neustar. 2019103361 600 
300 1209600 300
 a2-65.akam.net.: ns1.dnsvisa.com. premiumdns.support.neustar. 2019103361 600 
300 1209600 300
 a9-64.akam.net.: ns1.dnsvisa.com. premiumdns.support.neustar. 2019103361 600 
300 1209600 300
 ns0090.secondary.cloudflare.com.: ns1.dnsvisa.com. premiumdns.support.neustar. 
2019103361 600 300 1209600 300
 ns0210.secondary.cloudflare.com.: ns1.dnsvisa.com. premiumdns.support.neustar. 
2019103361 600 300 1209600 300


I wish I could say that this is surprising



Bjørn

Re: DoD IP Space

[Bjørn Mork]

Ca By  writes:

> The 3 cellular networks in the usa, 100m subs each, use ipv6 to uniquely
> address customers. And in the case of ims (telephony on a celluar), it is
> ipv6-only, afaik.

I certainly agree that this is easier and makes more sense.  I just
don't buy the "can't be done" wrt using rfc1918.


Bjørn

Re: DoD IP Space

[Bjørn Mork]

Ca By  writes:

> On Wed, Feb 10, 2021 at 4:32 AM Valdis Klētnieks 
> wrote:
>
>> On Wed, 10 Feb 2021 04:04:43 -0800, Owen DeLong said:
>> > Please explain to me how you uniquely number 40M endpoints with RFC-1918
>> without running out of
>> > addresses and without creating partitioned networks.
>>
>> OK.. I'll bite.  What network design needs 40M endpoints and can't tolerate
>> partitioned networks?  There's eyeball networks out there that have that
>> many
>> endpoints, but they end up partitioned behind multiple NAT boxes.
>>
>>
> Why would you assume partitioning is an acceptable design constraint ?
>
> I don’t think the cellular networks in the USA, each with over a 100M
> subscribers, wants their customers partitioned, and that is why the IMS /
> SIP on each modern phone is exclusively ipv6, afaik

You don't need to partition the customers to partition the network.
It's not like any single network entity scales to a 100M sessions in any
case.  You will need more than one SIP server.

You'll have multiple instances of "that user with 10.10.10.10", but
that's easily addressed that by including the associated network
segment.  So you have "that user with 10.10.10.10 in segment A" and
"that user with 10.10.10.10 in segment B". They can both be part of the
same customer database or whatever


Bjørn

Re: DoD IP Space

[Bjørn Mork]

Owen DeLong  writes:

> Please explain to me how you uniquely number 40M endpoints with RFC-1918 
> without running out of
> addresses and without creating partitioned networks.
>
> If you can’t, then I’m not the one making excuses.


You added "without ..." and did not explain why.  This does look a bit
like an excuse to me.  But there is probably some explanation I don't
see.

Why would you not partition the network?


Bjørn

Re: "Hacking" these days - purpose?

[Bjørn Mork]

For fun and/or profit.  Like the purpose always has been.

Note that the definition of fun will vary.  But overcoming a challenge
of some sort is almost universally considered "fun".


Bjørn

Re: Centurylink having a bad morning?

[Bjørn Mork]

Eric Kuhnke  writes:

> There's a number of enterprise end user type customers of 3356 that have
> on-premises server rooms/hosting for their stuff. And they spend a lot of
> money every month for a 'redundant' metro ethernet circuit that takes
> diverse fiber paths from their business park office building to the local
> clink/level3 POP. But all that last mile redundancy and fail over ability
> doesn't do much for them when 3356 breaks its network at the BGP level.

Well, many of us are paying for redundant power supplies or redundant
REs, even if that doesn't make any difference when the chassis is on
fire.  I guess most people know that, and still buy those redundant
components.

It's always about cost versus risk.  I certainly hope nobody here
believe single homed is completely failsafe.

(the lack of withdrawal making multi homed customers fail too is more
unexpected, and a new factor to consider in the future)


Bjørn

Re: Ipv6 help

[Bjørn Mork]

Brian Johnson  writes:

>> 1) It needs *much less* IPv4 addresses (in the NAT64) for the same number of 
>> customers.
>
> I cannot see how this is even possible. If I use private space
> internally to the CGN, then the available external space is the same
> and the internal customers are the same and I can do the same over sub
> ratio under both circumstance. Tell me how the math is different.

Because NAT64 implies DNS64, which avoids NATing any dual stack service.
This makes a major difference today.


Bjørn

Re: TCP and UDP Port 0 - Should an ISP or ITP Block it?

[Bjørn Mork]

What problem are you trying to solve?


Bjørn

Re: Ipv6 help

[Bjørn Mork]

Brandon Martin  writes:
> On 8/25/20 3:38 PM, JORDI PALET MARTINEZ via NANOG wrote:
>> This is very common in many countries and not related to IPv6, but
>> because many operators have special configs or features in the CPEs
>> they provide.
>
> I really, really hate to force users to use my network edge router (I
> provide the ONT, though, and I provide an edge router that works and
> most users do take it), but it can be tough to ensure users have
> something that supports all the right modern features and can be
> configured via standard means.

You aren't forcing anything if you allow the users to use any CPE and
document the features it must/should have.

 You want IPv4 access without DNS? Then you need CLAT
 You don't know what CLAT is?  Call your CPE vendor for support
 You don't care what CLAT is?  Use our CPE
 You want to call us for support?  Use our CPE

There is no force here.  It all is pretty similar to

 You want to connect the CPE to our ONT?  Then you need Ethernet
 etc.
 
excluding all those TokenRing routers.

> It would be nice if the consumer router industry could get its
> collective act together and at least come up with some easy-ish to
> understand feature support table that customers can match up with
> their service provider's list of needs.

If you create such a feature table as the service provider, and the
customer is unable to match it against their CPE documentation, then
that's a problem between the CPE vendor and the customer.

I can't understand why you want to make it your problem, as long as you
offer a CPE that just works.


Bjørn

Re: understanding IPv6

[Bjørn Mork]

On Sun, Jun 7, 2020 at 2:00 AM Fred Baker  wrote:

>  I'm sorry you have chosen to ignore documents like RFC 3315, which is
>  where DHCP PD was first described (in 2003). It's not like anyone's
>  hiding it.

Erhm, you probably meant RFC 3633 (also 2003).  There was no PD in the
original DHCPv6 spec


Bjørn

Re: understanding IPv6

[Bjørn Mork]

Daniel Sterling  writes:

> In all seriousness, I have been trying to understand IPv6 for a long
> time, and the documentation that I read (again, admittedly not often
> RFCs, but certainly Wikipedia, linux distro docs, etc) never mentioned
> DHCP PD, or at least never mentioned it as something important for how
> end-users would use IPv6.

Sorry, but I have some problems understanding this. AFAICT, you can't
read anything about configuring IPv6 access without seeing DHCPv6-PD
mentioned.

You referred to how OpenWrt "does it out of the box" for example.  So
just for fun, I tried to follow the most natural route from
https://openwrt.org to their IPv6 documentation for end users, which is
3 clicks from the front page to
https://openwrt.org/docs/guide-user/network/ipv6/start
where the first bullet point you see under "Native IPv6 connection" is
  * Automatic bootstrap from SLAAC, stateless DHCPv6, stateful DHCPv6,
DHCPv6-PD and any combination



Bjørn

Don't email clients have a kill file?

[Bjørn Mork]

At the risk of starting an off topic discussion here, but am I the only
one who'd like to see more plonks and less troll feeding?

I miss Usenet.


Bjørn

Re: Are underground utility markers essential workers?

[Bjørn Mork]

Nick Hilliard  writes:

> we have a very poorly-defined idea of what constitutes an "essential
> worker"

I thought "management" was the definition of non-essential workers. Who
else would have a job without being essential/critical for day-to-day
business?


Bjørn

Re: free collaborative tools for low BW and losy connections

[Bjørn Mork]

Nick Hilliard  writes:

> nntp is a non-scalable protocol which broke under its own
> weight.

How is nntp non-scalable?  It allows an infinite number of servers
connected in a tiered network, where you only have to connect to a few
other peers and carry whatever part of the traffic you want.

Binaries broke USENET.  That has little to do with nntp.

nntp is still working just fine and still carrying a few discussion
groups here and there.  And you have a really nice mailling list gateway
at news.gmane.io (which recently replaced gmane.org - see
https://lars.ingebrigtsen.no/2020/01/15/news-gmane-org-is-now-news-gmane-io/
for full story)


Bjørn

Re: Gmail email blocking is off the rails (again)

[Bjørn Mork]

"John Levine"  writes:

> Google accepts my mail just fine, including from my mailing lists.
> Their goal is to make their users happy by accepting the mail the
> users want and not the mail the users don't want.

If we rule out asking the users for every mail, then that means applying
statistics on empirical data.  The problem is that smoothing the edges
might throw away mail that the recipient care about, just because most
other users didn't.

Small players risk being blocked on the sole reason that they are too
small to make any measurable number of gmail users want their mail.



Bjørn

Re: Disney+ Streaming

[Bjørn Mork]

Sure. Like we all have been begging for an "Internet service" without
any peering...

The consumers have been begging for unbundling of content and transport.
This does not imply fragmentation of either. That's a content provider
straw man.  It is only reasonable to assume that all content providers
will see the benefit in mutual agreements for content exchange with all
other content providers.  Just like it's reasonable to assume your ISP
will let you access services hosted by some other ISP.

Of course, if ISPs wanted to make money then they would have tried to
monopolize the market by fragmentation.  Not..



Bjørn

Owen DeLong  writes:

> While I agree about the likely outcome, I will point out that consumers have 
> been
> begging for unbundling for years.
>
> This fragmentation of streaming services _IS_ the direct result of that 
> request.
>
> It’s unbundled service, exactly what they have been asking for.
>
> Owen
>
>
>> On Nov 26, 2019, at 01:54 , Mark Tinka  wrote:
>> 
>> 
>> 
>> On 12/Nov/19 22:36, Brian J. Murrell wrote:
>> 
>>> 
>>> I actually suspect streaming is going to decline (at least in
>>> comparison to where it could have grown to) if this streaming service
>>> fragmentation continues.
>>> 
>>> I think people are going to reject the idea that they need to subscribe
>>> to a dozen streaming services at $10-$20/mo. each and will be driven
>>> back the good old "single source" (piracy) they used to use before 1
>>> (or perhaps 2) streaming services kept them happy enough to abandon
>>> piracy.
>>> 
>>> The content providers are going to piss in their bed again due to
>>> greed.  Again.
>> 
>> This!
>> 
>> At the beginning of this year, I dumped Prime Video because while I
>> initially got it for "The Grand Tour", almost all the other content was
>> not available in Africa. Didn't see the point of shelling out over
>> US$100/year for just one show, especially since we already have Netflix
>> + a local linear pay TV service.
>> 
>> I bought the wife a new iPhone 11 Pro earlier this month. This got us
>> 1-year's worth of free AppleTV+. Not a lot of content so far, but I hear
>> the same about Disney+. Granted 2 of the 3 shows on TV+ are not bad. But
>> it's free, so what the heck.
>> 
>> I'm not keen on paying for more than one streaming service, if I'm
>> honest. There already isn't enough time in the world for regular life,
>> never mind watching one streaming service... now we have to deal with
>> more, each with their own price? Not sure how well the streaming
>> providers expect regular folk to take all of this fragmentation.
>> 
>> As my daughter would say, "They can miss me with it :-)".
>> 
>> Mark.
>> 

Re: BGP over TLS

[Bjørn Mork]

Christopher Morrow  writes:

> The x.509 system, to be effective here would require a TrustAnchor /
> Root-of-Trust that both parties agreed was acceptable...

As in a shared TrustAnchor?  No.  Both ends could use a simple self
signed certificate and be configured to trust the other.  A hash of the
peers public key would be sufficient for the BGP peer configuration.

Or you could use more complex PKI models, with a CA hierarchy or
whatever.  The point is that TLS doesn't force you to do that

Authenticating the peer by its public key hash is as simple as using an
TCP-MD5 password.

> To get around that you propose we hopscotch over to 'TLS with
> preshared keys (PSK)'...ok, that smells nice,

Maybe.  Personally I don't see the point.

>> My personal major gripe with certificate based systems is that many
>> routers don't have an RTC and won't know what time it is until they can
>> NTP, which likely requires protocol adjacencies, and then a dependency loop.
>
> this is also a problem, but really ... your igp should get you to an
> NTP source... or we'd all get to that fairly quickly, right? :)
>   (some of this is updating 'best practices' in building / maintaining
> a network, right?)

You may ignore notAfter and notBegin like DANE does. The ntp issue is
another reason.  But IMHO the most important one is that you don't want
any sort of forced key rotation, where the configuration that was valid
yesterday suddenly becomes invalid.  That's a policy designed for a
completely different usecase than running a routing protocol.

You'll probably want to trust your configured pinned peer key for as
long as it is part of your configuration.  And if you are using a CA,
then you'll probably want to use a CRL to withdraw specific certificates
instead of depending on a timeout.

And before someone claims that notAfter and notBegin validation is
mandated by the RFC 5280 certificate policy - The good authors of RFC
5280 anticipated that their "Internet applications" policy wouldn't
necessarily fit all:

   Some communities will need to supplement, or possibly replace, this
   profile in order to meet the requirements of specialized application
   domains or environments with additional authorization, assurance, or
   operational requirements.  However, for basic applications, common
   representations of frequently used attributes are defined so that
   application developers can obtain necessary information without
   regard to the issuer of a particular certificate or certificate
   revocation list (CRL).


BTW, using TLS for management protocols is not completely unknown.  We
already have RADSEC (RFC 6614) and syslog-tls (RFC 5425), and probably
others I haven't touched yet.  The certificate management problem is
pretty much the same for all these.  You have a closed group of
clients/servers/peers using explicitly configured sessions.  You want
both ends to authenticate each other.  You don't necessarily want an
umbrella trust anchor in the form of a CA.  Defining trust per session
is fine, using pinned certificates.


Bjørn

Re: BGP over TLS

[Bjørn Mork]

Jeffrey Haas  writes:

>  Exactly how the cert lifetime interacts with peering sessions is
>  likely to be several flavors of ugly.

If you pin the key, then there is no reason to care about expiration.
You could define the certificate as valid for as long as the pinned key
matches.  This is similar to what DANE does.


Bjørn

BGP over TLS (was: Re: "Using Cloud Resources to Dramatically Improve Internet Routing")

[Bjørn Mork]

Christopher Morrow  writes:

> isn't julien's idea more akin to DOT then DOH ?

Yes, and I really like Julien's proposal.  It even looks pretty
complete.  There are just a few details missing around how to make the
MD5 => TLS transition smooth.

Sorry for any confusion caused by an attempt to make a joke on DoH.  I
didn't anticipate the sudden turn to serious discussion :-)  Which
obviously was a good one.  I am all for BGP over TLS, so let's discuss
https://laptop006.livejournal.com/60532.html



Bjørn

Re: "Using Cloud Resources to Dramatically Improve Internet Routing"

[Bjørn Mork]

Julien Goodwin  writes:
> On 20/10/19 11:08 pm, Bjørn Mork wrote:
>> Hank Nussbacher  writes:
>>> On 07/10/2019 17:42, Stephane Bortzmeyer wrote:
>>>> On Fri, Oct 04, 2019 at 03:52:26PM -0400,
>>>>   Phil Pishioneri  wrote
>>>>   a message of 9 lines which said:
>>>>
>>>>> Using Cloud Resources to Dramatically Improve Internet Routing
>>>>> UMass Amherst researchers to use cloud-based ‘logically centralized
>>>>> control’
>>>> Executive summary: it's SDN for BGP. Centralizing Internet routing,
>>>> what could go wrong? (As the authors say, "One reason is there is no
>>>> single entity that has a big picture of what is going on, no
>>>> manager". I wonder who will be Internet's manager.)
>>>>
>>> Centralized Internet routing - sounds like DoH for BGP.
>> 
>> Great idea!  Why don't we just run BGP over HTTPS?  Everyone already has
>> a browser, so we can get rid of all these expensive routers.
>
> IMO BGP over TLS actually makes a bunch of sense,

Absolutely.  And so does DNS over TLS. A lot of sense.

But if you start encoding the BGP protocol data in the TLS session as
HTTP so you can tunnel it over a shared 443 port to some distant
endpoint, and even traverse HTTP proxies, then it would look like a
joke.

Or in the DoH case, would make you wish it was a joke.


Bjørn

Re: "Using Cloud Resources to Dramatically Improve Internet Routing"

[Bjørn Mork]

Hank Nussbacher  writes:
> On 07/10/2019 17:42, Stephane Bortzmeyer wrote:
>> On Fri, Oct 04, 2019 at 03:52:26PM -0400,
>>   Phil Pishioneri  wrote
>>   a message of 9 lines which said:
>>
>>> Using Cloud Resources to Dramatically Improve Internet Routing
>>> UMass Amherst researchers to use cloud-based ‘logically centralized
>>> control’
>> Executive summary: it's SDN for BGP. Centralizing Internet routing,
>> what could go wrong? (As the authors say, "One reason is there is no
>> single entity that has a big picture of what is going on, no
>> manager". I wonder who will be Internet's manager.)
>>
> Centralized Internet routing - sounds like DoH for BGP.

Great idea!  Why don't we just run BGP over HTTPS?  Everyone already has
a browser, so we can get rid of all these expensive routers.

The future is BoH


Bjørn

Re: Elad Cohen

[Bjørn Mork]

Jon Sands  writes:
> On 9/19/2019 6:12 AM, Ronald F. Guilmette wrote:
>>
>> I just want to ruling on this.  Am I the first and only person who has ever
>> received a cartooney directly on the NANOG list?
>
> I can't remember if it was over NANOG or not, but back in 2010 a good
> friend of mine Mike Bailey (now deceased) received similar bold faced
> legal threats (mostly threats of DMCA if I remember right) from FDC
> Servers when he exposed to the WHT forums that they were at the time
> using power strips daisy chained, motherboards sitting on cardboard,
> etc in their chicago datacenter - he documented with pictures a number
> of fire code violations and was threatened with DMCA notices for
> it. Sadly the pictures no longer load, but oh boy were they special:
> https://web.archive.org/web/20100228172939/http://ub3r.net/fdc/readme.htm

You can see one of those pics here:
https://itknowledgeexchange.techtarget.com/IT-watch-blog/fdcservers-colocation-data-center-gives-new-life-to-the-term-boxen/

> I do agree though, this should probably be taken way off-list.

Sure.  But there is still some popcorn left ;-)


Bjørn

Re: Mx204 alternative

[Bjørn Mork]

Mark Tinka  writes:

> The MX80 and MX104 have no business being in any modern conversation
> these days :-).

Except for the other MX-80, of course, which are better than ever.
https://en.wikipedia.org/wiki/MX-80


Bjørn

Re: Protecting 1Gb Ethernet From Lightning Strikes

[Bjørn Mork]

Måns Nilsson  writes:

> /Måns, has 6 pairs 9/125 between garage and house at home. 

Now you made me worry that my single OM4 pair to the garden shed might
be insufficient ;-)


Bjørn

Re: SFP supplier in Europe?

[Bjørn Mork]

nanog-...@mail.com writes:

> Unfortunately Fiberstore is what led me to ask about alternative
> suppliers. Fiberstore actually ships in their Bidi SFPs from Asia


Odd. They have lots of different BiDi SFFs "in Stock, EU Warehouse"
according to https://www.fs.com/de-en/c/bidi-sfp-89

> and lead times are one to two weeks.

My experience is that they ship a lot faster than that from Asia too,
but I guess I've just been lucky.


Bjørn

Re: ICMPv6 "too-big" packets ignored (filtered ?) by Cloudflare farms

[Bjørn Mork]

Stephen Satchell  writes:

> On 3/5/19 2:54 AM, Thomas Bellman wrote:
>> Out of curiosity, which operating systems put anything useful (for use
>> in ECMP) into the flow label of IPv6 packets?  At the moment, I only
>> have access to CentOS 6 and CentOS 7 machines, and both of them set the
>> flow label to zero for all traffic.
>
> Did you submit a bug report?

I believe this was fixed 5 years ago (in Linux v3.17):
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cb1ce2ef387b01686469487edd45994872d52d73

But RHEL and CentOS are using kernels from the stone age, so they
haven't noticed yet.


Bjørn

Re: a detour DANE, was A Deep Dive on the Recent Widespread DNS Hijacking

[Bjørn Mork]

Måns Nilsson  writes:

> NS5
>   21
> DNSKEY3
> SPF   1
> A 28
> NSEC  62
> AFSDB 3
> RP1
> MX2
> CNAME 9
> SOA   2
> RRSIG 147
> TXT   6
> SSHFP 14
> SRV   20
> DS4
> Total:16 rrtypes in zone

No TLSA records? 


Bjørn

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Bjørn Mork]

Bill Woodcock  writes:

> We need to get switched over to DANE as quickly as possible, and stop
> wasting effort trying to keep the CA system alive with ever-hackier
> band-aids.

Sure. Just won't happen as long as there is money left in the CA
business.


Bjørn

Re: sendmail.cf

[Bjørn Mork]

b...@theworld.com writes:

> The predecessor to sendmail was delivermail, 1979, also written by
> Eric Allman.
>
>   https://en.wikipedia.org/wiki/Delivermail

Damn.  Now you made me read RFC801 and wonder why we didn't have an
updated version for the IPv6 transition.  Or: Where would the Internet
have been today without that very explicit "complete switch over" goal?


Bjørn

Re: DNS Flag Day, Friday, Feb 1st, 2019

[Bjørn Mork]

Mark Andrews  writes:

> I’ve been complaining for YEARS about lack of EDNS compliance.

Didn't help.

bjorn@miraculix:~$  dig +edns=42 +noednsnegotiation @1.1 

; <<>> DiG 9.11.5-P1-1-Debian <<>> +edns=42 +noednsnegotiation @1.1
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40525
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1452
;; QUESTION SECTION:
;.  IN  NS

;; ANSWER SECTION:
.   9060IN  NS  d.root-servers.net.
.   9060IN  NS  e.root-servers.net.
.   9060IN  NS  f.root-servers.net.
.   9060IN  NS  g.root-servers.net.
.   9060IN  NS  h.root-servers.net.
.   9060IN  NS  i.root-servers.net.
.   9060IN  NS  j.root-servers.net.
.   9060IN  NS  k.root-servers.net.
.   9060IN  NS  l.root-servers.net.
.   9060IN  NS  m.root-servers.net.
.   9060IN  NS  a.root-servers.net.
.   9060IN  NS  b.root-servers.net.
.   9060IN  NS  c.root-servers.net.

;; Query time: 3 msec
;; SERVER: 1.0.0.1#53(1.0.0.1)
;; WHEN: Thu Jan 24 14:40:00 CET 2019
;; MSG SIZE  rcvd: 431



Bjørn

Re: the e-mail of the future is the e-mail oft the past, was Enough port 26 talk...

[Bjørn Mork]

Miles Fidelman  writes:

> Ever since the net went commercial, we've been seeing more and more
> walled gardens - driven by folks with an economic advantage to
> segmenting & capturing audiences.  Whenever someone talks about how
> great some new technology is, I'm always reminded to "follow the
> money."  (And ain't it ironic that Microsoft supports calendaring
> protocols, while Google breaks them.)

And this is happening to email too.

It's not IM or online conferencing that will kill email, but
fragmentation into multiple closed email environments. We accept SPF and
DMARC, abusing DNS to deliberately break SMTP. All in the name of spam
protection, Mailing lists barely work anymore and have to resort to
hacks to be able to forward messages to their recipients.  Traditional
forwarding to another account hasn't worked in years. Smaller providers
are regularily blocked causing service disruption to their users.

It's just a matter of time before the big players, well known for their
disregard of open protocols, just shut off SMTP completely. They'll
probably "invent" something much better as an excuse... And the masses
will love them for that, because it finally removed the spam "problem".

And everyone has a gmail account anyway, so why bother with outside
email?



Bjørn

Re: Enough port 26 talk...

[Bjørn Mork]

Yes.  What is all the fuzz about?  Email will be as dead as USENET in a
couple of years anyway.

Welcome to the age of "feeds".  You may cry now.


Bjørn

Re: WIndows Updates Fail Via IPv6

[Bjørn Mork]

John Von Essen  writes:

> I recently go a Linksys home wifi router, by default it enables ipv6
> on the LAN. If there is no native IPv6 on the WAN side (which is my
> case since FiOS doesnt do v6 yet) the Linksys defaults to a v6 tunnel.

Could this be a 6RD tunnel requested by your ISP using DHCP with
OPTION_6RD? Ref RFC5969

Setting up any tunnel to some pre-configured endpoint by default does
not sound like a good idea  But DHCP on the WAN side is "trusted",
so configuring a DHCP requested tunnel by default is reasonable.

> For the first few weeks of using the router, I had no idea alot of my
> traffic was going out via the v6 tunnel.
>
> Then I started getting random reachability and availability
> issues. Google would not load, but Bing and Yahoo would, and so on. I
> thought it was a FiOS issue, but after digging, I discovered the v6
> tunnel, disabled it and all my issues went away.
>
> I dont know what Linksys uses for the v6 tunnel because its buried in
> the firmware, but any tunnel service is vulnerable to a variety of
> issues that could effect access. Its odd that it always effects
> Windows update all the time, but who knows.

It would be great to have more details about this default tunnel setup.
Can't you sniff the traffic?

Anyway:  Thanks for yet another argument for native dual-stack.
Avoiding such unwanted tunnels is really simple:

If you're an ISP:
  Offer native dual-stack to your Internet access customers.

If you're an Internet access customer:
  Request native dual-stack from your ISP

Problem solved.


Bjørn

Re: bloomberg on supermicro: sky is falling

[Bjørn Mork]

"Naslund, Steve"  writes:

> It only proves that you have seen the card at some point.  Useless.

It doesn't even prove that much.  There is nothing preventing a rogue
online shop from storing and reusing the CVV you give them.  Or selling
your complete card details including zip code, CVV and whatever.

In practice, the CVV is just 3 more digits in the card number. No
security whatsoever in that.


Bjørn