Re: odd compile error in a lib
> I installed FreeBSD 9.1 on 3 virtually identical HP rack servers. ^^^ It seems this box is missing a Kerberos (krb5) library, but I don't know what it's called on FreeBSD. Maybe compare a list of installed packages on the servers and install what's missing on the system where linkage breaks. -JP ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
odd compile error in a lib
I installed FreeBSD 9.1 on 3 virtually identical HP rack servers.
two of the servers compile bind 9.9.2-P1 as expected.
One however dies because of a bunch of undefined references in
a library file.
a proper ./configure was issued, along with a make; on ALL 3!
I am stumped, and would appreciate suggestions.
Thanks,
Jim
export MAKE_SYMTABLE="yes"; export BASEOBJS="builtin.o client.o
config.o control.o controlconf.o interfacemgr.o listenlist.o log.o
logconf.o main.o notify.o query.o server.o sortlist.o statschannel.o
tkeyconf.o tsigconf.o update.o xfrout.o zoneconf.o lwaddr.o lwresd.o
lwdclient.o lwderror.o lwdgabn.o lwdgnba.o lwdgrbn.o lwdnoop.o
lwsearch.ounix/os.o unix/dlz_dlopen_driver.o"; if [
X"/usr/bin/perl5" = X -o X"${MAKE_SYMTABLE:-}" = X ] ; thengcc
-pthread -g -O2 -I/usr/local/include/libxml2 -I/usr/local/include -o
named ${BASEOBJS} ${LIBS0} ../../lib/lwres/liblwres.a
../../lib/dns/libdns.a -lgssapi_krb5 -lcrypto
../../lib/bind9/libbind9.a ../../lib/isccfg/libisccfg.a
../../lib/isccc/libisccc.a ../../lib/isc/libisc.a -L/usr/local/lib
-lxml2 -lz -L/usr/local/lib -liconv -lm -lreadline; else rm -f
namedtmp0;gcc -pthread -g -O2 -I/usr/local/include/libxml2
-I/usr/local/include -o namedtmp0 ${BASEOBJS} ${LIBS0}
../../lib/lwres/liblwres.a ../../lib/dns/libdns.a -lgssapi_krb5
-lcrypto ../../lib/bind9/libbind9.a ../../lib/isccfg/libisccfg.a
../../lib/isccc/libisccc.a ../../lib/isc/libisc.a -L/usr/local/lib
-lxml2 -lz -L/usr/local/lib -liconv -lm -lreadline || exit 1; rm -f
named-symtbl.c named-symtbl.o; /usr/bin/perl5 ../../util/mksymtbl.pl
-o named-symtbl.c namedtmp0 || exit 1; make named-symtbl.o || exit 1;
rm -f namedtmp1;gcc -pthread -g -O2 -I/usr/local/include/libxml2
-I/usr/local/include -o namedtmp1 ${BASEOBJS} named-symtbl.o ${LIBS0}
../../lib/lwres/liblwres.a ../../lib/dns/libdns.a -lgssapi_krb5
-lcrypto ../../lib/bind9/libbind9.a ../../lib/isccfg/libisccfg.a
../../lib/isccc/libisccc.a ../../lib/isc/libisc-nosymtbl.a
-L/usr/local/lib -lxml2 -lz -L/usr/local/lib -liconv -lm -lreadline ||
exit 1; rm -f named-symtbl.c named-symtbl.o; /usr/bin/perl5
../../util/mksymtbl.pl -o named-symtbl.c namedtmp1 || exit 1; make
named-symtbl.o || exit 1;gcc -pthread -g -O2
-I/usr/local/include/libxml2 -I/usr/local/include -o namedtmp2
${BASEOBJS} named-symtbl.o ${LIBS0} ../../lib/lwres/liblwres.a
../../lib/dns/libdns.a -lgssapi_krb5 -lcrypto
../../lib/bind9/libbind9.a ../../lib/isccfg/libisccfg.a
../../lib/isccc/libisccc.a ../../lib/isc/libisc-nosymtbl.a
-L/usr/local/lib -lxml2 -lz -L/usr/local/lib -liconv -lm -lreadline;
/usr/bin/perl5 ../../util/mksymtbl.pl -o named-symtbl2.c namedtmp2;
count=0; until diff named-symtbl.c named-symtbl2.c > /dev/null ; do
count=`expr $count + 1` ; test $count = 42 && exit 1 ; rm -f
named-symtbl.c named-symtbl.o; /usr/bin/perl5 ../../util/mksymtbl.pl
-o named-symtbl.c namedtmp2 || exit 1; make named-symtbl.o || exit 1;
gcc -pthread -g -O2 -I/usr/local/include/libxml2 -I/usr/local/include
-o namedtmp2 ${BASEOBJS} named-symtbl.o ${LIBS0}
../../lib/lwres/liblwres.a ../../lib/dns/libdns.a -lgssapi_krb5
-lcrypto ../../lib/bind9/libbind9.a ../../lib/isccfg/libisccfg.a
../../lib/isccc/libisccc.a ../../lib/isc/libisc-nosymtbl.a
-L/usr/local/lib -lxml2 -lz -L/usr/local/lib -liconv -lm -lreadline;
/usr/bin/perl5 ../../util/mksymtbl.pl -o named-symtbl2.c namedtmp2;
done ; mv namedtmp2 named; rm -f namedtmp0 namedtmp1 namedtmp2
named-symtbl2.c; fi
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5_ser_ccache_init'
/usr/local/lib/libgssapi_krb5.so: undefined reference to `krb5_rd_rep_dce'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5int_init_context_kdc'
...
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5_cc_set_config'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5_auth_con_setuseruserkey'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5_get_credentials_for_user'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5_internalize_opaque'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5_ser_pack_bytes'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5_init_creds_set_password'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5_free_tgt_creds'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`decode_krb5_ap_req'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`encode_krb5_ticket'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5_auth_con_getkey_k'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5_kt_client_default'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5_authdata_get_attribute_types'
*** [named] Error code 1
Stop in /u/qcinet/pgmr/FreeBSD/packages/bind/bind-9.9.2-P1/bin/named.
*** [subdirs] Error code 1
Stop in /u/qcinet/pgmr/FreeBSD/packages/bind/bind-9.9.2-P1/
BIND9 statistics-server: JSON?
As a fan of BIND's statistics-server I was tempted to see if I could
reduce the size of the data (XML) named produces by adding an option to
produce JSON. The patch [1] (which is terribly quick and dirty) does that.
[1] https://gist.github.com/jpmens/4958763
Accessing the URI /json on named would produce something like this:
{
"views": {
"_default": [
{
"name": "0.IN-ADDR.ARPA",
"class": "IN",
"serial": 0
},
{
"name": "B.E.F.IP6.ARPA",
"class": "IN",
"serial": 0
},
[...]
{
"name": "ww.mens.de",
"class": "IN",
"serial": 201211565
}
],
"_bind": [
{
"name": "authors.bind",
"class": "CH",
"serial": 0
},
[...]
]
}
}
Which of course is trivial to parse, with say,
#!/usr/bin/env python
import sys, json urllib2
BINDURI = 'http://127.0.0.1:8053/json'
f = urllib2.urlopen(BINDURI)
# print f.headers
doc = json.loads(f.read())
views = doc['views']
for viewname, zonelist in views.iteritems():
print viewname
for zone in zonelist:
print "\t%s %-40s %s" % (zone['class'], zone['name'],
zone['serial'])
which in turn makes this:
_default
IN 0.IN-ADDR.ARPA 0
IN B.E.F.IP6.ARPA 0
IN ww.mens.de 201211565
[...]
_bind
CH authors.bind 0
[...]
I haven't yet conducted tests as to which is actually faster to
produce/transport/consume, but I _suspect_ it's JSON. :)
If I cleaned this up appropriately and attempted to add some (all?) of
the counters (I'm mostly interested in the list of zones which is why I
started with that) would there be a chance of ISC adding this to stock
BIND9? Even better: would ISC take on the work of doing it? ;-)
Regards,
-JP
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
BIND 10 - 1.0.0 Release Candidate
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 BIND 10 - 1.0.0 Release Candidate Welcome to the first release candidate toward the first production BIND 10 1.0.0 release. BIND 10 provides a C++ library for DNS (with python wrappers) and several cooperating daemons for providing authoritative DNS service (with in-memory and SQLite3 backends and DNSSEC support), dynamic DNS, zone transfers, and experimental forwarding and recursive name service. Supplementary components are included for statistics collection and reporting and remote configuration and control. This version of BIND 10 also includes the latest snapshot of the BIND 10 DHCP development. The snapshot includes a C++ library for DHCP and two DHCP servers, one for IPv4 and one for IPv6. Features of these servers are: * Able to allocate and renew addresses, and handle lease expiration and releases. * Supports a subset of clients: - DHCPv4 clients connected to the server via a relay. - DHCPv6 clients on the same LAN as the server. * Able to configure values for standard options returned to a client, either globally or on a per-subnet basis. * Able to define new options and configure them in the same way as standard options. * Leases are stored in a MySQL database. * Configuration, logging and process control uses the same mechanisms as the BIND 10 DNS server. Note: The default testing account and password for bindctl/b10-cmdctl is now removed; a new account for remote configuration and control can be created with b10-cmdctl-usermgr, for example: b10-cmdctl-usermgr --file /usr/local/etc/bind10/cmdctl-accounts.csv We are looking for testers to provide feedback about using this release candidate. For more information about BIND 10, the release schedule, and the community testing plans, please see: http://bind10.isc.org/wiki/ProductionRelease Documentation is included and also available via the BIND 10 website at http://bind10.isc.org/ The bind10-1.0.0-rc source may be downloaded from: ftp://ftp.isc.org/isc/bind10/1.0.0-rc/bind10-1.0.0-rc.tar.gz A PGP signature of the distribution is at ftp://ftp.isc.org/isc/bind10/1.0.0-rc/bind10-1.0.0-rc.tar.gz.sha512.asc The signature was generated with the ISC code signing key which is available at https://www.isc.org/about/openpgp A summary of the significant changes since the previous release include (from the ChangeLog): 580.[func]* muks There is no longer a default user account. The old default account with username 'root' has been removed. In a fresh installation of BIND 10, the administrator has to configure a user account using the b10-cmdctl-usermgr program. (Trac #2641, git 54e8f4061f92c2f9e5b8564240937515efa6d934) 579.[bug] jinmei libdatasrc/b10-auth: corrected some corner cases in query handling of in-memory data source that led to the following invalid/odd responses from b10-auth: - duplicate RRs in answer and additional for type ANY query - incorrect NSEC for no error, no data (NXRRSET) response that matches a wildcard (Trac #2585, git abe78fae4ba3aca5eb01806dd4e05607b1241745) 578.[bug] jinmei b10-auth now returns closest encloser NSEC3 proof to queries for an empty non terminal derived from an Opt-Out NSEC RR, as clarified in errata 3441 for RFC5155. Previously it regarded such case as broken zone and returned SERVFAIL. (Trac #2659, git 24c235cb1b379c6472772d340e21577c3460b742) 577.[func] muks Added an SQLite3 index on records(rname, rdtype). This decreases insert performance by ~28% and adds about ~20% to the file size, but increases zone iteration performance. As it introduces a new index, a database upgrade would be required. (Trac #1756, git 9b3c959af13111af1fa248c5010aa33ee7e307ee) 576.[bug] tmark, tomek b10-dhcp6: Fixed bug when the server aborts operation when receiving renew and there are no IPv6 subnets configured. (Trac #2719, git 3132b8b19495470bbfd0f2ba0fe7da443926034b) 575.[bug] marcin b10-dhcp6: Fixed the bug whereby the subnet for the incoming packet was selected using only its source address. The subnet is now selected using either source address or the name of the server's interface on which the packet has been received. (Trac #2704, git 1cbacf19a28bdae50bb9bd3767bca0147fde37ed) 574.[func] tmark b10-dhcp4, b10-dhcp6: Composite key indexes were added to the lease tables to reduce lease search time. The lease4 table now has two additional indexes: a) hwaddr/subnet_id and b) client_id/subnet_id. The lease6 now has the one additional index: iaid/subnet_id/duid. Adding these indexes significantly improves lease acquisition performance.
RE: NSEC3/NSEC transition
Thank you Mark Regards, David -Original Message- From: Mark Andrews [mailto:ma...@isc.org] Sent: February-14-13 5:39 PM To: David Sherman Cc: bind-us...@isc.org Subject: Re: NSEC3/NSEC transition In message , David Sherman writes: > Thank you, Mark > > Is it safe to keep -u option for dnssec-signzone in all cases, > regardless o= f current actual NSEC/NSEC3 chains. > > Thanks, > David I had forgotten about "-u". Being a appliance vendor you may want to use it all the time as you have a dashboards etc. For individuals that are just re-signing a zone, I would say no. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: NSEC3/NSEC transition
In message , David Sherman writes: > Thank you, Mark > > Is it safe to keep -u option for dnssec-signzone in all cases, regardless o= > f current actual NSEC/NSEC3 chains. > > Thanks, > David I had forgotten about "-u". Being a appliance vendor you may want to use it all the time as you have a dashboards etc. For individuals that are just re-signing a zone, I would say no. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: NSEC3/NSEC transition
Thank you, Mark Is it safe to keep -u option for dnssec-signzone in all cases, regardless of current actual NSEC/NSEC3 chains. Thanks, David -Original Message- From: Mark Andrews [mailto:ma...@isc.org] Sent: February-14-13 3:23 PM To: David Sherman Cc: bind-us...@isc.org Subject: Re: NSEC3/NSEC transition In message , David Sherman writes: > Hi, > > If dynamic signing is used with BIND 9.8, what is the recommended > procedure t o switch from NSEC3-signed zone to NSEC-signed without > changing existing DNSK EYs (currently RSA/SHA-512 algorithms are used for > both ZSK and KSK)? > Any specific options for dnssec-signzone? Throw the signed zone imn a editor. Remove all the NSEC3 records. Remove the NSEC3PARAM records. Sign the zone but DO NOT use -3 or -H. If you don't specify a salt or iterations then a NSEC chain will be built instead of a NSEC3 chain. For a dynamic zone just remove all NSEC3PARAM records. named will do the rest. > Thanks, > David > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to > unsubscribe from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: NSEC3/NSEC transition
In message , David Sherman writes: > Hi, > > If dynamic signing is used with BIND 9.8, what is the recommended procedure t > o switch from NSEC3-signed zone to NSEC-signed without changing existing DNSK > EYs (currently RSA/SHA-512 algorithms are used for both ZSK and KSK)? > Any specific options for dnssec-signzone? Throw the signed zone imn a editor. Remove all the NSEC3 records. Remove the NSEC3PARAM records. Sign the zone but DO NOT use -3 or -H. If you don't specify a salt or iterations then a NSEC chain will be built instead of a NSEC3 chain. For a dynamic zone just remove all NSEC3PARAM records. named will do the rest. > Thanks, > David > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Export / Import all zone data
Daniel wrote on 02/14/2013 02:52:55 PM: > Just make the new server a slave of the old one, let it do zone transfers of > all of the old zones, then change the config on the new one from slave to > master. I wonder if that wasn't done once before which is why the zone files don't appear to be "structured the 'proper' way."Depending on the zone contents you can end up with a lot of $ORIGIN and the like which can be a little confusing. Perhaps the original poster could share some examples of what is seeing. Bill Confidentiality Notice: This electronic message and any attachments may contain confidential or privileged information, and is intended only for the individual or entity identified above as the addressee. If you are not the addressee (or the employee or agent responsible to deliver it to the addressee), or if this message has been addressed to you in error, you are hereby notified that you may not copy, forward, disclose or use any part of this message or any attachments. Please notify the sender immediately by return e-mail or telephone and delete this message from your system. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Export / Import all zone data
On 2/14/13 1:46 PM, "Mailinglists" wrote: > I'm looking to migrate all of the zone data from one installation of Bind to > another...hardware move. One machine is very old but running a pretty modern > version of Bind 9.6-ESV-R8. The other server is running Bind 9.8.2 and is in > use, so I'm merging existing zone data with new data, although none of the > zones will overlap. > > The problem I see is that the actual zone files, the way they are structured, > are in an old format. Bind 9.6 must still understand them, but I don't think > they are structured the "proper" way. I was hopeful there was an export / > import procedure whereby that process would sanitize the zone info and log any > errors for manual fixing. Just make the new server a slave of the old one, let it do zone transfers of all of the old zones, then change the config on the new one from slave to master. -- Daniel J McDonald, CCIE # 2495, CISSP # 78281 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Export / Import all zone data
On 14 February 2013 19:46, Mailinglists wrote: > I'm looking to migrate all of the zone data from one installation of Bind to > another...hardware move. One machine is very old but running a pretty modern > version of Bind 9.6-ESV-R8. The other server is running Bind 9.8.2 and is in > use, so I'm merging existing zone data with new data, although none of the > zones will overlap. > > The problem I see is that the actual zone files, the way they are structured, > are in an old format. Bind 9.6 must still understand them, but I don't think > they are structured the "proper" way. I was hopeful there was an export / > import procedure whereby that process would sanitize the zone info and log > any errors for manual fixing. > > Either this process is dead simple and so nobody documents it or it is all > but impossible so nobody documents it...I'm not sure. But an hour of web > searches hasn't turned up much, just lots of info about migrating to or from > a Windows based DNS to BIND. > > A helpful point in the right direction would be appreciated. > > Thank you. If you allow zone transfers to a.n.other machine you should be able to "dig @nameserver zone.name.com axfr > zone.name.com.db" to perform a zone transfer and dump it to a file. I believe the standard dig output is compatible with BIND so you can use the output file as the new BIND zone file. Steve ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Export / Import all zone data
I'm looking to migrate all of the zone data from one installation of Bind to another...hardware move. One machine is very old but running a pretty modern version of Bind 9.6-ESV-R8. The other server is running Bind 9.8.2 and is in use, so I'm merging existing zone data with new data, although none of the zones will overlap. The problem I see is that the actual zone files, the way they are structured, are in an old format. Bind 9.6 must still understand them, but I don't think they are structured the "proper" way. I was hopeful there was an export / import procedure whereby that process would sanitize the zone info and log any errors for manual fixing. Either this process is dead simple and so nobody documents it or it is all but impossible so nobody documents it...I'm not sure. But an hour of web searches hasn't turned up much, just lots of info about migrating to or from a Windows based DNS to BIND. A helpful point in the right direction would be appreciated. Thank you. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: NSEC3/NSEC transition
David Sherman wrote: > > If dynamic signing is used with BIND 9.8, what is the recommended > procedure to switch from NSEC3-signed zone to NSEC-signed without > changing existing DNSKEYs (currently RSA/SHA-512 algorithms are used for > both ZSK and KSK)? Any specific options for dnssec-signzone? Use nsupdate to delete the NSEC3PARAM record - see http://ftp.isc.org/isc/bind9/cur/9.8/doc/arm/Bv9ARM.ch04.html#id2563909 If you are using dynamic signing then you aren't using dnssec-signzone. Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Building a fresh named.root
Running bind rooted on FC 16 using the standard package. The ca file is located in /var/named/chroot/var/named/named.ca The hints are not built in. [shawn@www ~]$ strings /usr/sbin/named | grep A.ROOT-SERVERS.NET returns nothing. Centos is RedHat EL (free version) which is a stable version of fedora Core + proprietary extras ?? They may have re-imped bind differently but I doubt it. If you build it from source, over a set of installed packages, you may have residual files that came with the packages, but are not relevant to you rebuild. Bind is: > Date: Thu, 14 Feb 2013 10:44:02 -0500 > From: r...@htt-consult.com > To: d...@dotat.at > Subject: Re: Building a fresh named.root > CC: bind-users@lists.isc.org > > > On 02/14/2013 10:18 AM, Tony Finch wrote: > > Robert Moskowitz wrote: > >> More records 1/3/2013 than in the named.ca stub which IF my version > >> has > >> it builtin raises the question about keeping current at this time in the > >> Internet (and trusting Redhat to roll in new builtin hints as they go). > > No need to worry. They are only hints, and named uses them to get the > > current list of root name servers at startup. > > Thanks. Now I just have to find out from the Centos list if my version > has them built in. > > > Even if they are 15 years > > out of date it will still work, because the root name servers do not > > change very often. > > And with anycast they will probably not change until IPv9... > > Check out RFC 1606. > > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
NSEC3/NSEC transition
Hi, If dynamic signing is used with BIND 9.8, what is the recommended procedure to switch from NSEC3-signed zone to NSEC-signed without changing existing DNSKEYs (currently RSA/SHA-512 algorithms are used for both ZSK and KSK)? Any specific options for dnssec-signzone? Thanks, David ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Building a fresh named.root
On 02/14/2013 10:26 AM, Jaap Akkerhuis wrote: You too are missing some A and records! Here is mine: Use bufsize=4096 or at least something around 700, else the answer doesn't fitand is truncated. I was thinking it was something like that. Thanks. jaap dig +bufsize=4096 . ns @198.41.0.4 ; <<>> DiG 9.8.4-P1 <<>> +bufsize=4096 . ns @198.41.0.4 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33099 ;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 23 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;. IN NS ;; ANSWER SECTION: . 518400 IN NS d.root-servers.net. . 518400 IN NS j.root-servers.net. . 518400 IN NS h.root-servers.net. . 518400 IN NS g.root-servers.net. . 518400 IN NS k.root-servers.net. . 518400 IN NS b.root-servers.net. . 518400 IN NS c.root-servers.net. . 518400 IN NS i.root-servers.net. . 518400 IN NS m.root-servers.net. . 518400 IN NS e.root-servers.net. . 518400 IN NS l.root-servers.net. . 518400 IN NS a.root-servers.net. . 518400 IN NS f.root-servers.net. ;; ADDITIONAL SECTION: d.root-servers.net. 360 IN 2001:500:2d::d d.root-servers.net. 360 IN A 199.7.91.13 j.root-servers.net. 360 IN 2001:503:c27::2:30 j.root-servers.net. 360 IN A 192.58.128.30 h.root-servers.net. 360 IN 2001:500:1::803f:235 h.root-servers.net. 360 IN A 128.63.2.53 g.root-servers.net. 360 IN A 192.112.36.4 k.root-servers.net. 360 IN 2001:7fd::1 k.root-servers.net. 360 IN A 193.0.14.129 b.root-servers.net. 360 IN A 192.228.79.201 c.root-servers.net. 360 IN A 192.33.4.12 i.root-servers.net. 360 IN 2001:7fe::53 i.root-servers.net. 360 IN A 192.36.148.17 m.root-servers.net. 360 IN 2001:dc3::35 m.root-servers.net. 360 IN A 202.12.27.33 e.root-servers.net. 360 IN A 192.203.230.10 l.root-servers.net. 360 IN 2001:500:3::42 l.root-servers.net. 360 IN A 199.7.83.42 a.root-servers.net. 360 IN 2001:503:ba3e::2:30 a.root-servers.net. 360 IN A 198.41.0.4 f.root-servers.net. 360 IN 2001:500:2f::f f.root-servers.net. 360 IN A 192.5.5.241 ;; Query time: 19 msec ;; SERVER: 198.41.0.4#53(198.41.0.4) ;; WHEN: Thu Feb 14 16:24:06 2013 ;; MSG SIZE rcvd: 699 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Building a fresh named.root
On 02/14/2013 10:18 AM, Tony Finch wrote: Robert Moskowitz wrote: More records 1/3/2013 than in the named.ca stub which IF my version has it builtin raises the question about keeping current at this time in the Internet (and trusting Redhat to roll in new builtin hints as they go). No need to worry. They are only hints, and named uses them to get the current list of root name servers at startup. Thanks. Now I just have to find out from the Centos list if my version has them built in. Even if they are 15 years out of date it will still work, because the root name servers do not change very often. And with anycast they will probably not change until IPv9... Check out RFC 1606. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Building a fresh named.root
You too are missing some A and records! Here is mine: Use bufsize=4096 or at least something around 700, else the answer doesn't fitand is truncated. jaap dig +bufsize=4096 . ns @198.41.0.4 ; <<>> DiG 9.8.4-P1 <<>> +bufsize=4096 . ns @198.41.0.4 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33099 ;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 23 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;. IN NS ;; ANSWER SECTION: . 518400 IN NS d.root-servers.net. . 518400 IN NS j.root-servers.net. . 518400 IN NS h.root-servers.net. . 518400 IN NS g.root-servers.net. . 518400 IN NS k.root-servers.net. . 518400 IN NS b.root-servers.net. . 518400 IN NS c.root-servers.net. . 518400 IN NS i.root-servers.net. . 518400 IN NS m.root-servers.net. . 518400 IN NS e.root-servers.net. . 518400 IN NS l.root-servers.net. . 518400 IN NS a.root-servers.net. . 518400 IN NS f.root-servers.net. ;; ADDITIONAL SECTION: d.root-servers.net. 360 IN 2001:500:2d::d d.root-servers.net. 360 IN A 199.7.91.13 j.root-servers.net. 360 IN 2001:503:c27::2:30 j.root-servers.net. 360 IN A 192.58.128.30 h.root-servers.net. 360 IN 2001:500:1::803f:235 h.root-servers.net. 360 IN A 128.63.2.53 g.root-servers.net. 360 IN A 192.112.36.4 k.root-servers.net. 360 IN 2001:7fd::1 k.root-servers.net. 360 IN A 193.0.14.129 b.root-servers.net. 360 IN A 192.228.79.201 c.root-servers.net. 360 IN A 192.33.4.12 i.root-servers.net. 360 IN 2001:7fe::53 i.root-servers.net. 360 IN A 192.36.148.17 m.root-servers.net. 360 IN 2001:dc3::35 m.root-servers.net. 360 IN A 202.12.27.33 e.root-servers.net. 360 IN A 192.203.230.10 l.root-servers.net. 360 IN 2001:500:3::42 l.root-servers.net. 360 IN A 199.7.83.42 a.root-servers.net. 360 IN 2001:503:ba3e::2:30 a.root-servers.net. 360 IN A 198.41.0.4 f.root-servers.net. 360 IN 2001:500:2f::f f.root-servers.net. 360 IN A 192.5.5.241 ;; Query time: 19 msec ;; SERVER: 198.41.0.4#53(198.41.0.4) ;; WHEN: Thu Feb 14 16:24:06 2013 ;; MSG SIZE rcvd: 699 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Building a fresh named.root
Robert Moskowitz wrote: > > More records 1/3/2013 than in the named.ca stub which IF my version has > it builtin raises the question about keeping current at this time in the > Internet (and trusting Redhat to roll in new builtin hints as they go). No need to worry. They are only hints, and named uses them to get the current list of root name servers at startup. Even if they are 15 years out of date it will still work, because the root name servers do not change very often. Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Building a fresh named.root
On 02/14/2013 09:47 AM, Tony Finch wrote: Robert Moskowitz wrote: Which begs the next question I was going to ask. How often should I download a fresh named.zone? Never. If you keep BIND reasonably up-to-date its built-in hints will work fine. More records 1/3/2013 than in the named.ca stub which IF my version has it builtin raises the question about keeping current at this time in the Internet (and trusting Redhat to roll in new builtin hints as they go). Is there a way I can DIG my server for what it thinks . is? Like using that same DIG command? I am still checking out my files and have not started bind, but I should be ready shortly... ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Building a fresh named.root
On 02/14/2013 09:38 AM, Tony Finch wrote: Robert Moskowitz wrote: On 02/14/2013 09:05 AM, Warren Kumari wrote: BIND now comes with a baked in roots file (in the imaginatively named lib/dns/rootns.c ) Not (at least by that name) in the Redhat/Centos 6.3 bind 9.8.2. That is a source file name which is compiled into the binary. You don't need any extra files in the installation. There is no need for a named.root file, and is just another thing to go wrong… Is there anything needed in the named.conf to actuate this if you do have it? The default is to use the built-in hints. That makes sense. Smart people that put this together ;) Given the expansion of records, I think I am going to stay with an explicit root file this time around. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Building a fresh named.root
On 02/14/2013 09:34 AM, Warren Kumari wrote: On Feb 14, 2013, at 9:28 AM, Robert Moskowitz wrote: On 02/14/2013 09:05 AM, Warren Kumari wrote: BIND now comes with a baked in roots file (in the imaginatively named lib/dns/rootns.c ) Not (at least by that name) in the Redhat/Centos 6.3 bind 9.8.2. Nope -- it is in lib/dns/rootns.c in the source code tree…. Oh, of course... When BIND is compiled into a binary this gets baked in…. You can verify this by running strings on the binary. E.g: wkumari$:~$ strings /usr/local/sbin/named | grep A.ROOT-SERVERS.NET . 518400 IN NS A.ROOT-SERVERS.NET. A.ROOT-SERVERS.NET. 360 IN A 198.41.0.4 A.ROOT-SERVERS.NET. 360 IN 2001:503:BA3E::2:30 Mine is located in /usr/sbin/ and no such string. In fact the only occurance of ROOT is a comment on the location of the ROOT KEY. And anyway, baking it in is a problem as we continue to have an availablity of for the roots. There is no need for a named.root file, and is just another thing to go wrong… Is there anything needed in the named.conf to actuate this if you do have it? W On Feb 14, 2013, at 8:35 AM, Robert Moskowitz wrote: The Centos 6.3 bind and bind-chroot do not seem to come with a named.root. Does have a named.ca, though. So from my old named.root.hints include (also not provided; where did I get this?) I tried: wget ftp://ftp.rs.internic.net/domain/named.root And got a nice looking named.root last updated 1/3/2013, with nice comments on who use to run the various root servers. Then I tried: dig . ns @198.41.0.4 > named.root I see where this addr is the A root server, anyway, the response did not have A records for B, E, I, J, or L !!! And of course no records for I, J, or L. It has NS records for A thru M. What went wrong here? Which do I use? ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Building a fresh named.root
Robert Moskowitz wrote: > > Which begs the next question I was going to ask. How often should I download > a fresh named.zone? Never. If you keep BIND reasonably up-to-date its built-in hints will work fine. Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Building a fresh named.root
On 02/14/2013 09:19 AM, Christian Tardif wrote: You're right. CentOS 6.3 does not have named.root. They just call it named.ca. That's actually the same file thing. You just need to refer to the right file name for hints. Note below that I did see the named.ca which is from their namecaching setup. And this stub does not have as many records as the one I ftped, so it is already dated. Which begs the next question I was going to ask. How often should I download a fresh named.zone? Do I set up a monthly cron job? It is clear that there is movement on populating it with records. Christian... On 02/14/2013 08:35 AM, Robert Moskowitz wrote: The Centos 6.3 bind and bind-chroot do not seem to come with a named.root. Does have a named.ca, though. So from my old named.root.hints include (also not provided; where did I get this?) I tried: wget ftp://ftp.rs.internic.net/domain/named.root And got a nice looking named.root last updated 1/3/2013, with nice comments on who use to run the various root servers. Then I tried: dig . ns @198.41.0.4 > named.root I see where this addr is the A root server, anyway, the response did not have A records for B, E, I, J, or L !!! And of course no records for I, J, or L. It has NS records for A thru M. What went wrong here? Which do I use? ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Building a fresh named.root
Robert Moskowitz wrote: > On 02/14/2013 09:05 AM, Warren Kumari wrote: > > BIND now comes with a baked in roots file (in the imaginatively named > > lib/dns/rootns.c ) > > Not (at least by that name) in the Redhat/Centos 6.3 bind 9.8.2. That is a source file name which is compiled into the binary. You don't need any extra files in the installation. > > There is no need for a named.root file, and is just another thing to go > > wrong… > > Is there anything needed in the named.conf to actuate this if you do have it? The default is to use the built-in hints. Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first.___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Building a fresh named.root
Oops ignore that earlier send. Hit wrong button... On 02/14/2013 08:42 AM, Steven Carr wrote: On 14 February 2013 13:35, Robert Moskowitz wrote: What went wrong here? Which do I use? Not sure what is up with your dig response (can you post the contents) but it works for me and if your dig still isn't working use the one from FTP. sjcarr@elmo:~ $ dig . ns @198.41.0.4 ; <<>> DiG 9.8.3-P1 <<>> . ns @198.41.0.4 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6958 ;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 13 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;. IN NS Stuff deleted. ;; ADDITIONAL SECTION: j.root-servers.net. 360 IN 2001:503:c27::2:30 j.root-servers.net. 360 IN A 192.58.128.30 k.root-servers.net. 360 IN 2001:7fd::1 k.root-servers.net. 360 IN A 193.0.14.129 e.root-servers.net. 360 IN A 192.203.230.10 h.root-servers.net. 360 IN 2001:500:1::803f:235 h.root-servers.net. 360 IN A 128.63.2.53 a.root-servers.net. 360 IN 2001:503:ba3e::2:30 a.root-servers.net. 360 IN A 198.41.0.4 g.root-servers.net. 360 IN A 192.112.36.4 f.root-servers.net. 360 IN 2001:500:2f::f f.root-servers.net. 360 IN A 192.5.5.241 l.root-servers.net. 360 IN 2001:500:3::42 ;; Query time: 44 msec ;; SERVER: 198.41.0.4#53(198.41.0.4) ;; WHEN: Thu Feb 14 13:40:13 2013 ;; MSG SIZE rcvd: 508 You too are missing some A and records! Here is mine: ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.10.rc1.el6_3.6 <<>> . ns @198.41.0.4 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57006 ;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 13 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;. IN NS ;; ANSWER SECTION: . 518400 IN NS f.root-servers.net. . 518400 IN NS d.root-servers.net. . 518400 IN NS k.root-servers.net. . 518400 IN NS h.root-servers.net. . 518400 IN NS g.root-servers.net. . 518400 IN NS a.root-servers.net. . 518400 IN NS c.root-servers.net. . 518400 IN NS m.root-servers.net. . 518400 IN NS e.root-servers.net. . 518400 IN NS j.root-servers.net. . 518400 IN NS b.root-servers.net. . 518400 IN NS i.root-servers.net. . 518400 IN NS l.root-servers.net. ;; ADDITIONAL SECTION: f.root-servers.net. 360 IN 2001:500:2f::f f.root-servers.net. 360 IN A 192.5.5.241 d.root-servers.net. 360 IN 2001:500:2d::d d.root-servers.net. 360 IN A 199.7.91.13 k.root-servers.net. 360 IN 2001:7fd::1 k.root-servers.net. 360 IN A 193.0.14.129 h.root-servers.net. 360 IN 2001:500:1::803f:235 h.root-servers.net. 360 IN A 128.63.2.53 g.root-servers.net. 360 IN A 192.112.36.4 a.root-servers.net. 360 IN 2001:503:ba3e::2:30 a.root-servers.net. 360 IN A 198.41.0.4 c.root-servers.net. 360 IN A 192.33.4.12 m.root-servers.net. 360 IN 2001:dc3::35 ;; Query time: 221 msec ;; SERVER: 198.41.0.4#53(198.41.0.4) ;; WHEN: Thu Feb 14 08:08:32 2013 ;; MSG SIZE rcvd: 508 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Building a fresh named.root
On Feb 14, 2013, at 9:28 AM, Robert Moskowitz wrote: > > On 02/14/2013 09:05 AM, Warren Kumari wrote: >> BIND now comes with a baked in roots file (in the imaginatively named >> lib/dns/rootns.c ) > > Not (at least by that name) in the Redhat/Centos 6.3 bind 9.8.2. Nope -- it is in lib/dns/rootns.c in the source code tree…. When BIND is compiled into a binary this gets baked in…. You can verify this by running strings on the binary. E.g: wkumari$:~$ strings /usr/local/sbin/named | grep A.ROOT-SERVERS.NET . 518400 IN NS A.ROOT-SERVERS.NET. A.ROOT-SERVERS.NET. 360 IN A 198.41.0.4 A.ROOT-SERVERS.NET. 360 IN 2001:503:BA3E::2:30 W > >> There is no need for a named.root file, and is just another thing to go >> wrong… > > Is there anything needed in the named.conf to actuate this if you do have it? > >> >> W >> On Feb 14, 2013, at 8:35 AM, Robert Moskowitz wrote: >> >>> The Centos 6.3 bind and bind-chroot do not seem to come with a named.root. >>> Does have a named.ca, though. >>> >>> So from my old named.root.hints include (also not provided; where did I get >>> this?) I tried: >>> >>> wget ftp://ftp.rs.internic.net/domain/named.root >>> >>> And got a nice looking named.root last updated 1/3/2013, with nice >>> comments on who use to run the various root servers. >>> >>> Then I tried: >>> >>> dig . ns @198.41.0.4 > named.root >>> >>> I see where this addr is the A root server, anyway, the response did not >>> have A records for B, E, I, J, or L !!! And of course no records for >>> I, J, or L. It has NS records for A thru M. >>> >>> What went wrong here? >>> >>> Which do I use? >>> >>> >>> ___ >>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to >>> unsubscribe from this list >>> >>> bind-users mailing list >>> bind-users@lists.isc.org >>> https://lists.isc.org/mailman/listinfo/bind-users >>> > -- "I think it would be a good idea." - Mahatma Ghandi, when asked what he thought of Western civilization ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Building a fresh named.root
On 02/14/2013 09:05 AM, Warren Kumari wrote: BIND now comes with a baked in roots file (in the imaginatively named lib/dns/rootns.c ) Not (at least by that name) in the Redhat/Centos 6.3 bind 9.8.2. There is no need for a named.root file, and is just another thing to go wrong… Is there anything needed in the named.conf to actuate this if you do have it? W On Feb 14, 2013, at 8:35 AM, Robert Moskowitz wrote: The Centos 6.3 bind and bind-chroot do not seem to come with a named.root. Does have a named.ca, though. So from my old named.root.hints include (also not provided; where did I get this?) I tried: wget ftp://ftp.rs.internic.net/domain/named.root And got a nice looking named.root last updated 1/3/2013, with nice comments on who use to run the various root servers. Then I tried: dig . ns @198.41.0.4 > named.root I see where this addr is the A root server, anyway, the response did not have A records for B, E, I, J, or L !!! And of course no records for I, J, or L. It has NS records for A thru M. What went wrong here? Which do I use? ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Building a fresh named.root
You're right. CentOS 6.3 does not have named.root. They just call it named.ca. That's actually the same file thing. You just need to refer to the right file name for hints. Christian... On 02/14/2013 08:35 AM, Robert Moskowitz wrote: The Centos 6.3 bind and bind-chroot do not seem to come with a named.root. Does have a named.ca, though. So from my old named.root.hints include (also not provided; where did I get this?) I tried: wget ftp://ftp.rs.internic.net/domain/named.root And got a nice looking named.root last updated 1/3/2013, with nice comments on who use to run the various root servers. Then I tried: dig . ns @198.41.0.4 > named.root I see where this addr is the A root server, anyway, the response did not have A records for B, E, I, J, or L !!! And of course no records for I, J, or L. It has NS records for A thru M. What went wrong here? Which do I use? ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Building a fresh named.root
BIND now comes with a baked in roots file (in the imaginatively named lib/dns/rootns.c ) There is no need for a named.root file, and is just another thing to go wrong… W On Feb 14, 2013, at 8:35 AM, Robert Moskowitz wrote: > The Centos 6.3 bind and bind-chroot do not seem to come with a named.root. > Does have a named.ca, though. > > So from my old named.root.hints include (also not provided; where did I get > this?) I tried: > > wget ftp://ftp.rs.internic.net/domain/named.root > > And got a nice looking named.root last updated 1/3/2013, with nice comments > on who use to run the various root servers. > > Then I tried: > > dig . ns @198.41.0.4 > named.root > > I see where this addr is the A root server, anyway, the response did not have > A records for B, E, I, J, or L !!! And of course no records for I, J, or > L. It has NS records for A thru M. > > What went wrong here? > > Which do I use? > > > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users > -- "Does Emacs have the Buddha nature? Why not? It has bloody well everything else..." ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Building a fresh named.root
On 14 February 2013 13:35, Robert Moskowitz wrote: > What went wrong here? > > Which do I use? Not sure what is up with your dig response (can you post the contents) but it works for me and if your dig still isn't working use the one from FTP. sjcarr@elmo:~ $ dig . ns @198.41.0.4 ; <<>> DiG 9.8.3-P1 <<>> . ns @198.41.0.4 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6958 ;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 13 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;. IN NS ;; ANSWER SECTION: . 518400 IN NS j.root-servers.net. . 518400 IN NS k.root-servers.net. . 518400 IN NS e.root-servers.net. . 518400 IN NS h.root-servers.net. . 518400 IN NS a.root-servers.net. . 518400 IN NS g.root-servers.net. . 518400 IN NS f.root-servers.net. . 518400 IN NS l.root-servers.net. . 518400 IN NS i.root-servers.net. . 518400 IN NS b.root-servers.net. . 518400 IN NS d.root-servers.net. . 518400 IN NS c.root-servers.net. . 518400 IN NS m.root-servers.net. ;; ADDITIONAL SECTION: j.root-servers.net. 360 IN 2001:503:c27::2:30 j.root-servers.net. 360 IN A 192.58.128.30 k.root-servers.net. 360 IN 2001:7fd::1 k.root-servers.net. 360 IN A 193.0.14.129 e.root-servers.net. 360 IN A 192.203.230.10 h.root-servers.net. 360 IN 2001:500:1::803f:235 h.root-servers.net. 360 IN A 128.63.2.53 a.root-servers.net. 360 IN 2001:503:ba3e::2:30 a.root-servers.net. 360 IN A 198.41.0.4 g.root-servers.net. 360 IN A 192.112.36.4 f.root-servers.net. 360 IN 2001:500:2f::f f.root-servers.net. 360 IN A 192.5.5.241 l.root-servers.net. 360 IN 2001:500:3::42 ;; Query time: 44 msec ;; SERVER: 198.41.0.4#53(198.41.0.4) ;; WHEN: Thu Feb 14 13:40:13 2013 ;; MSG SIZE rcvd: 508 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Building a fresh named.root
The Centos 6.3 bind and bind-chroot do not seem to come with a named.root. Does have a named.ca, though. So from my old named.root.hints include (also not provided; where did I get this?) I tried: wget ftp://ftp.rs.internic.net/domain/named.root And got a nice looking named.root last updated 1/3/2013, with nice comments on who use to run the various root servers. Then I tried: dig . ns @198.41.0.4 > named.root I see where this addr is the A root server, anyway, the response did not have A records for B, E, I, J, or L !!! And of course no records for I, J, or L. It has NS records for A thru M. What went wrong here? Which do I use? ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND does not answer
Christian Tardif wrote: > > Back to a DNS problem, I came back to this thread. If I do a "dig +norec", I > still don't get the final answer but then, I get a whole bunch of information > (the NS records for the requested zone, and the A records relativey to these > NS records) That means the local name server is giving you a referral: it is telling you where to get the answer from, which isn't the local name server. Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
