grant> I'd be interested in learning what other things /require/ or are
grant> at least predicated on having PTR records for IPs.
Been a few years since I last delved but was appalled at some of the
pointless uses of rev-ptrs. NYT used to require it to let you connect to
their website, as one such
rharolde> Thanks for the link. Lots of pieces to get working there. Not
rharolde> nearly as simple as TSIG. But good if you are already using
rharolde> Kerberos.
MS active directory is kerberos under the hood. You don't need to run a
classic mit/hesiod KDC to get GSS-TSIG to work. But it is crypti
pemensik> I am aware search is a no-no in DNS community. However, is
pemensik> there any public documentation to this change? Is there RFC
pemensik> recommending not to use search or how it should be used,
pemensik> related to today's top level domains?
pemensik> While I agree it is dangerous, the
larissas> When an authoritative server processes a successful IXFR
larissas> transfer or a dynamic update, there is a small window of time
larissas> during which the IXFR/update coupled with a query may cause a
larissas> deadlock to occur.
The issue is a write lock. The bug can be triggered by an
bsfinkel> In the posting and on the ISC release notes page on the web,
bsfinkel> under "Feature Changes" - the first heading "9.7.2" should
bsfinkel> read "9.7.3".
No, it's correct. Those were new features in 9.7.2. 9.7.3 has a number
of bug fixes but no "new" features over 9.7.2.
But it's good
martin> there is a recurring message in named.log that goes something
martin> like:
martin> success resolving 'www.pbs.org/A' (in 'pbs.org'?) after
martin> reducing the advertised EDNS UDP packet size to 512 octets
martin> What category of message is this called and can I put something
martin>
ScottH> Given an ip of 64.84.37.2
ScottH> $dig -x 64.84.37.2
ScottH> 2.37.84.64.in-addr.arpa. 3589 IN PTR
capone.hostwizard.com.
ScottH> $dig 37.84.64.in-addr.arpa NS
ScottH> 37.84.64.in-addr.arpa. 3538IN NS ns1.nacio.com.
ScottH> 37.84.64.in-addr
ScottH> 1) Is it possible to determine what ip range/space has been
ScottH> given to user of that IP space? For example, in a colocation
ScottH> environment, I am given say, a /24, and I want to look that up
ScottH> and see if it really is a /24. I have found the -x option which
ScottH> is makin
8 matches
Mail list logo