IPv6 automatic reverse DNS

Hello

Many service providers have IPv4 reverse DNS for all their IP addresses. If nothing is more relevant, this will often just be the IPv4 address hashed somehow and tagged to the ISP domain name. For some arcane reason it is important to have the forward DNS match the reverse DNS or some mail servers might reject your mails.

However with IPv6 it is not practical to build such a complete reverse DNS zone. You could do a star entry but that would fail the reverse/forward match test.

It should be simple to build a DNS server that will automatically generate a hostname value for every reverse lookup received, and also be able to parse that hostname value to return the correct IPv6 address on forward lookups.

Does any DNS server have that feature? Should we have it? Why not?

I know of some arguments for:

1a) mail servers like it

1b) anti spam filters believe in the magic of checking forward/reverse match.

2) traceroute will be nicer

3) http://ipv6-test.com/ will give me 20/20 instead of 19/20 (yes that was what got me going on this post)

4) Output from "who" command on Unix will look nicer (maybe).

Regards,

Baldur

Hello

Many service providers have IPv4 reverse DNS for all their IP addresses. If nothing is more relevant, this will often just be the IPv4 address hashed somehow and tagged to the ISP domain name. For some arcane reason it is important to have the forward DNS match the reverse DNS or some mail servers might reject your mails.

However with IPv6 it is not practical to build such a complete reverse DNS zone. You could do a star entry but that would fail the reverse/forward match test.

It should be simple to build a DNS server that will automatically generate a hostname value for every reverse lookup received, and also be able to parse that hostname value to return the correct IPv6 address on forward lookups.

Does any DNS server have that feature?

It's easy enough to implement with plugins on some servers.

Should we have it?

Meh.

Why not?

Because having an automatically generated reverse DNS is a sign that the IP address is not really intended to be offering public services, rather it's a malware-infested end user machine.

I know of some arguments for:

1a) mail servers like it

... because it's a sign that the mail is coming from a real mailserver configured by a competent admin, rather than being a random compromised machine. That's not the case if you're just synthesizing reverse DNS for arbitrary IP addresses on your network.

1b) anti spam filters believe in the magic of checking forward/reverse match.

For the same reason as above. Spam filters are also often smart enough to recognize, and treat as dubious, synthesized reverse DNS.

If you have synthesized reverse DNS on your smarthost you're likely to have a bad time, perhaps initially, perhaps the first time someone notices bad mail coming from it and doesn't recognize it as a legitimate smarthost.

2) traceroute will be nicer

Most of those hosts a traceroute goes through should hopefully have stable IP addresses and meaningful, not synthesized, reverse DNS, I'd think. Consumer endpoints are the only ones where you might expect that not to be the case and synthesized reverse DNS might be an improvement there.

3) http://ipv6-test.com/ will give me 20/20 instead of 19/20 (yes that was what got me going on this post)

4) Output from "who" command on Unix will look nicer (maybe).

Regards,

Baldur

Cheers,
  Steve

Why not have DHCP update dns with both.

Luke Guillory
Network Operations Manager

Tel: 985.536.1212
Fax: 985.536.0300
Email: lguillory@reservetele.com

Reserve Telecommunications
100 RTC Dr
Reserve, LA 70084

Already available: KnotDNS.

https://www.knot-dns.cz/docs/2.x/html/configuration.html#synth-record-automatic-forward-reverse-records

Olivier

It should be simple to build a DNS server that will automatically
generate a hostname value for every reverse lookup received, and also
be able to parse that hostname value to return the correct IPv6
address on forward lookups.

Does any DNS server have that feature? Should we have it? Why not?

Nominum's nameserver software has these features. Industrial strength
nameservice, with lots of industrial-strength features, but at an
industrial-strength price.

I thought BIND had grown that feature, but I haven't used BIND for a
while now, so maybe not.

1b) anti spam filters believe in the magic of checking
forward/reverse match.

Someone in this thread said that only malware-infested end-users are
behind IP addresses with no reverse lookup. Well - no. As long as we
keep telling anyone who isn't running a full-bore commercial network to
"consume, be silent, die", we are holding everyone back, including
ourselves.

It's fine to use no-reverse-lookup as a component of a spamminess
score. It's not OK to use it as proof of spamminess.

Regards, K.

1b) anti spam filters believe in the magic of checking
forward/reverse match.

Someone in this thread said that only malware-infested end-users are
behind IP addresses with no reverse lookup. Well - no. As long as we
keep telling anyone who isn't running a full-bore commercial network to
"consume, be silent, die", we are holding everyone back, including
ourselves.

If you send mail over IPv6 from an address with no reverse DNS you
will see quite a lot of this sort of thing:

550 5.7.1 [*] Our system has detected that this message
5.7.1 does not meet IPv6 sending guidelines regarding PTR records and
5.7.1 authentication. Please review
5.7.1 Email sender guidelines - Google Workspace Admin Help for more
5.7.1 information.

It's fine to use no-reverse-lookup as a component of a spamminess
score. It's not OK to use it as proof of spamminess.

