Re: [PLUG] DNS, fsearch, systemd

[David Collins via plug <plug@lists.phillylinux.org>]

That's not actually a misconfiguration. It's a common practice among ISPs. The initial lookup domain of 156.255.213.162.in-addr.arpa. is prescribed by DNS convention for reverse lookups. However, the owner of the address can make that DNS record a CNAME to whatever domain name they want. It doesn't actually have to be a PTR. And the target of the CNAME can follow whatever format they want. As long as at the end of the CNAME redirection it ends up at a PTR record it will work correctly.

Now, why would they want to do it this way? It's because of the way DNS delegation works. DNS delegation by default does not work well if you subnet an IP space in certain ways. We'll use your same IP address examples.

1Looking at just 162.213.255.0/24 in this instance, it is being subnetted into 162.213.255.0/25 and 162.213.255.128/25. As an example, let's say those two /25 IP blocks are delegated to different customers. If I'm one of those customers, I want to be able to control the in-addr.arpa entries for my IP range. If I'm an ISP, I want to be able to assign the in-addr.arpa domains for those IP ranges to those customers.

Here's where the problem comes in. DNS delegations occur at subdomain boundaries. There is no way to delegate half of the 255.213.162.in-addr.arpa domain space to a single customer. The ISP can only create an entry that delegates all of 255.213.162.in-addra.arpa to a single customer (using a DNS NS record). So the ISP can't delegate half of the namespace to one customer and half of the namespace to another customer.

UNLESS they create an NS record for each individual IP address entry. They would need to make an NS for each subdomain from 1.255.213.162.in-addr.arpa to 255.255.213.162.in-addr.arpa. That's a valid solution to the problem.

HOWEVER, what happens when that ISP customers change and the ISP now has to delegate that namespace to a new customer? They have to go back and change all of those NS records. That's probably not difficult to do with a script. But there's a more efficient way.

That brings us to what they did. The ISP can insert another level of subdomain and create CNAME records to that. So In this case, they created 128-25.255.213.162.in-addr.arpa They can delegate the NS records for 128-25.255.213.162.in-addr.arpa to another organization. The ISP then creates CNAME records for all of the IP address reverse lookup domains to their equivalent number inside of 128-25.255.213.162.in-addr.arpa For example, 156.255.213.162.in-addr.arpa is a CNAME to 156.128-25.255.213.162.in-addr.arpa. Now, if the customer changes, the ISP only needs to update the single delegation NS record for 128-25.255.213.162.in-addr.arpa. All of their other CNAME records are still valid. This works because any subdomain can be delegated using an NS record. And any valid name inside of DNS can be a valid subdomain.

The customer controls 128-25.255.213.162.in-addr.arpa and can set the proper IP entries within it to what they want. This is based on what I have seen other ISPs do. It seems like the particular story here is more involved. I did a few lookups and not all of the IP addresses that would be in 162.213.255.128/25 have their reverse lookups set to CNAME records. So probably only some of the reverse lookups for that IP range have this CNAME scheme in place. That may be because the IP space is further subnetted by customer but the DNS reverse lookups were organized differently for some reason.

---
David Collins
dave@cyberpunkjedi.com

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

On Thursday, November 25th, 2021 at 10:28 AM, George Langford via plug <plug@lists.phillylinux.org> wrote:

> The late Dan Kominsky first brought up dns cache poisoning in 2008,
>
> which I was able
>
> to retrieve from my PLUG archive; Dan Goodin has carried the analysis
>
> further as
>
> jeffv has brought up recently.
>
> I've just found a class of mis-configured in-addr.arpa entries that
>
> ought to disrupt
>
> DNS lookups. Here's a ferinstance: 162.213.255.128/25.
>
> There's a misconfiguration in the in-addr.arpa index address for more
>
> than fifty of these
>
> IPv4 addresses:
>
> dig -x 162.213.255.156 ==> ;; ANSWER SECTION:
>
> 156.255.213.162.in-addr.arpa. 1200 IN CNAME
>
> 156.128-25.255.213.162.in-addr.arpa.
>
> 156.128-25.255.213.162.in-addr.arpa. 7199 IN PTR
>
> server1.jobinterview.biz.
>
> That misconfiguration ought to interfere with the resolution of
>
> server1.jobinterview.biz, but it doesn't.
>
> Is that because I've looked up those addresses too many times ?
>
> The miscofiguration appears to stem from the original setup/registration
>
> of the server,
>
> as 128/25 is the correct CIDR block of the affected addresses. However,
>
> the injected
>
> 128-25 in 156.128-25.255.213.162.in-addr.arpa is in the wrong position
>
> of the reversed
>
> order of IPv4 octets, as though the misconfiguration is deliberate.
>
> Philadelphia Linux Users Group -- http://www.phillylinux.org
>
> Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
>
> General Discussion -- http://lists.phillylinux.org/mailman/listinfo/plug
___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug