Re: DoD IP Space

[Mel Beckman]

I remember. And I have the HE.net Guru Badge to prove it :)

And don’t forget the World IPv6 Launch in 2012. 

IPv6. The protocol of the future, and always will be :)


-mel via cell

> On Feb 26, 2021, at 3:49 PM, Jay Hennigan  wrote:
> 
> On 2/13/21 18:24, Mark Foster wrote:
> 
>> So the business case will be the 'killer app' or perhaps 'killer service' 
>> that's IPv6-only and that'll provide a business reason.
>> But chicken and egg.. who wants to run a service that's IPv6-only and miss 
>> out on such a big userbase?
> 
> Am I the only one who remembers "The Great IPv6 Experiment" from way back in 
> 2007?
> 
> -- 
> Jay Hennigan - j...@west.net
> Network Engineering - CCIE #7880
> 503 897-8550 - WB6RDV

Re: DoD IP Space

[Jay Hennigan]

On 2/13/21 18:24, Mark Foster wrote:


So the business case will be the 'killer app' or perhaps 'killer service' 
that's IPv6-only and that'll provide a business reason.

But chicken and egg.. who wants to run a service that's IPv6-only and miss out 
on such a big userbase?


Am I the only one who remembers "The Great IPv6 Experiment" from way 
back in 2007?


--
Jay Hennigan - j...@west.net
Network Engineering - CCIE #7880
503 897-8550 - WB6RDV

Re: Newbie Question: Is anyone actually using the Null MX (RFC 7505)?

[Grant Taylor via NANOG]

On 2/26/21 12:10 PM, b...@uu3.net wrote:
Hmm right... Somehow I tought that having that special Null MX will 
silently discard message... I dont know why...


It's Friday.  I'm presuming that many of us have had a long week and are 
ready for the weekend.  ;-)



So, RFC 7505 is pretty much even pointless in my opinion.


No, it's not pointless.  See Alan's reply to my previous message for why 
a Null MX helps as a sender / MSA operator.


See point #2 in my previous message for why you care about Null MX as a 
receiver.



You have to do more.. to pretty much achieve the same.


But it's not the same.

You cause hard failures fast.  It means that sending servers should 
never contact the A /  addresses, much less every time the sending 
system retries to send.  So you do save yourself some CPU cycles as a 
recipient.


Its just easier to not having MX on subdomains that does not serve 
as email destinations.. Less records in DNS.


Easier has seldom been better.

If you publish a Null MX for said subdomain(s), my server will give up 
immediately.  If you don't publish a Null MX, my server will pester your 
A /  IPs every four hours for days at a time.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Newbie Question: Is anyone actually using the Null MX (RFC 7505)?

[John Levine]

In article  you write:
>Hmm right... Somehow I tought that having that special Null MX
>will silently discard message... I dont know why...
>
>So, RFC 7505 is pretty much even pointless in my opinion.
>You have to do more.. to pretty much achieve the same..
>Its just easier to not having MX on subdomains that does not serve
>as email destinations.. Less records in DNS..

Please reread RFC 7505 section 4.

I presume you are aware that SMTP falls back to A records only if there
is no MX record.  If there is any MX record, null or otherwise, mail
clients don't look for an A or .

R's,
John

Re: Newbie Question: Is anyone actually using the Null MX (RFC 7505)?

[John Levine]

In article  
you write:
>1. Is there anyone actively using this Null MX? If so, may I please see
>that actual record line (in BIND zone file format) just to satisfy myself
>that I wrote mine correctly?

Yes.

services.net.   3600IN  MX  0 .


>2. Which one makes more sense from the practical point-of-view: having a
>Null MX Record for the no-mail domain, or having no MX record at all?

Null MX of course.  See section 4 of RFC 7505.

Large mail systems like gmail and recent versions of mail servers like Postfix
all recognize a null MX.  I suppose there are some dusty old mail systems
that do something odd with it and throw an error message but so what?  You
don't want them to send you mail in the first place.

R's,
John

Re: Newbie Question: Is anyone actually using the Null MX (RFC 7505)?

[Mark Andrews]

I think just about everything has been said beyond contacting the operators of 
the
online testing tools and requesting that they update their tool or to take it 
down.
A broken tool is worse that no tool.  The is too much out-of-date stuff on the
Internet.  We should all be doing our little bits to correct it or remove it.

