Re: IPv6 recap

Adam Augustine <[email protected]>
Newsgroups gmane.mail.imap.courier.general
Message-ID <[email protected]>
Hello Ale,

Wow, go on vacation for two weeks and the world moves on without you. :-)

 >>There's no way I can get a reverse address for 
2a02:29e1:500:6c00::/56, as my provider itself didn't get a delegation 
for its 2a02:29e1::/32.

The upstream ISP just hasn't set up the reverse delegation yet at RIPE, 
probably just forgot to add their servers in at the time they got the 
allocation. That happened to me and I discovered it the exact same way 
you did.

 From an ISP's perspective, an IPv6 allocation isn't any different from 
an IPv4 allocation, and the rDNS is configured in the same place in 
RIPE's web interface and the exact same way. Sometimes people get hung 
up on the rDNS delegation thinking their DNS servers need to be 
reachable via IPv6 first, but they don't. They should do enable IPv6 on 
the DNS servers eventually of course, and preferably sooner rather than 
later, but it isn't immediately necessary for IPv6 rDNS to work. DNS 
doesn't care about whether the network layer if v4 or v6, it will use 
whatever is reachable.

That said, RIPE even provides secondary DNS services with ns.ripe.net, 
which is dual-stacked and so could be used to provide an IPv6 capable 
rDNS for your ISP.

The ISP can configure the rDNS delegation at RIPE without even opening a 
RIPE ticket, and then can do the rDNS delegation to you for the 
"0.0.c.6.0.0.5.0.1.e.9.2.2.0.a.2.ip6.arpa" domain. The ISP to customer 
rDNS delegation is simpler than with the typically non-octet boundary 
IPv4 because IPv6 allocations are supposed to always be done on the 
nibble boundary, as is the case with your /56.

I would open a ticket with Pianeta Fibra asking them to configure the 
IPv6 rDNS at RIPE following these instructions: 
https://apps.db.ripe.net/docs/Database-Support/Configuring-Reverse-DNS/#creating-domain-objects-for-reverse-dns 
.

It may take some doing, depending on how big and bureaucratic the 
company is, but the fact that they are doing IPv6 and it is functional 
for you is a good indicator that they are competent. In looking at the 
WHOIS information, it may be that they will in turn have to contact 
another upstream ISP ("SeFlow Internet Services" or "Aruba Network 
S.p.A.") to do it for them. I am not sure.

I'll have to read through the rest of the thread to see how things 
turned out, but I wanted to try to address the root cause of the 
delivery failure immediately.

Thanks,
   Adam

On 4/5/24 05:52, Alessandro Vesely wrote:
> Hi,
>
> this happened again, but this time caused a bounce:
>
>  <<< 554 resimta-c2p-559421.sys.comcast.net 
> resimta-c2p-559421.sys.comcast.net 2a02:29e1:500:6c00::4 Comcast 
> requires that all mail servers must have a PTR record with a valid 
> Reverse DNS entry. Currently your mail server does not fill that 
> requirement. For more information, refer to: 
> https://postmaster.comcast.net/smtp-error-codes.php#554
>
> Is it possible to inhibit use of IPv6 a little bit harder?
>
> There's no way I can get a reverse address for 
> 2a02:29e1:500:6c00::/56, as my provider itself didn't get a delegation 
> for its 2a02:29e1::/32.  It goes to 2a:: in RIPE:
>
> ; <<>> DiG 9.18.24-1-Debian <<>> 1.e.9.2.2.0.a.2.ip6.arpa ns
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 19800
> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 1232
> ; COOKIE: cad8ae482b0e559c01000000660fe49763aa815e05fda159 (good)
> ;; QUESTION SECTION:
> ;1.e.9.2.2.0.a.2.ip6.arpa.    IN    NS
>
> ;; AUTHORITY SECTION:
> 0.a.2.ip6.arpa.        3600    IN    SOA    pri.authdns.ripe.net. 
> dns.ripe.net. 1712314758 3600 600 864000 3600
>
>
> Best
> Ale
>
>
> On Mon 01/Apr/2024 12:18:52 +0200 Alessandro Vesely wrote:
>> On Sun 24/Mar/2024 13:00:34 +0100 Alessandro Vesely wrote:
>>>
>>> I ended up setting two new IPv6 addresses.  One for outgoing mail, 
>>> in ip6out and SPF record.  The other for incoming, set in esmtpd's 
>>> PORT variable and published as a secondary MX which only has an AAAA 
>>> address.
>>>
>>> Thus far neither happened to be used.
>>
>>
>> Update: one was used yesterday, for outgoing mail:
>>
>> Mar 31 04:47:04 22 north courieresmtp: 
>> id=00000000005DC23B.000000006608CEA7.000063AD,from=<[email protected]>,addr=<[email protected]>: 
>> 250 2.0.0 OK  1711853224 
>> g24-20020a1709063b1800b00a47484f15e9si3262997ejf.241 - gsmtp
>> Mar 31 04:47:04 22 north courieresmtp: 
>> id=00000000005DC23B.000000006608CEA7.000063AD,from=<[email protected]>,addr=<[email protected]>,success: 
>> delivered: alt1.aspmx.l.google.com [2a00:1450:4025:c03::1b]
>> Mar 31 04:47:04 22 north courieresmtp: 
>> id=00000000005DC23B.000000006608CEA7.000063AD,from=<[email protected]>,addr=<[email protected]>,status: 
>> success
>>
>> Probably due to a delayed response to the A query.
>>
>>
>> Best
>> Ale
>
>
> _______________________________________________
> courier-users mailing list
> [email protected]
> Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users



_______________________________________________
courier-users mailing list
[email protected]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.