Marc Lehmann writes ("Re: Bug#467485: adns _does_ work with multiple ptr
records"):
> On Mon, Oct 13, 2014 at 05:47:29PM +0100, Ian Jackson
> <ijack...@chiark.greenend.org.uk> wrote:
> > DNS. adns by default (ie if you don't say `-t ptr-') insists that
> > every address returned has a matching forward entry.
>
> Adns doesn't do that, as at least test1.laendle resolves to 10.0.0.255,
> but wasn't returned, so it failed for this ptr record.
The adns API does not require applications which use adns to deal with
partial information in this way. In the general case returning only
part of an RRset would be a serious bug in DNS software.
> # adnshost -i 10.0.0.255
> Error during DNS PTR lookup for 255.0.0.10.in-addr.arpa: Inconsistent
> resource records in DNS
>
> # host 10.0.0.255
> 255.0.0.10.in-addr.arpa domain name pointer test2.laendle.
> 255.0.0.10.in-addr.arpa domain name pointer test1.laendle.
> # host test1.laendle
> test1.laendle has address 10.0.0.255
> test1.laendle has IPv6 address 3ffe:1900:4545:2:240::f7e1
I assume from your lack of comment on it that test2.laendle does not
have an A RR mentioning 10.0.0.255. (Why did you not explictly say so?)
> Besides, adns should follow the RFCs by default, that is, return the ptr
> records when requested and follow cname chains instead of erroring out for
> valid zone data (google.de was unresolvable for years by adns until they
> recently changed their DNS setup), instead of imposing its own unrealistic
> standards on the internet - no other resolver fails this way.
Checking forward correspondence for reverse DNS is SOP and has been
for many years. Anyone who uses rdns information needs to do that
because otherwise anyone can claim to be anyone else.
I don't expect to have convinced you. However, I am now satisfied
that there is no bug in adns here. I will leave it to the Debian adns
maintainer to close the bug.
Ian.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
