Score:0

Server

PTR registers for CNAMEs

Gilberto Martins

10/21/23, 5:58 PM

In my bind9 DNS server, I have my servers described like this:

[...]
prd1frm201      IN      A       172.21.10.2
dns             IN      CNAME   prd1frm201.kprd1.
ntp             IN      CNAME   prd1frm201.kprd1.

prd1frm202      IN      A       172.21.10.3
sentry          IN      CNAME   prd1frm202.kprd1.

[...]

And the reverse is defined like:

[...]
3                       IN PTR  prd1frm202.kprd1.
4                       IN PTR  prd1frm203.kprd1.
[...]

So, when I resolve a host name (either A or CNAME) I get this correct answer:

gmartins@HP-Gilberto:~$ host prd1frm201
prd1frm201.kprd1 has address 172.21.10.2

gmartins@HP-Gilberto:~$ host dns
dns.kprd1 is an alias for prd1frm201.kprd1.
prd1frm201.kprd1 has address 172.21.10.2

gmartins@HP-Gilberto:~$ host ntp
ntp.kprd1 is an alias for prd1frm201.kprd1.
prd1frm201.kprd1 has address 172.21.10.2

What is indeed correct! My question is about reverse resolution:

gmartins@HP-Gilberto:~$ host 172.21.10.2
2.10.21.172.in-addr.arpa domain name pointer prd1frm201.kprd1.

gmartins@HP-Gilberto:~$ host 172.21.10.3
3.10.21.172.in-addr.arpa domain name pointer prd1frm202.kprd1.

Obviously, I'll never get a CNAME as an answer. But if I just change the reverse DNS file like this:

2                       IN PTR  prd1frm201.kprd1.
2                       IN PTR  dns.kprd1.
2                       IN PTR  ntp.kprd1.

Provides this answer:

gmartins@prd1frm201:~$ host 172.21.10.2
2.10.21.172.in-addr.arpa domain name pointer dns.kprd1.
2.10.21.172.in-addr.arpa domain name pointer ntp.kprd1.
2.10.21.172.in-addr.arpa domain name pointer prd1frm201.kprd1.

Although it seems perfectly fine, RFC 1912 states that "Also, PTR records must point back to a valid A record, not an alias defined by a CNAME".

My question is: What is the PROPER way to configure it? should I only assign a PTR to an A register or can I have a PTR assigned either to an A or a CNAME register? Why (not)?

134

1 + 16

bind

cname-record

ptr-record

Nikita Kipriyanov

10/21/23, 6:28 PM

It is not fine. Think how those PTRs will be used. For example, not in your case, but in case of Internet, mail servers often check that remote IP address, HELO hostname and the forward A record match. If you have three PTRs for one IP, it is obvious there will be problems, because you only have one name in HELO, but three names in the PTR for the remote IP to match, and nobody knows which one will be chosen to check against; 2/3 of deliveries will fail. Better don't have multiple PTRs for one IP. You have a canonical name, that name should appear in the PTR, and nothing else.

1

Reply

Gilberto Martins

10/21/23, 7:09 PM

@NikitaKipriyanov, I haven't mentioned, but this DNS serves only the internal network, and we use no SMTP server. That's why I'm using RFC 1918 IP addresses (https://www.rfc-editor.org/rfc/rfc1918.html). But I didn't know about the HELO <-> A record match, thank you for this information!!!

0

Reply

Patrick Mevzek

10/21/23, 9:23 PM

" I haven't mentioned, but this DNS serves only the internal network, and we use no SMTP server. " You don't need to bother with `PTR` records at all then. They are not needed, everything will work without them.

1

Reply

Nikita Kipriyanov

10/21/23, 9:31 PM

Not everything would work; things like PostgreSQL authentication still may depend on it. But the idea is this: if you don't plan to make things compartible "because it is just internal network", why are you asking at all? Just do anything you want and nobody will even know. If something breaks because of it, you will know. Do you have any concrete business problem or asking just out of curiosity?

0

Reply

Gilberto Martins

10/22/23, 12:31 AM

@PatrickMevzek I want to follow the proper way to do things, mostly by following RFCs (as I mentioned), and best practices. While working on this, this question came up. Other than that, some of our internal software may demand the proper DNS configuration. In any case, we believe to do things right.

0

Reply

Gilberto Martins

10/22/23, 12:36 AM

@NikitaKipriyanov "if you don't plan to make things compartible "because it is just internal network", why are you asking at all? Just do anything you want and nobody will even know". I am the leader of my team, I would know (obviously). Yes, at the same time it is a "concrete business issue" and also curiosity.

0

