> It appears to be the "mixed" bit that is problematic: > mdr@FLEHARISH ~ $ host Pool.ntp.org > [NXDOMAIN]
> mdr@FLEHARISH ~ $ host pool.ntp.org > [works] > mdr@FLEHARISH ~ $ host POOL.NTP.ORG > [works] I suspect your local cache of being responsible for the last of those. Using dig @a.ntpns.org, I am unable to reproduce it: % dig -t ns @a.ntpns.org pool.ntp.org [NOERROR, nine NS records, naming a.ntpns.org through i.ntpns.org] % dig -t ns @a.ntpns.org POOL.NTP.ORG [SERVFAIL] % dig -t ns @a.ntpns.org Pool.ntp.org [SERVFAIL] % dig -t ns @a.ntpns.org pool.ntp.ORG [SERVFAIL] % dig -t ns @a.ntpns.org pooL.ntp.org [SERVFAIL] I get basically the same behaviour when querying for type A: SERVFAIL for not-all-lowercase names. It looks to me as though the implementation behind a.ntpns.org just doesn't understand the DNS's name equivalence rules. I agree that those rules are severely broken, but it is much, much too late to fix them now. The same is probably true of the other eight; presumably they're all running the same code. I picked g.ntpns.org "at random" and it proved to behave more or less the same way, working only for all-lowercase names and returning SERVFAIL for others. They also return SERVFAIL when queried for other names, such as lists.ntp.org or rodents-montreal.org, even when queried in all lowercase, so I suspect they just aren't realizing that the query is one they're supposed to serve. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML [email protected] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B _______________________________________________ pool mailing list [email protected] http://lists.ntp.org/listinfo/pool
