Re: [EXTERNAL] Re: A crazy idea

[Feldman, Mark via NANOG]

On 7/19/21, 9:04 AM, "Stephen Satchell"  wrote:

On 7/19/21 5:41 AM, Feldman, Mark wrote:
> What you propose is not outlandish; some ISPs have been dual stack
> and providing some combination of these services for years.  They
> already provide IPv6 ip6.arpa delegations should their business
> customers want them.  Some even provide at least a /56 so customers
> can have multiple /64 subnets.  And we, I mean they, can also provide
> RFC2317 in-addr.arpa delegations for those smaller IPv4 blocks.

The part that is missing isn't the "some ISPs", it's "all ISPs".

It's true that not all ISPs do IPv6.  There are those that do support it and 
those that will.  At some point the pain associated with the lack of IPv4 
address space will outweigh the pain of IPv6 deployment.   Those that do IPv6 
should support all of the service that I described.

Also,
I don't know of any DNS service provider that offers a product to handle
delegations from the IN-ADDR.ARPA and IP6.ARPA trees.

Any DNS service provider should be able to host an in-addr.arpa or ip6.arpa 
zone.  If they don't do "reverse/PTR" zones, they're really not a full service 
provider.  Zones are zones.

I'm focusing on the SOHO customer market with my proposal.

My standard residential service has my router getting a /64 that allows my 
hosts to self-generate public, routable /128 IPv6 addresses using EUI64 and 
other mechanisms when I don't bother setting the RHS of the address.   I also 
get a single IPv4 address which gets NAT'd.   There's no reason for a SOHO 
customer to have less than that and there are reasons to have more.

Every modern device in my house preferes IPv6 when the service to which it is 
connecting is dual stack.  It all just works as-is.  When things break, it's 
usually an antiquated piece of equipment  that doesn't grok IPv6 itself or 
there's one in the way.

Most of our residential customers don't pay attention the underlying protocols. 
 They just plug things in and use them.  Well over half of the DNS queries 
coming from our customers come in over IPv6.

The allocation of IPv6 space with prefixes shorter than /64 is indeed a
consideration for bigger administrative domains like country
governments, but on the other end, SOHO customers would be happy with
/96, /104 or even /112 allocations if they could get them.  (Just how
many light bulbs, fridges, toasters, doorbells, phones,  does SOHOs
have?)  I would *not* like to see "us" make the same mistake with IPv6
that was made with IPv4, handing out large blocks of space like so many
pieces of M or Skittles candy.

The standard for an IPv6 subnet is a /64.  It's what makes EUI64  and other 
useful addressing techniques possible.  You can't think of IPv6 with an IPv4 
scarcity mindset -- that will cause you to cripple IPv6.  And, no, even with 
/64 subnets, you won't run out of IPv6 addresses -- there are still billions of 
times more subnets available with IPv6  than there are host addresses in IPv4.

Making the standard subnet a /64 and having IPv6 delegations fall on nibble 
boundaries means a clean mapping to DNS without RFC2317 games.

We used to have someone with the title, IPv6 Evangelist.  He got us far.  Now 
it's everyone's job.

  Mark

Re: A crazy idea

[Feldman, Mark via NANOG]

What you propose is not outlandish; some ISPs have been dual stack and 
providing some combination of these services for years.  They already provide 
IPv6 ip6.arpa delegations should their business customers want them.  Some even 
provide at least a /56 so customers can have multiple /64 subnets.  And we, I 
mean they, can also provide RFC2317 in-addr.arpa delegations for those smaller 
IPv4 blocks.

  Mark


On 7/19/21, 8:13 AM, "NANOG on behalf of Stephen Satchell" 
 wrote:

First, I know this isn't the right place to propose this; need a pointer
to where to propose an outlandish idea.

PROBLEM:  IPv6 support is still in its birthing pangs.  I see a problem
that limits deployment of IPv6 fully:  reverse PTR records in the
".in6.arpa." zones.

(Now that I think about it, this may very well be a network operator
issue.  Who maintains the ".in.arpa." zones delegated by IANA now?)

I've been going 'round and 'round with AT about "static" IPv6
addresses.  In particular, I can't get a PTR record in the ip6.arpa.
zone to save my life.  Now, the problem is not really ripe yet, because
the big reason for PTR records is for mail servers -- best practice
calls for /PTR agreement, just like for IPv4 the best practice is
for A/PTR agreement.

The existing DNS providers can support delegation domains, so that I
don't have to have DNS servers of my own if I don't want to.  It could
be that one would need to "buy" the delegation domain, but that's a
front-office consideration.  Personally, I use register.com for my
domain DNS zones.  I believe strongly that other registrars that offer
customer zone editing, plus DNS service providers, can support reverse
delegation zones with a minimum of hassle, and without charging an arm
and a leg for the service.

 From the customers' viewpoint, a GUI would make the maintenance
relatively painless.

(Keying the information below took a long time.  Any rational DNS admin
and DNS service provider would have automation in place to take out the
painful work.)