Reply

Patrick Mevzek

10/22/23, 6:12 PM

"I want to follow the proper way to do things, mostly by following RFCs (as I mentioned), and best practices. " Please state which RFC or best practices require each host to have a proper PTR record in the DNS.

0

Reply

Patrick Mevzek

10/22/23, 6:13 PM

@NikitaKipriyanov "Not everything would work; things like PostgreSQL authentication still may depend on it." That would be deeply wrong then. Nothing modern should rely on this, we are not in the ear of `rtelnet` or `rlogin` anymore. Basing auth on DNS records is the wrong way to do it.

0

Reply

Nikita Kipriyanov

10/23/23, 5:02 AM

No, the security doesn't base solely on DNS (there *is* a possibility to do so with [`ident` method](https://www.postgresql.org/docs/current/auth-ident.html) in Postgres, they have a big warning of what to not to do with it), but it still uses DNS. It's rather used to further restrict access, explained in the description of [pg_hba.conf file](https://www.postgresql.org/docs/15/auth-pg-hba-conf.html).

0

Reply

Gilberto Martins

11/10/23, 4:17 PM

@PatrickMevzek "Please state which RFC or best practices require each host to have a proper PTR record in the DNS" This is what I am looking for. RFC 1912 states that "Also, PTR records must point back to a valid A record, not an alias defined by a CNAME", that is, the wrong way to do it. So when I have an A record, and a few CNAME records, what is the proper way to configure the PTR records in this case?

0

Reply

Gilberto Martins

11/10/23, 4:21 PM

@PatrickMevzek "Nothing modern should rely on this". I may agree, but we all need to do things in the way modern software can rely on.

0

Reply

Patrick Mevzek

11/10/23, 4:55 PM

Can you state one real valid use case you have where not having `PTR` records is the sole reason for the thing not to work? "So when I have an A record, and a few CNAME records, what is the proper way to configure the PTR records in this case?" There isn't. Take a webhost. A given IP address can be used for thousand of websites, so what to do? Put thousand PTR records (few applications and probably 0 will deal with multiple PTR records)? Put one for one random name? Or for a name unrelated (so breaking forward resolution)? Or just stop putting that at all since useless? Think about IPv6 too...

0

Reply

Gilberto Martins

11/10/23, 5:06 PM

@PatrickMevzek "Can you state one real valid use case you have where not having PTR records is the sole reason for the thing not to work?". No, I can't, and this is not the goal of my post. The resource PTR is available (for a reason), and what I want to know is the proper way to use it in a specific circumstance, OR the proper way to config PTR in cases like the one you mentioned here, which is "A given IP address can be used for thousand of websites". My question is still the same: How to properly configure PTR in such cases? I'm asking HOW to PROPERLY configure it in this scenario.

0

Reply

Patrick Mevzek

11/10/23, 6:50 PM

"I'm asking HOW to PROPERLY configure it in this scenario." You can't (and more importantly you don't NEED TO) because the scenario you have in mind today is **40** years after the `PTR` records were invented, so in the meantime various things did change making `PTR` records kind of obsolete today (besides email handling)...

0

Reply

Gilberto Martins

11/14/23, 11:33 PM

@PatrickMevzek "so in the meantime various things did change making PTR records kind of obsolete today (besides email handling)", So you're suggesting that in a DNS configuration it's not necessary to configure any PTR records, unless for emails?

0

Reply

Patrick Mevzek

11/15/23, 2:44 AM

"So you're suggesting that in a DNS configuration it's not necessary to configure any PTR records, unless for emails?". Correct, they are not needed. For 99.999% of use cases. Could be useful in an internal network you maintain completely, for ease of maintenance, but for publicly available services, in a world full of CDNs, load balancing, geolocation, offloading to third parties, they are just either impossible to maintain properly (and none is better than wrong ones) or very difficult, for no gain.

1

Reply

Score:2

Server

t3ln3t

10/21/23, 9:54 PM

Not all applications will check the other PTRs. When you have multiple records for a single host, they may be returned in an unpredictable order. Most applications will take the first answer it gets and totally ignore the rest. Your issue will persist and only work as envisioned, when the records all match up forward & reverse. Since it's all private space, there shouldn't be anything stopping you from assigning IPs to every service. A machine can have multiple IPs and then your forward & reverse records all match. Happy day!

+ 1

Gilberto Martins

11/10/23, 4:14 PM

"Not all applications will check the other PTRs". I know this. But what I really want to know is what is the correct way to do things right, say, at internet.

0

Reply

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: PTR registers for CNAMEs

PTR registers for CNAMEs

Post an answer