Mark

> On 26 Feb 2021, at 21:19, Pirawat WATANAPONGSE via NANOG  
> wrote:
> 
> Dear all,
> 
> 
> I put the “Null MX” Record (RFC 7505) into one of my domains yesterday, then 
> those online mail diagnostic tools out there start getting me worried:
> 
> It looks like most of those tools do not recognize the Null MX as a special 
> case; they just complain that they cannot find the mail server at “.”
> [Sarcasm: as if the root servers are going to provide mail service to a mere 
> mortal like me!]
> 
> Among a few shining exceptions (in a good way) is the good ol’ 
> https://bgp.he.net/ which does not show that domain as having any MX record.
> [maybe it is also wrong, in the other direction?]
> 
> I fear that the MTAs are going to behave that same way, treating my Null MX 
> as a “misconfigured mail server name” and that my record will mean 
> unnecessary extra queries to the root servers. [well, minus cache hit]
> 
> So, here comes the questions:
> 1. Is there anyone actively using this Null MX? If so, may I please see that 
> actual record line (in BIND zone file format) just to satisfy myself that I 
> wrote mine correctly?
> 2. Which one makes more sense from the practical point-of-view: having a Null 
> MX Record for the no-mail domain, or having no MX record at all?
> 
> 
> Thanks in advance for all advices,
> 
> --
> 
> Pirawat.
> 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

Re: Newbie Question: Is anyone actually using the Null MX (RFC 7505)?

[John Peach]

On 2/26/21 2:10 PM, b...@uu3.net wrote:
> Hmm right... Somehow I tought that having that special Null MX
> will silently discard message... I dont know why...
>
> So, RFC 7505 is pretty much even pointless in my opinion.
> You have to do more.. to pretty much achieve the same..
> Its just easier to not having MX on subdomains that does not serve
> as email destinations.. Less records in DNS..

It should mean that there is no attempt to deliver email, even if the
domain has an A or  record.

>
>
> -- Original message --
>
> From: Grant Taylor via NANOG 
> To: nanog@nanog.org
> Subject: Re: Newbie Question: Is anyone actually using the Null MX (RFC 7505)?
> Date: Fri, 26 Feb 2021 12:03:37 -0700
>
> On 2/26/21 11:46 AM, b...@uu3.net wrote:
>> Well, I bet my legacy system will bounce it for example...
> What specifically is the bounce?
>
> I thought the purpose of the Null MX was to do two things:
>
> 1)  Provide as an MX that can't be connected to.
> 2)  Serve as a signal to things that know how to interpret it that no mail is 
> to
> be expected.
>
> I would expect that some server, if not the MSA, /would/ generate a bounce
> /because/ the email to the domain is undeliverables.
>
>> I cant speak about Sendmail, qmail, Exim.. when they started supporting it.
> My Sendmail boxes have been dealing with the Null MX just fine.  The
> aforementioned bounce is /expected/ to tell the sender that the destination
> address is bad.
>
>> So, In my opinion changing already working standards in a way
>> that they arent full compat with old systems is imo bad aproach.
> IMHO there is little, if any, effective difference between the Null MX and an 
> MX
> pointing to an unresolvable name or an non-routed IP.  They cause a hard / 
> fast
> failure in an early upstream MTA thus induce a bounce.
>
> Depending on the MSA, the delivery problem may even be presented to the user 
> as
> they are submitting the message to the MSA.
>
>
>
> --
> Grant. . . .
> unix || die
>

Re: London Interxion Data Centers

[Töma Gavrichenkov]

Peace,

On Fri, Feb 26, 2021, 10:05 PM Matthew Petach  wrote:

> Aren't they (LME) in Savvis, though?
>>
> That was certainly true in 2003, at least
>

Maybe it's still true today.

tax.select.prd.lmexgw.com.
*A*213.86.73.66
inetnum: 213.86.73.0 - 213.86.73.255
netname: NET-GB-LME
descr: LME Savvis DC
country: GB
admin-c: KM8442-RIPE
tech-c: KM8442-RIPE
status: ASSIGNED PA
mnt-by: COLT-UK

--
Töma

>

Re: Newbie Question: Is anyone actually using the Null MX (RFC 7505)?

[Alan Hodgson]