What would the domain names look like?  Let's take my current IP/IPv6
assignments from AT:

   2600:1700:79b0:ddc0::/64
   99.65.194.96/29

The IPv6 delegation would be easy:

> 0.c.d.d.0.b.9.7.0.0.7.1.0.0.6.2.ip6.arpa. NS my-DNS-server-1.
> 0.c.d.d.0.b.9.7.0.0.7.1.0.0.6.2.ip6.arpa. NS my-DNS-server-2.

because the delegation would always be on a /64 boundary. The customer
assignments would be straightforward.  In my BIND9 zone file, it would
look something like this:

> $ORIGIN 0.c.d.d.0.b.9.7.0.0.7.1.0.0.6.2.ip6.arpa.
> @ IN SOA ...
> @ NS my-DNS-server-1.
> @ NS my-DNS-server-2.
> 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR server1.example.com.
> 2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR server2.example.com.

Delegations for the IP range, not being on an octet boundary, would be a
little more problematic:

 > 96-103.194.65.99.in-addr.arpa. NS my-DNS-server-1
 > 96-103.194.65.99.in-addr.arpa. NS my-DNS-server-2> $GENERATE 96-102 $
IN CNAME $.96-103.194.65.99.in-addr.arpa.

In my BIND9 zone file, it would look something like this:

> $ORIGIN 96-103.194.65.99.in-addr.arpa.
> @ SOA ...
> @ NS my-dns-server-1.
> @ NS my-dns-server-2.
> 96 IN PTR server1.example.com.
> 97 IN PTR server2.example.com.

The advantage to this system to the number providers is they would have
one administrative record per customer, instead of having to deal with
each PTR record individually.  The advantage to customers is they don't
have to beg and snivel to get PTR records, just beg and snivel once to
get the delegation.  The advantage to DNS server providers is they have
something else to sell.

Want to encourage IPv6 adoption?  This would help.

Re: Yet another Quadruple DNS?

[Feldman, Mark]

Another one for the list...  We're working on fielding our quad-255 
(255.255.255.255) DNS.  It's currently pingable but not yet providing 
resolution.  We're aiming for an April 1st release.  One of the most 
widley-distributed quads out there.  We're thinking about calling it QUAdFF -- 
drink it up.  

  Mark


On 3/30/18, 10:48 AM, "NANOG on behalf of Royce Williams" 
 wrote:

And FWIW, there are currently a few other other same-quad open resolvers:

# IP - desc | CIDR | recursion-yes
1.1.1.1 - APNIC-LABS - Research prefix for APNIC Labs (now Cloudflare
distributed public recursive DNS) | 1/8 | recursion-yes
8.8.8.8 - Google LLC (public recursive DNS) | 8.8.8/24 | recursion-yes
9.9.9.9 - Quad9 (public recursive DNS) | 9.9.9/24 | recursion-yes
77.77.77.77 - Dadeh Gostar Asr Novin P.J.S. Co. (Iran) | 77.77.64/19 |
recursion-yes
80.80.80.80 - Freenom DNS CLoud IP Space | 80.80.80/23  | recursion-yes
114.114.114.114 - NanJing XinFeng Information Technologies, Inc. |
114.114/16 | recursion-yes

Full survey - with owners of the largest bit-boundary-aligned blocks
that contain them - here:

https://gist.github.com/roycewilliams/6cb91ed94b88730321ca3076006229f1

Royce

xtube.com/ultradns/dynect zone issues

[Feldman, Mark]

If folks from xtube.com/ultradns/dynect are on the list, it appears that 
there’s a discrepancy in the xtube.com zone being served by the some auths.  At 
least one of the CNAMEs required for resolution is missing from the zone being 
served by at least some ultra instances.  No idea where the breakdown is, but 
we’ve got customers telling the world  that we’re blocking access to porn.  
I’ll also note that the SOA ttl and ncache are on the large side, so we’re 
caching those NXDOMAINs for quite a while.  Flushing is just playing 
whack-a-mole at the moment.

Also, if folks from any large auths want to provide me with contact info, we’ll 
happily reach out to you privately/directly should something similar occur in 
the future .

  Mark
  Comcast TPX Core Network Services

New Jersey auth servers

[Feldman, Mark]

If someone responsible for or with connections to those running the 
state.nj.us/nj.gov auth name servers would contact me off list, it would be 
appreciated.  We're having some resolution issues that appear to be due to 
DNS/network config at or near those auths.

  Mark
  Comcast T Core Network Servies

1and1 DNS contact

[Feldman, Mark]

If there's anyone from 1and1 (specifically, someone involved with 
apps-1and1.com), please contact me off list.  We're running across a DNS 
resolution issue from some places on our network and would like to discuss.  
Thanks.

  Mark
  Comcast T Core Network Services

Google Fiber contact

[Feldman, Mark]

Can someone from Google Fiber contact me off list?  Thanks.

  Mark
  Comcast T Core Network Services

Go Daddy contact

[Feldman, Mark]

Can someone from Go Daddy contact me off-list about a shared customer issue?

  Mark
  Comcast DNS