People running large mailservers made that decision some time
ago. Disagreeing with them won't make them accept your email.

Cheers,
  Steve

I'd recommend reviewing this document, and contributing as appropriate. I think it covers this pretty thoroughly today, but if there are missing considerations, now is the time to make sure that feedback is captured.
https://tools.ietf.org/html/draft-ietf-dnsop-isp-ip6rdns-02

Wes George

There are two competing drafts for synthetic rule-based PTR responses for IPv6 rDNS:

Howard Lee, Time Warner Cable (now Charter)
https://tools.ietf.org/html/draft-howard-isp-ip6rdns-08

J. Woodworth, CenturyLink
https://datatracker.ietf.org/doc/draft-woodworth-bulk-rr/

Nominum and Xerocole/Akamai also have proprietary solutions to this in their Vantio AuthServ and AuthX products, respectively.

It seems to me that it is still an open question whether the recommendations in RFC-1912 that any IP address that accesses the Internet should have a PTR and matching forward record. My personal thoughts are that the best solution would be an OPTIONAL standards-based method of generating DNS responses based on a ruleset if a specific zone record is not present, and that implementation of that requirement should be left to the developers of the auth nameserver software.

Andrew

Caveat: These thoughts are mine personally and do not represent any official position of Charter Communications.

Ληdrеw Whiте
Charter Network Operations - DAS DNS
Desk: 314-394-9594 ? Cell: 314-452-4386
andrew.white2@charter.com

I didn't say it would. IMHO reverse lookups are excellent and useful.
My only beef is with the idea that the absence of a reverse lookup
entry has any useful meaning any more, or, in particular, is proof of
spamminess.

It would be interesting (and would alter my opinion) to see statistics
of real spamminess positives ("is spam") dropping significantly if
failed reverse lookups are removed from the calculation.

Regards, K.

At the risk of getting into IETF administrivia, a little clarification is important here: The first draft you mention above was replaced by the draft I referenced in my previous email. It is currently an adopted WG draft in DNSOP, moving toward working group last call as a consensus document., thus the window for capturing and incorporating feedback is closing soon. The second document does not appear to be associated with any IETF Working Group yet, but it also isn't competing with the first document. The first draft is informational status, discussing the issues and considerations surrounding this problem, of which generating on-the-fly reverse records is one possible solution. The second draft is a proposed standard defining *how* to generate those on-the-fly reverse records assuming one decides that is the right path to take in one's network, and would dovetail nicely via reference to section 2.5 of isp-ip6-rdns.

Wes George

Thanks for the clarification, Wes.

Has anyone proposed the method of publishing v6 PTRs on-the-fly as addresses are observed passing through an ISP's router?

Andrew

Ληdrеw Whiте
Charter Network Operations - DAS DNS
Desk: 314-394-9594 ? Cell: 314-452-4386
andrew.white2@charter.com

Actually, it was *long* before that. I think it is STD 1 or STD 2 -- requirements for connecting a host to the internet. All "deliberate" Internet hosts performing useful functions should have matching forward and reverse DNS and should expect to be labelled as "untrustworthy in the extreme" if they do not. Assigning meaning to the resolved DNS name (embeded parts) is what came much later.

Hi Wes,

There are two competing drafts for synthetic rule-based PTR responses for IPv6 rDNS:

Howard Lee, Time Warner Cable (now Charter)
draft-howard-isp-ip6rdns-08

J. Woodworth, CenturyLink
draft-woodworth-bulk-rr-09 - BULK DNS Resource Records

At the risk of getting into IETF administrivia, a little clarification is important here: The first draft you mention above was replaced by the draft I referenced in my previous email. It is currently an adopted WG draft in DNSOP, moving toward working group last call as a consensus document., thus the window for capturing and incorporating feedback is closing soon. The second document does not appear to be associated with any IETF Working Group yet, but it also isn't competing with the first document. The first draft is informational status, discussing the issues and considerations surrounding this problem, of which generating on-the-fly reverse records is one possible solution. The second draft is a proposed standard defining *how* to generate those on-the-fly reverse records assuming one decides that is the right path to take in one's network, and would dovetail nicely via reference to section 2.5 of isp-ip6-rdns.

This is exactly right, and thanks for the clear explanation of arcane IETF process….

Comments on https://www.ietf.org/id/draft-ietf-dnsop-isp-ip6rdns-02.txt can go to Lee or the WG mailing list, dnsop@ietf.org <mailto:dnsop@ietf.org>. We’re trying to make it useful for operators, so having operators comment is *really* good….

The WG felt quite strongly that the document shouldn’t be prescriptive as far as telling people they *should* do this, only some of the considerations about doing it if they wish to.

John Woodworth’s bulk-rr document was discussed in the WG in the last IETF meeting (Berlin in July) and got enough interest that John was planning to keep working on it. It needs people committed to active review and discussion on it to become a WG document, which he hasn’t requested (yet), but if the idea seems useful to you, you should tell him.

best,
Suzanne
(DNSOP co-chair, but not speaking for the WG or anyone else….)