On Fri, 2021-02-26 at 12:03 -0700, Grant Taylor via NANOG wrote:
> On 2/26/21 11:46 AM, b...@uu3.net wrote:
> > Well, I bet my legacy system will bounce it for example...
> 
> What specifically is the bounce?
> I thought the purpose of the Null MX was to do two things:
> 1)  Provide as an MX that can't be connected to.2)  Serve as a signal to
> things that know how to interpret it that no mail is to be expected.
> I would expect that some server, if not the MSA, /would/ generate a bounce
> /because/ the email to the domain is undeliverables.

Exactly. Postfix bounces it immediately with an accurate message:

Domain ???.com does not accept mail (nullMX)

This seems preferable to waiting hours or days for a bounce due to not being
able to connect to the A record on port 25 or w/e.

Re: Newbie Question: Is anyone actually using the Null MX (RFC 7505)?

[borg]

Hmm right... Somehow I tought that having that special Null MX
will silently discard message... I dont know why...

So, RFC 7505 is pretty much even pointless in my opinion.
You have to do more.. to pretty much achieve the same..
Its just easier to not having MX on subdomains that does not serve
as email destinations.. Less records in DNS..


-- Original message --

From: Grant Taylor via NANOG 
To: nanog@nanog.org
Subject: Re: Newbie Question: Is anyone actually using the Null MX (RFC 7505)?
Date: Fri, 26 Feb 2021 12:03:37 -0700

On 2/26/21 11:46 AM, b...@uu3.net wrote:
> Well, I bet my legacy system will bounce it for example...

What specifically is the bounce?

I thought the purpose of the Null MX was to do two things:

1)  Provide as an MX that can't be connected to.
2)  Serve as a signal to things that know how to interpret it that no mail is to
be expected.

I would expect that some server, if not the MSA, /would/ generate a bounce
/because/ the email to the domain is undeliverables.

> I cant speak about Sendmail, qmail, Exim.. when they started supporting it.

My Sendmail boxes have been dealing with the Null MX just fine.  The
aforementioned bounce is /expected/ to tell the sender that the destination
address is bad.

> So, In my opinion changing already working standards in a way
> that they arent full compat with old systems is imo bad aproach.

IMHO there is little, if any, effective difference between the Null MX and an MX
pointing to an unresolvable name or an non-routed IP.  They cause a hard / fast
failure in an early upstream MTA thus induce a bounce.

Depending on the MSA, the delivery problem may even be presented to the user as
they are submitting the message to the MSA.



-- 
Grant. . . .
unix || die

Re: London Interxion Data Centers

[Matthew Petach]

On Fri, Feb 26, 2021 at 4:56 AM Töma Gavrichenkov  wrote:

> Peace
>
> On Fri, Feb 26, 2021, 3:06 PM Rod Beck 
> wrote:
>
>> My understanding is that there are three London Interxion data centers (I
>> thought Equinix was the Borg and had assimilated pretty everything at this
>> point).
>>
>> Trying to get the address where the facility where the London Metal
>> Exchange houses its trading engine.
>>
>
> Aren't they (LME) in Savvis, though?
>
> --
> Töma
>

That was certainly true in 2003, at least:

https://zynap.com/savvis-gains-ground-in-u-k-managed-hosting-services-market-with-six-new-customer-wins/

and this list seems to corroborate that:

https://trends.builtwith.com/websitelist/Savvis/United-Kingdom/London

Though, it looks like LME has strict limits on which networks they will
allow to connect into it:

https://www.lme.com/Trading/Access-the-market/ISVs-and-connectivity-providers

and it looks like at the moment, Colt is the favoured provider for LMEnet:

https://www.lme.com/Trading/Systems/LMEnet#tabIndex=0

Best of luck getting a toe in the door!^_^;;

Matt

Re: Newbie Question: Is anyone actually using the Null MX (RFC 7505)?

[Grant Taylor via NANOG]

On 2/26/21 11:46 AM, b...@uu3.net wrote:

Well, I bet my legacy system will bounce it for example...


What specifically is the bounce?

I thought the purpose of the Null MX was to do two things:

1)  Provide as an MX that can't be connected to.
2)  Serve as a signal to things that know how to interpret it that no 
mail is to be expected.


I would expect that some server, if not the MSA, /would/ generate a 
bounce /because/ the email to the domain is undeliverables.



I cant speak about Sendmail, qmail, Exim.. when they started supporting it.


