IPv6 dynamic reverse DNS


#1

I hope you don’t mind an implementation question. I see you automatically generate reverse DNS for your IPv6 addresses if they haven’t been explicitly set:

$ dig +short -x 2001:41c8:51:278:1234:1234:1234:1234
2001-41c8-0051-0278-1234-1234-1234-1234.no-reverse-dns-set.uk0.bigv.io.

These are presumably generated “on-the-fly”.

Could I just ask: do you use a standard DNS server package to do this - and if so what is it? Or did you custom-code this?

Thanks,

Brian.

P.S. Sadly there’s no matching dynamic forward

$ dig +short 2001-41c8-0051-0278-1234-1234-1234-1234.no-reverse-dns-set.uk0.bigv.io. aaaa
$

#2

Hi,

Not at all! The DNS for *.uk0.bigv.io is being served by a pair of PowerDNS servers, which perform lookups by talking to a bit of custom Ruby (now Go) using the “pipe” backend - https://doc.powerdns.com/md/authoritative/backend-pipe/ . If the IP is in a range assigned to BigV, and we can’t find anything better to return, we send the default.

Would the A/AAAA record be helpful for any use case in particular? This is a straightforward port of the behaviour under bytemark.co.uk for unassigned (IPv4) IPs, so the way it works hasn’t really been thought through in any detail. Maybe the default, once a range has been allocated, should be to return no PTR records at all…


#3

The reason is just so that there’s matching forward and reverse DNS. Many SMTP servers on the Internet run BOFH policies on IPv6, seeing this as a chance to “do it right this time round”. The upshot is people won’t accept mail from you over v6 without matching forward and reverse DNS.

This is from a bigv.io machine: real E-mail addresses were used but elided.

$ telnet gmail-smtp-in.l.google.com. 25
Trying 2a00:1450:400c:c03::1a...
Connected to gmail-smtp-in.l.google.com.
Escape character is '^]'.
220 mx.google.com ESMTP cs1si20665919wjc.122 - gsmtp
EHLO example.com
250-mx.google.com at your service, [2001:41c8:............]
250-SIZE 35882577
250-8BITMIME
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-CHUNKING
250 SMTPUTF8
MAIL FROM:<........@........>
250 2.1.0 OK cs1si20665919wjc.122 - gsmtp
RCPT TO:<........@googlemail.com>
250 2.1.5 OK cs1si20665919wjc.122 - gsmtp
DATA
354  Go ahead cs1si20665919wjc.122 - gsmtp
Subject: test

test
.
550-5.7.1 [2001:41c8:................      12] Our system has detected
550-5.7.1 that this message is likely unsolicited mail. To reduce the amount of
550-5.7.1 spam sent to Gmail, this message has been blocked. Please visit
550-5.7.1 http://support.google.com/mail/bin/answer.py?hl=en&answer=188131 for
550 5.7.1 more information. cs1si20665919wjc.122 - gsmtp
Connection closed by foreign host.

Note: this doesn’t explicitly mention PTR records as per the similar example at
http://tanguy.ortolo.eu/blog/article109/google-ipv6-smtp-restrictions

  • but if you have PTR without matching forward, that’s generally counted as suspicious (in IP wrappers for example). Notice that the “at your service” line shows only the IP, not the auto-generated reverse DNS.

Regards,

Brian.


#4

Hi again,

I think this intersects with a couple of bugs caused by the move to the new powerdns backend. When you provision a new VM in BigV, its two primary IP addresses (v4 and V^) automatically get forward and reverse records for [vm].[group].[account].uk0.bigv.io

Since Wednesday, the PTR lookups from a.ns.uk0.bigv.io have been broken in a couple of different ways, one of which leads to IPv6 addresses getting the .no-reverse-dns-set.ip6.arpa PTR record instead of the correct one. That’s all fixed now, so out of the box, forward and reverse should match, and email should be fine.

If you add a new IPv4 address to a VM, or start using extra IPv6 addresses in your subnet, they will have the no-reverse-dns-set PTR records, so sending email from those IPs is more of a problem. But you can set the reverse DNS on these (and the primary IPs) from the control panel or CLI - and arguably should - so adding A/AAAA records for .no-reverse-dns-set. would be a mistake, I think.