On Tue, Oct 14, 2014 at 02:04:56PM +0100, Ian Jackson
<ijack...@chiark.greenend.org.uk> wrote:
> 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?)
Hmm, maybe you missed the full context of this ticket? This ticket is
exactly about this case.
> 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 know what SOP (standard operation?) means, but neither glibc,
freebsd 9, freebsd 7, cygwin nor the bind9 host utility have any problem
in reverse resolving these records, it's just adns that is nonstandard
here.
> I don't expect to have convinced you. However, I am now satisfied
> that there is no bug in adns here.
Maybe it's not a bug, by definition, but it's still incompatible to the
reest of the rssolver world.
You also ignored the cname bug I reported - I just checked, adnshost still
fails to resolve cnames pointing to cnames:
# host cname1.laendle
cname1.laendle is an alias for cname2.laendle.
cname2.laendle is an alias for cname3.laendle.
cname3.laendle has address 1.1.1.1
# adnshost cname1.laendle
cname1.laendle CNAME cname2.laendle
Error during DNS A lookup for cname1.laendle: DNS alias found where
canonical name wanted
Googling shows that this bug is deliberately in adns (apparently, the
issue is not understanding the rfc, as I found the claim the rrfc doesn't
allow cname chains), even though it's a common and legal configuration,
and needs to be supported properly unless there are well understood
reasons not to. To quote the RFC:
RFC 1034 3.6.2 Aliases and canonical names
[...] domain software should not fail when presented with CNAME chains or
loops; CNAME chains should be followed and CNAME loops signalled as an
error.
I also, and again, checked glibc, freebsd 9, freebsd 7, cygwin and bind9,
and none of these have trouble resolving cname chains, so it's again a bug
only in adns.
Incidentally, this kept adns from resolving google.de for years - google
fortunately changed their dns setup recently, but there is no reason not
to fix this bug in adns - for example, adnshost fails to resolve
www.microsoft.com for the same reason here.
> I will leave it to the Debian adns maintainer to close the bug.
Well, one would have wished adns would be fixed instead to work
rfc-compatible and/or like the rest of the world, for interoperability
reasons.
In any case, something is severely wrong if you insist that not being able
to resolve google or microsoft domains is not a bug in adns somehow. The
implied claim that this is not a bug when basically every other resolver
properly resolves these hosts is not convincing.
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / schm...@schmorp.de
-=====/_/_//_/\_,_/ /_/\_\
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