My Sendmail boxes have been dealing with the Null MX just fine.  The 
aforementioned bounce is /expected/ to tell the sender that the 
destination address is bad.



So, In my opinion changing already working standards in a way
that they arent full compat with old systems is imo bad aproach.


IMHO there is little, if any, effective difference between the Null MX 
and an MX pointing to an unresolvable name or an non-routed IP.  They 
cause a hard / fast failure in an early upstream MTA thus induce a bounce.


Depending on the MSA, the delivery problem may even be presented to the 
user as they are submitting the message to the MSA.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Newbie Question: Is anyone actually using the Null MX (RFC 7505)?

[borg]

Well, I bet my legacy system will bounce it for example...

Postfix 3.0: RFC 7505 ("Null MX" No Service Resource Record), Earlier 
Postfix versions will bounce mail because of a "Malformed DNS server reply". 

I cant speak about Sendmail, qmail, Exim.. when they started supporting it.

So, In my opinion changing already working standards in a way
that they arent full compat with old systems is imo bad aproach.

-- Original message --

From: Suresh Ramasubramanian 
To: "b...@uu3.net" , "nanog@nanog.org" 
Subject: Re: Newbie Question: Is anyone actually using the Null MX (RFC 7505)?
Date: Fri, 26 Feb 2021 17:43:17 +

OK. In your experience, which legacy system is going to misinterpret this 
record?

The current RFC is from 2014-15 but the original idea from Mark Delany (then at 
Yahoo now at Apple) has been kicking around from 2006 or so. I remember 
contributing some text to the original draft RFC but can?t find any trace of it 
online right now.

It worked just fine even back then, I assure you. So if there is any legacy MTA 
that still doesn?t accept it, it probably relies on UUCP domain maps or similar.

--srs

From: NANOG  on behalf of 
b...@uu3.net 
Date: Friday, 26 February 2021 at 10:51 PM
To: nanog@nanog.org 
Subject: Re: Newbie Question: Is anyone actually using the Null MX (RFC 7505)?
Thats cute, but remember that there are gazylion of legacy systems
on Internet as well. They might have no clue what do do with it..
Also remember that MTA is supposed to accept email to [ip] too.

On my opinion, its best to just have no MX record at all.
While MTA can fallback and try to do delivery by IN A record, I think
its not that big problem. You need to specify for what domains you
accept email anyway. And spammers will not care at all...


-- Original message --

From: Pirawat WATANAPONGSE via NANOG 
To: nanog@nanog.org
Subject: Newbie Question: Is anyone actually using the Null MX (RFC 7505)?
Date: Fri, 26 Feb 2021 17:19:41 +0700

Dear all,


I put the ˙˙Null MX˙˙ Record (RFC 7505) into one of my domains yesterday,
then those online mail diagnostic tools out there start getting me worried:

It looks like most of those tools do not recognize the Null MX as a special
case; they just complain that they cannot find the mail server at ˙˙.˙˙
[Sarcasm: as if the root servers are going to provide mail service to a
mere mortal like me!]

Among a few shining exceptions (in a good way) is the good ol˙˙
https://bgp.he.net/ which does not show that domain as having any MX record.
[maybe it is also wrong, in the other direction?]

I fear that the MTAs are going to behave that same way, treating my Null MX
as a ˙˙misconfigured mail server name˙˙ and that my record will mean
unnecessary extra queries to the root servers. [well, minus cache hit]

So, here comes the questions:
1. Is there anyone actively using this Null MX? If so, may I please see
that actual record line (in BIND zone file format) just to satisfy myself
that I wrote mine correctly?
2. Which one makes more sense from the practical point-of-view: having a
Null MX Record for the no-mail domain, or having no MX record at all?


Thanks in advance for all advices,

--

Pirawat.

Weekly Routing Table Report

[Routing Analysis Role Account]

This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.

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

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

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

If you have any comments please contact Philip Smith .

Routing Table Report   04:00 +10GMT Sat 27 Feb, 2021

Report Website: http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary


