[Yeti DNS Discuss] Strange BIND resolver behaviour (may be not Yeti-specific)

[Pierre Beyssac]

On Tue, Jul 14, 2015 at 10:59:00PM +0200, Stephane Bortzmeyer wrote:
> I take the opportunity of Yeti work to observe the behavior of my
> resolvers, something that I don't typically do for the "normal"
> root. So, this behaviour may be not Yeti-specific.

More analysis as I see it regarding .arpa, unless I am missing something:

.arpa is delegated, apparently by the Yeti root zone (unless there
is a glitch in zone transfers or root zone tranfers interpretation
by DNS servers), to the Yeti root servers:

arpa.                   86400   IN      NSEC    as. NS DS RRSIG NSEC
arpa.                   86400   IN      DS      38779 8 1 51FA4E1C70961517AC8D7AC7A910FA88B4498815
arpa.                   86400   IN      DS      38779 8 2 57A4DBC5F771779988CC814F3686B3D00AB688B0D5CE68EBC5729D8C 34EA533E
arpa.                   86400   IN      DS      39109 8 2 78ECB255B02F119896ACA3C5F0950AD8483E70F8241673FF4EBD655D 8CFBD3EA
arpa.                   86400   IN      DS      39109 8 1 EC737224B7B0D5D8D6D488DDEB3C613AF5661F3A
arpa.                   172800  IN      NS      bii.dns-lab.net.
arpa.                   172800  IN      NS      dahu1.yeti.eu.org.
arpa.                   172800  IN      NS      yeti-ns.tisf.net.
arpa.                   172800  IN      NS      yeti-ns.wide.ad.jp.
arpa.                   172800  IN      NS      yeti-ns.as59715.net.
arpa.                   172800  IN      NS      ns-yeti.bondis.org.
arpa.                   172800  IN      NS      yeti-ns.ix.ru.
arpa.                   172800  IN      NS      ns2.ipv6.ernet.in.
arpa.                   86400   IN      RRSIG   DS 8 1 86400 20150814044005 20150715044005 35271 . XJbkeNs/PNkw89X96untV+A19PKB5mh9GgWkxpCtMFZEOT4C0eMr
uDI3 TifN7bkINDxjwrDRq96YBnqFki3cUrtE6RaUe/rbExygV8+ytEaAznun hZ58ANm13C6QUCzhK6U02gVOXZduc94AavuOvfk19+VbyY505nAHszvZ wNk=
arpa.                   86400   IN      RRSIG   NSEC 8 1 86400 20150814044005 20150715044005 35271 . L2fmppkjINb00ztvq4+M5VFgpdcjTV2V6aHwC9gOHICTOn8/ud
DdSxoe DMl2oL0orLYWPvGHFWAfcNgYI4+QIXexEktjGAA1kLlb4KpUJszifdRd 9djj4+mkBGhGS5LtkVffPoQsshCflJoxyCri2X8XFP7zjnm3/aeiHxK0 Wzo=

The above is what 2001:559:8000::6 (yeti-ns.tisf.net) also returns. Can't
check on others due to closed transfer permissions.

Moreover, 2001:559:8000::6 also accepts AXFRs for .arpa, which yeld:

; <<>> DiG 9.10.2-P2 <<>> @2001:559:8000::6 axfr arpa.
; (1 server found)
;; global options: +cmd
arpa.                   86400   IN      SOA     bii.dns-lab.net. yeti.biigroup.cn. 2015071500 1800 900 604800 86400
arpa.                   86400   IN      RRSIG   SOA 8 1 86400 20150814090001 20150715090001 423 arpa. rFpkzDdF+TOqmMC1knXtX+NsENgub9fiC2hLTptLfJHI3080q
xCHldFj WZTO/IGVgm22rSJxlOBCivkGBsrOQgmkyEy1UuziyoEXtRreH+/mWysc ez6H2aU5CN+MN+SiGipbCOsHjAgpJRtr2bxdnexUmdruY93QjfJixZ09 KiU=
arpa.                   172800  IN      NS      bii.dns-lab.net.
arpa.                   172800  IN      NS      yeti.bofh.priv.at.
...

And bii.dns-lab.net clearly is authoritative for .arpa:
$ dig @bii.dns-lab.net soa arpa.
...
arpa.                   86400   IN      SOA     bii.dns-lab.net. yeti.biigroup.cn. 2015071500 1800 900 604800 86400

So I as see it and unless I am missing something:
- either the Yeti root .arpa delegation should be fixed to point
  the the real .arpa servers as it is currently in effect a lame
  delegation to Yeti root servers; which may explain caching problems.
- or the Yeti root servers should be made authoritative for the
  Yeti .arpa.

The former seems simpler and better to me.
-- 
Sent from my FreeBSD server on its IPv6 connection
Pierre Beyssac	      	    		pb at fasterix.frmug.org