BGP routing table entries examined:  847193
Prefixes after maximum aggregation (per Origin AS):  322664
Deaggregation factor:  2.63
Unique aggregates announced (without unneeded subnets):  404082
Total ASes present in the Internet Routing Table: 70649
Prefixes per ASN: 11.99
Origin-only ASes present in the Internet Routing Table:   60774
Origin ASes announcing only one prefix:   25076
Transit ASes present in the Internet Routing Table:9875
Transit-only ASes present in the Internet Routing Table:299
Average AS path length visible in the Internet Routing Table:   4.3
Max AS path length visible:  62
Max AS path prepend of ASN (266299)  59
Prefixes from unregistered ASNs in the Routing Table:   978
Number of instances of unregistered ASNs:   982
Number of 32-bit ASNs allocated by the RIRs:  35208
Number of 32-bit ASNs visible in the Routing Table:   29241
Prefixes from 32-bit ASNs in the Routing Table:  136223
Number of bogon 32-bit ASNs visible in the Routing Table:16
Special use prefixes present in the Routing Table:1
Prefixes being announced from unallocated address space:562
Number of addresses announced to Internet:   2915817600
Equivalent to 173 /8s, 203 /16s and 216 /24s
Percentage of available address space announced:   78.8
Percentage of allocated address space announced:   78.8
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   99.5
Total number of prefixes smaller than registry allocations:  289157

APNIC Region Analysis Summary
-

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

ARIN Region Analysis Summary


Prefixes being announced by ARIN Region ASes:244189
Total ARIN prefixes after maximum aggregation:   112229
ARIN Deaggregation factor: 2.18
Prefixes being announced from the ARIN address blocks:   244750
Unique aggregates announced from the ARIN address blocks:116755
ARIN Region origin ASes present in the Internet Routing Table:18747
ARIN Prefixes per ASN:13.06
ARIN Regi

Re: Newbie Question: Is anyone actually using the Null MX (RFC 7505)?

[Suresh Ramasubramanian]

OK. In your experience, which legacy system is going to misinterpret this 
record?

The current RFC is from 2014-15 but the original idea from Mark Delany (then at 
Yahoo now at Apple) has been kicking around from 2006 or so. I remember 
contributing some text to the original draft RFC but can’t find any trace of it 
online right now.

It worked just fine even back then, I assure you. So if there is any legacy MTA 
that still doesn’t accept it, it probably relies on UUCP domain maps or similar.

--srs

From: NANOG  on behalf of 
b...@uu3.net 
Date: Friday, 26 February 2021 at 10:51 PM
To: nanog@nanog.org 
Subject: Re: Newbie Question: Is anyone actually using the Null MX (RFC 7505)?
Thats cute, but remember that there are gazylion of legacy systems
on Internet as well. They might have no clue what do do with it..
Also remember that MTA is supposed to accept email to [ip] too.

On my opinion, its best to just have no MX record at all.
While MTA can fallback and try to do delivery by IN A record, I think
its not that big problem. You need to specify for what domains you
accept email anyway. And spammers will not care at all...


-- Original message --

From: Pirawat WATANAPONGSE via NANOG 
To: nanog@nanog.org
Subject: Newbie Question: Is anyone actually using the Null MX (RFC 7505)?
Date: Fri, 26 Feb 2021 17:19:41 +0700

Dear all,


I put the ˙˙Null MX˙˙ Record (RFC 7505) into one of my domains yesterday,
then those online mail diagnostic tools out there start getting me worried:

It looks like most of those tools do not recognize the Null MX as a special
case; they just complain that they cannot find the mail server at ˙˙.˙˙
[Sarcasm: as if the root servers are going to provide mail service to a
mere mortal like me!]

Among a few shining exceptions (in a good way) is the good ol˙˙
https://bgp.he.net/ which does not show that domain as having any MX record.
[maybe it is also wrong, in the other direction?]

I fear that the MTAs are going to behave that same way, treating my Null MX
as a ˙˙misconfigured mail server name˙˙ and that my record will mean
unnecessary extra queries to the root servers. [well, minus cache hit]

So, here comes the questions:
1. Is there anyone actively using this Null MX? If so, may I please see
that actual record line (in BIND zone file format) just to satisfy myself
that I wrote mine correctly?
2. Which one makes more sense from the practical point-of-view: having a
Null MX Record for the no-mail domain, or having no MX record at all?


Thanks in advance for all advices,

--

Pirawat.

Re: Newbie Question: Is anyone actually using the Null MX (RFC 7505)?

[borg]

Thats cute, but remember that there are gazylion of legacy systems
on Internet as well. They might have no clue what do do with it..
Also remember that MTA is supposed to accept email to [ip] too.

On my opinion, its best to just have no MX record at all.
While MTA can fallback and try to do delivery by IN A record, I think
its not that big problem. You need to specify for what domains you
accept email anyway. And spammers will not care at all...


-- Original message --

From: Pirawat WATANAPONGSE via NANOG 
To: nanog@nanog.org
Subject: Newbie Question: Is anyone actually using the Null MX (RFC 7505)?
Date: Fri, 26 Feb 2021 17:19:41 +0700

Dear all,


I put the ˙˙Null MX˙˙ Record (RFC 7505) into one of my domains yesterday,
then those online mail diagnostic tools out there start getting me worried:

It looks like most of those tools do not recognize the Null MX as a special
case; they just complain that they cannot find the mail server at ˙˙.˙˙
[Sarcasm: as if the root servers are going to provide mail service to a
mere mortal like me!]

Among a few shining exceptions (in a good way) is the good ol˙˙
https://bgp.he.net/ which does not show that domain as having any MX record.
[maybe it is also wrong, in the other direction?]

I fear that the MTAs are going to behave that same way, treating my Null MX
as a ˙˙misconfigured mail server name˙˙ and that my record will mean
unnecessary extra queries to the root servers. [well, minus cache hit]

So, here comes the questions:
1. Is there anyone actively using this Null MX? If so, may I please see
that actual record line (in BIND zone file format) just to satisfy myself
that I wrote mine correctly?
2. Which one makes more sense from the practical point-of-view: having a
Null MX Record for the no-mail domain, or having no MX record at all?


Thanks in advance for all advices,

--

Pirawat.

OARC 35 Workshop, May 6th & 7th, Registration and Call for Contributions now open

[Jake Zack]

OARC 35 will be an online meeting on May 6th & 7th starting at 01:00 UTC. The 
Programme Committee is seeking contributions from the community.

All DNS-related subjects and suggestions for discussion topics are welcome. For 
inspiration, we provide a non-exhaustive list of ideas:

- Stories of DNS Migrations: Reasoning for DNS software migration. Tooling used 
to ensure a smooth and correct process.
- DNS Intricacies: Chasing down problems and surprising behavior.
- Garbage Traffic: Analysis on unexpected traffic seen by authoritative and 
recursive servers.
- DITL: Day In The Life of various roles and teams in DNS.

As it is an online workshop, we'd like to encourage brevity; presentations 
should not be longer than 20 minutes (with additional time for questions).

**Workshop Milestones:**

* 04 Feb 2021 - Submissions open via Indico
* 18 Mar 2021 - Deadline for submission (23:59 UTC)
* 25 Mar 2021 - Initial Contribution list published
* 08 Apr 2021 - Full agenda published
* 22 Apr 2021 - Deadline for slideset submission and Rehearsal
* 06 May 2021 - OARC 35 Workshop

The Registration page and details for presentation submission are published at:



DNS-OARC provides registration fee waivers for the workshop to support those 
who are part of under-represented groups at DNS-OARC. See the registration page 
for details.

To allow the Programme Committee to make objective assessments of submissions, 
so as to ensure the quality of the workshop, submissions SHOULD include slides. 
Draft slides are acceptable on submission.

Additional information for speakers of OARC 35:

  * your talk will be broadcast live and recorded for future reference
  * your presentation slides will be available for delegates and others to 
download and refer to, before, during and after the meeting
  * you will be expected to attend a rehearsal on April 22nd. It would be very 
useful to have your slides (even if draft) ready for this.

If you have questions or concerns you can contact the Programme Committee:

https://www.dns-oarc.net/oarc/programme

via 

Jacob Zack for the DNS-OARC Programme Committee

OARC depends on sponsorship to fund its workshops and associated social events. 
 Please contact  if your organization is interested in 
becoming a sponsor.

(Please note that OARC is run on a non-profit basis, and is not in a position 
to reimburse expenses or time for speakers at its meetings.)


--

Jacob Zack
DNS Architect – CIRA (.CA TLD)

Re: London Interxion Data Centers

[Töma Gavrichenkov]

Peace

On Fri, Feb 26, 2021, 3:06 PM Rod Beck 
wrote:

> My understanding is that there are three London Interxion data centers (I
> thought Equinix was the Borg and had assimilated pretty everything at this
> point).
>
> Trying to get the address where the facility where the London Metal
> Exchange houses its trading engine.
>

Aren't they (LME) in Savvis, though?

--
Töma

>

Re: London Interxion Data Centers

[Brandon Butterworth]

On Fri Feb 26, 2021 at 12:05:14PM +, Rod Beck wrote:
> My understanding is that there are three London Interxion data centers (I 
> thought Equinix was the Borg and had assimilated pretty everything at this 
> point).

The competition authoritites stopped them, part of the Telecity
set of DCs was sold to Digital Realty which joined with Interxion

> Trying to get the address where the facility where the London
> Metal Exchange houses its trading engine

I doubt they will tell you but the IXN facilites are right by
the City so a candidate. You can see where on their web site

https://www.interxion.com

brandon

London Interxion Data Centers

[Rod Beck]

Hi Folks,

My understanding is that there are three London Interxion data centers (I 
thought Equinix was the Borg and had assimilated pretty everything at this 
point).

Trying to get the address where the facility where the London Metal Exchange 
houses its trading engine. No, financial institutions don't like to give this 
info to transport providers. The trading engine is the heart of electronic 
trading - it matches buy and sell offers.

Regards,

Roderick.


Roderick Beck

Global Network Capacity Procurement

United Cable Company

www.unitedcablecompany.com
https://unitedcablecompany.com/video/
New York City & Budapest

rod.b...@unitedcablecompany.com

Budapest: 36-70-605-5144

NJ: 908-452-8183



[1467221477350_image005.png]

Re: Newbie Question: Is anyone actually using the Null MX (RFC 7505)?

[Suresh Ramasubramanian]

MTAs don’t care what online analysis tools tell you and setting a null MX for a 
domain that you don’t receive mail for will work just fine, for the reasons 
explained in the rfc

Having no MX means the smtp connection will fall back to the A record for your 
domain if one exists


--srs

From: NANOG  on behalf of Pirawat 
WATANAPONGSE via NANOG 
Sent: Friday, February 26, 2021 3:49:41 PM
To: nanog@nanog.org 
Subject: Newbie Question: Is anyone actually using the Null MX (RFC 7505)?

Dear all,


I put the “Null MX” Record (RFC 7505) into one of my domains yesterday, then 
those online mail diagnostic tools out there start getting me worried:

It looks like most of those tools do not recognize the Null MX as a special 
case; they just complain that they cannot find the mail server at “.”
[Sarcasm: as if the root servers are going to provide mail service to a mere 
mortal like me!]

Among a few shining exceptions (in a good way) is the good ol’ 
https://bgp.he.net/ which does not show that domain as having any MX record.
[maybe it is also wrong, in the other direction?]

I fear that the MTAs are going to behave that same way, treating my Null MX as 
a “misconfigured mail server name” and that my record will mean unnecessary 
extra queries to the root servers. [well, minus cache hit]

So, here comes the questions:
1. Is there anyone actively using this Null MX? If so, may I please see that 
actual record line (in BIND zone file format) just to satisfy myself that I 
wrote mine correctly?
2. Which one makes more sense from the practical point-of-view: having a Null 
MX Record for the no-mail domain, or having no MX record at all?


Thanks in advance for all advices,

--

Pirawat.

Newbie Question: Is anyone actually using the Null MX (RFC 7505)?

[Pirawat WATANAPONGSE via NANOG]

Dear all,


I put the “Null MX” Record (RFC 7505) into one of my domains yesterday,
then those online mail diagnostic tools out there start getting me worried:

It looks like most of those tools do not recognize the Null MX as a special
case; they just complain that they cannot find the mail server at “.”
[Sarcasm: as if the root servers are going to provide mail service to a
mere mortal like me!]

Among a few shining exceptions (in a good way) is the good ol’
https://bgp.he.net/ which does not show that domain as having any MX record.
[maybe it is also wrong, in the other direction?]

I fear that the MTAs are going to behave that same way, treating my Null MX
as a “misconfigured mail server name” and that my record will mean
unnecessary extra queries to the root servers. [well, minus cache hit]

So, here comes the questions:
1. Is there anyone actively using this Null MX? If so, may I please see
that actual record line (in BIND zone file format) just to satisfy myself
that I wrote mine correctly?
2. Which one makes more sense from the practical point-of-view: having a
Null MX Record for the no-mail domain, or having no MX record at all?


Thanks in advance for all advices,

--

Pirawat.