Re: Need help to know about ROOT DNS query
Hi, Thanks for the response. But i read a article in sans.org website that internal DNS server should not respond to ROOT NS query. Please find the below URL for more information. http://isc1.sans.org/dnstest.html http://isc.sans.edu/diary.html?storyid=5713 Kindly help me. --- On Thu, 17/3/11, Warren Kumari war...@kumari.net wrote: From: Warren Kumari war...@kumari.net Subject: Re: Need help to know about ROOT DNS query To: babu dheen babudh...@yahoo.co.in Cc: bind-users@lists.isc.org bind-users@lists.isc.org Date: Thursday, 17 March, 2011, 8:50 PM Nah, that's fine (and normal). BIND comes configured with the roots so that it can start resolution. I guess I don't fully understand your concern here -- is it that you are worried that the root might see queries and so know your internal hostnames? W Warren Kumari --Please excuse typing, etc -- This was sent from a device with a tiny keyboard. On Mar 17, 2011, at 7:20 AM, babu dheen babudh...@yahoo.co.in wrote: Hi, We have two internal Windows DNS servers which answer all DNS query by forwarding it to gateway DNS server running in Redhat BIND. But i have a query regarding allowing ROOT DNS query on internal DNS server. Can anyone let me know whether company Internal DNS server should respond to ROOT DNS query. When i execute # dig . NS @my-company-name-server query I am getting complete response Let me know whether enabling ROOT DNS query is a security threat. For more informaton can you read and help us to securely configure our company internal Windows DNS server and its impact of disabling it. ; DiG 9.3.3rc2 . NS @10.0.0.1 ; (1 server found) ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 34899 ;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 10 ;; QUESTION SECTION: ;. IN NS ;; ANSWER SECTION: . 49842 IN NS j.root-servers.net. . 49842 IN NS k.root-servers.net. . 49842 IN NS l.root-servers.net. . 49842 IN NS m.root-servers.net. . 49842 IN NS a.root-servers.net. . 49842 IN NS b.root-servers.net. . 49842 IN NS c.root-servers.net. . 49842 IN NS d.root-servers.net. . 49842 IN NS e.root-servers.net. . 49842 IN NS f.root-servers.net. . 49842 IN NS g.root-servers.net. . 49842 IN NS h.root-servers.net. . 49842 IN NS i.root-servers.net. ;; ADDITIONAL SECTION: j.root-servers.net. 49842 IN A 192.58.128.30 a.root-servers.net. 49842 IN A 198.41.0.4 b.root-servers.net. 49842 IN A 192.228.79.201 c.root-servers.net. 49842 IN A 192.33.4.12 d.root-servers.net. 49842 IN A 128.8.10.90 e.root-servers.net. 49842 IN A 192.203.230.10 f.root-servers.net. 49842 IN A 192.5.5.241 g.root-servers.net. 49842 IN A 192.112.36.4 h.root-servers.net. 49842 IN A 128.63.2.53 i.root-servers.net. 49842 IN A 192.36.148.17 ;; Query time: 34 msec ;; SERVER: 10.0.0.1#53(10.132.1.13) ;; WHEN: Thu Mar 17 17:16:18 2011 ;; MSG SIZE rcvd: 401 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
ip6.arpa help
Hi, I work for a small ISP in Sweden and we recently starting to provide IPv6 for customers. I have a problem thou with the reverse DNS lookups for IPv6. I don't have a good way of doing this, maybe someone can help. When we deliver IPv6 service to a customer they get at least a /64, which you all know is A LOT of addresses. This is impossible to generate unique PTR records for every address. The way we solved this is to use * PTR customer.domain.com. so that all addresses in the /64 will get the same reverse lookup. But if a customer need a unique PTR for a mailserver I cant use both *PTR customer.domain.com. and 5.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0 PTR mail.domain.com. in the same zone-file, the * will be ignored. Is this how it should be or am I doing it wrong? Instead maybe Bind can dynamically generate a answer for a reverse lookup request instead of storing all PTRs in the zone-file? Are there any good information, maybe RFC, how reverse DNS should be done in IPv6. Then I don't mean how to register a ip6.arpa and edit your zone-file in bind. I mean how you solve the problem with generate 2^64 unique PTR records for a single customer without filling your hard drive. =) Cheers // Mattias Andersson ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Stub zone vs forward zone
Hi,
On Mon, Mar 14, 2011 at 09:16:13PM -0400, Kevin Darcy wrote:
Stub zones: only available as a single level beyond one's authoritative
core, i.e. the stub server must be able to talk directly to one or more
authoritative servers for the zone.
Forward zones: can be daisy-chained an arbitrary number of levels from
the authoritative core (but this is not recommended due to
manageability, performance and reliability concerns).
Stub zones: will use whatever is in the NS records of the zone (or
descendants of the zone, if not otherwise defined) to resolve queries
which are below a zone cut.
Forward zones: will always use the configured forwarders, which must
support recursion, even for names which are known to be deeper in the
delegation hierarchy and whose delegated/authoritative nameservers might
respond more quickly than the forwarders, if asked.
Thanks for the clarification, I appreciate that.
As a general rule, use type forward zones only if you have some
connectivity issue you need to work around, e.g. trying to resolve
Internet names from behind a restrictive firewall.
So, a type forward zone is the right thing to do for the reverse DNS
zones of RFC1918 networks that are reachable via a VPN link. However,
my setup using a type forward zone doesn't work, and bind does not
even try querying the forwarders listed in the type forward zone
statement when I try to obtain a PTR record for an IP on these nets.
Use slave zones if you want a full copy of the zone available at all
times (unless it expires of course), thus maximizing fault-tolerance
and client-to-resolver performance, but subject to the replication
overhead, storage space and willingness of the zone owner to allow
zone transfers. And use stub zones if you want a more lightweight
alternative to slaving, at the expense of some fault-tolerance and
client-to-resolver performance.
In my case, my slave could only intermittendly reach the master
servers for the zones, so I'd need to reload these zones quite
frequently to catch a time when the VPN tunnel is built. Does a stub
zone use the same mechanism, or will it immediately query for the
stub's NS records when a query comes in and the NS records are no
longer cached?
To answer your specific question, the non-intuitive[1] forwarders { };
is needed to inhibit forwarding which has presumably been defined at a
higher level (semantically) in your config, either at the
1.10.in-addr.arpa level, or somewhere above that, explicitly, or
so-called global forwarding defined in the options clause.
Global forwarders. So they would take precedence over the locally
available delegations for the stub zone?
Greetings
Marc
--
-
Marc Haber | I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Stub zone vs forward zone
On Mon, Mar 14, 2011 at 01:36:10PM +0100, Jan-Piet Mens wrote:
A stub zone tells BIND to load SOA and NS records from its masters {}.
(forwarders {} is, I belive, both useless and incorrect here.) From that
point onwards, your BIND will use the data in the stub to recursively
find answers to queries for that zone.
The forwarder on the other hand, instructs BIND to forward all queries
for the zone to the addresses in the forwarders {} list; the target
server must be prepared and willing to perform recursive lookups on your
behalf.
In this case, the servers mentioned in the configuration I posted are
both authoritative for the zones that they're query for _and_ willing
to recurse for my bind if it asked them a recursive query. Which it
doesn't in the forward setup, it just immediately returns NXDOMAIN.
Greetings
Marc
--
-
Marc Haber | I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Need help to know about ROOT DNS query
In message 8423.3972...@web137314.mail.in.yahoo.com, babu dheen writes: Hi, Thanks for the response. But i read a article in sans.org website that inte= rnal DNS server should not respond to ROOT NS query. Please find the below URL for more information. http://isc1.sans.org/dnstest.html http://isc.sans.edu/diary.html?storyid=5713 Kindly help me. The query is being used to determine if the nameserver is offing recursive services to machines it shouldn't. There isn't anything wrong the query itself or to returning the NS records if the machine should be getting recursive service. --- On Thu, 17/3/11, Warren Kumari war...@kumari.net wrote: From: Warren Kumari war...@kumari.net Subject: Re: Need help to know about ROOT DNS query To: babu dheen babudh...@yahoo.co.in Cc: bind-users@lists.isc.org bind-users@lists.isc.org Date: Thursday, 17 March, 2011, 8:50 PM Nah, that's fine (and normal). BIND comes configured with the roots so that it can start resolution. I gue= ss I don't fully understand your concern here -- is it that you are worried= that the root might see queries and so know your internal hostnames? W Warren Kumari --Please excuse typing, etc -- This was sent from a device with a tiny = keyboard. On Mar 17, 2011, at 7:20 AM, babu dheen babudh...@yahoo.co.in wrote: Hi, We have two internal Windows DNS servers which answer all DNS query by f= orwarding it to gateway DNS server running in Redhat BIND. But i have a que= ry regarding allowing ROOT DNS query on internal DNS server. Can anyone let me know whether company Internal DNS server should respond t= o ROOT DNS query. When i execute # dig . NS @my-company-name-server query= I am getting complete response Let me know whether enabling ROOT DNS query is a security threat. For mo= re informaton can you read and help us to securely configure our company in= ternal Windows DNS server and its impact of disabling it. ; DiG 9.3.3rc2 . NS @10.0.0.1 ; (1 server found) ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 34899 ;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 10 ;; QUESTION SECTION: ;.= IN NS ;; ANSWER SECTION: . 49842= IN NS j.root-servers.net. . 49842= IN NS k.root-servers.net. . 49842= IN NS l.root-servers.net. . 49842= IN NS m.root-servers.net. . 49842= IN NS a.root-servers.net. . 49842= IN NS b.root-servers.net. . 49842= IN NS c.root-servers.net. . 49842= IN NS d.root-servers.net. . 49842= IN NS e.root-servers.net. . 49842= IN NS f.root-servers.net. . 49842= IN NS g.root-servers.net. . 49842= IN NS h.root-servers.net. . 49842= IN NS i.root-servers.net. ;; ADDITIONAL SECTION: j.root-servers.net. 49842 IN A= 192.58.128.30 a.root-servers.net. 49842 IN A= 198.41.0.4 b.root-servers.net. 49842 IN A= 192.228.79.201 c.root-servers.net. 49842 IN A= 192.33.4.12 d.root-servers.net. 49842 IN A= 128.8.10.90 e.root-servers.net. 49842 IN A= 192.203.230.10 f.root-servers.net. 49842 IN A= 192.5.5.241 g.root-servers.net. 49842 IN A= 192.112.36.4 h.root-servers.net. 49842 IN A= 128.63.2.53 i.root-servers.net. 49842 IN A= 192.36.148.17 ;; Query time: 34 msec ;; SERVER: 10.0.0.1#53(10.132.1.13) ;; WHEN: Thu Mar 17 17:16:18 2011 ;; MSG SIZE rcvd: 401 ___ 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 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Stub zone vs forward zone
On 18.03.2011 10:17, Marc Haber wrote:
Which it doesn't in the forward setup, it just immediately returns NXDOMAIN.
Do you include zones.rfc1918 in your configuration? What SOA RR does the
NXDOMAIN return?
| zone 0.10.in-addr.arpa {
| type forward;
| forwarders { 10.0.0.2; };
| };
|
| include /etc/bind/zones.rfc1918;
The dummy zone overrides the forward declaration:
| $ dig -x 10.0.0.3
| ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 59555
|
| ;; AUTHORITY SECTION:
| 10.in-addr.arpa. 86400 IN SOA localhost. root.localhost. 1
604800
86400 2419200 86400
Hauke.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: ip6.arpa help
Den 18. mars 2011 kl. 10.07 skrev mattias.o.anders...@gavle.se mattias.o.anders...@gavle.se: Are there any good information, maybe RFC, how reverse DNS should be done in IPv6. Then I don’t mean how to register a ip6.arpa and edit your zone-file in bind. I mean how you solve the problem with generate 2^64 unique PTR records for a single customer without filling your hard drive. =) I'm in a similar situation, and no, I don't know of a nice and easy way of doing this with current software. Pre-generating reverse records for any possible IPv6 address in your prefix(es) isn't going to work. Adding it to your own services/servers such as email servers etc, that's easy. But how can you know which of the 2^64 addresses your customer is going to be using? I've been toying with some ideas, not sure which one would actually work the best way: - don't add any IPv6 reverse records for customers - you could take the overhead of letting your customers either ask for specific reverse records to be implemented (through customer service? self service web interface?) - if your customers get assigned addresses from DHCPv6, you might consider letting it update the zones for you - in theory you could delegate the responsability for reverse records in the customers prefix to them, but I doubt many customers would actually bother running their own nameservers for this. - perhaps some alternative nameserver software is capable of generating the reverse records on the fly, based on some template, if there's not a specific record already defined? -- Regards Eivind Olsen eiv...@aminor.no ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Bind 9.8 with DNSSEC and Thales nShield HSM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I conducted a DNSSEC tests with Bind 9.8 (also 9.7.3) and Thales nShield HSM. Everything compiled fine, I was able to generate keys and list keys on HSM: # pkcs11-list -p xxx object[0]: handle 1120 class 3 label[6] 'example-KSK' id[0] object[1]: handle 1118 class 2 label[6] 'example-KSK' id[0] object[2]: handle 1121 class 3 label[6] 'example-ZSK' id[0] object[3]: handle 1119 class 2 label[6] 'example-ZSK' id[0] after that I try to sign zone and signing process ends with signed example zone. After that I added more DS records into zone to check performance and started signing zone again: # dnssec-signzone -r /dev/urandom -K ../keys/ -A -t -H 12 -3 7A821C39150237743E55 -S -o example example dnssec-signzone: warning: dns_dnssec_findmatchingkeys: error reading key file Kexample.+010+12897.private: not found Fetching KSK 57642/RSASHA512 from key repository. dnssec-signzone: fatal: No non-KSK DNSKEY found; supply a ZSK or use '-z'. No keys?! but how... Check HSM for stored keys: # pkcs11-list -p xxx object[0]: handle 1120 class 3 label[6] 'pl-KSK' id[0] object[1]: handle 1118 class 2 label[6] 'pl-KSK' id[0] object[2]: handle 1119 class 2 label[6] 'pl-ZSK' id[0] It appears that in some odd way the key is removed from the HSM device. Totally do not know why this is happening. List keys on HSM with vendor tools: # /opt/nfast/bin/nfkminfo -k (-k List keys) Key list - 4 keys AppName pkcs11 Ident uc65c8e963cca1145bd03dc67489b447d4edabdf02-18705e16324ea034c2d0ab0d77646aa74ef530a2 AppName pkcs11 Ident ucb7e2e031bf94c1a22fd05627ae352481a610-ad7cfaa7dc5489c283957141d0141129f7c7ca42 AppName pkcs11 Ident uc65c8e963cca1145bd03dc67489b447d4edabdf02-01f2a911363a8399b5d533658e4f0c3f4a945f5b AppName pkcs11 Ident ucb7e2e031bf94c1a22fd05627ae352481a610-19434597a848accd73417c203221596829f5f748 # /opt/nfast/bin/nfkminfo -l (-l List keys and names, ordered by protection) Keys protected by cardsets: key_pkcs11_uc65c8e963cca1145bd03dc67489b447d4edabdf02-18705e16324ea034c2d0ab0d77646aa74ef530a2 `pl-KSK' key_pkcs11_ucb7e2e031bf94c1a22fd05627ae352481a610-ad7cfaa7dc5489c283957141d0141129f7c7ca42 `pl-KSK' definitely something's has gone wrong. so I started to debug it when it happens. Key is missing after calling dst_lib_destroy() function from dnssec-signzone.c (line: 3963) and setting PKCS#11 library debug to highest shows: 2011-03-18 12:49:27 [22986]: pkcs11: 08CCC_DestroyObject 2011-03-18 12:49:27 [22986]: pkcs11: 08CC hSession 0x08CC 2011-03-18 12:49:27 [22986]: pkcs11: 08CC hObject 0x0461 2011-03-18 12:49:27 [22986]: pkcs11: DNFC__hash_session 0x08CC 2011-03-18 12:49:27 [22986]: pkcs11: 08CC Dhashmap lookup hash 465E9E2260D probe 13 step 77 2011-03-18 12:49:27 [22986]: pkcs11: 08CC Dlookup try hashmap[13] hash 465E9E2260D value 0x8a52a0 2011-03-18 12:49:27 [22986]: pkcs11: 08CC Dfound hashmap[13] value 0x8a52a0 2011-03-18 12:49:27 [22986]: pkcs11: DNFC__hash_session 0x08CC 2011-03-18 12:49:27 [22986]: pkcs11: 08CC Dhashmap lookup hash 465E9E2260D probe 13 step 77 2011-03-18 12:49:27 [22986]: pkcs11: 08CC Dlookup try hashmap[13] hash 465E9E2260D value 0x8a52a0 2011-03-18 12:49:27 [22986]: pkcs11: 08CC Dfound hashmap[13] value 0x8a52a0 2011-03-18 12:49:27 [22986]: pkcs11: D NFC__hash_object_handle 0x0461 2011-03-18 12:49:27 [22986]: pkcs11: 08CC Dhashmap lookup hash 2308A65EDFE probe 126 step 91 2011-03-18 12:49:27 [22986]: pkcs11: 08CC Dlookup try hashmap[126] hash 2308A65EDFE value 0x890fb0 2011-03-18 12:49:27 [22986]: pkcs11: 08CC Dfound hashmap[126] value 0x890fb0 2011-03-18 12:49:27 [22986]: pkcs11: DNFC__hash_session 0x08CC 2011-03-18 12:49:27 [22986]: pkcs11: 08CC Dhashmap lookup hash 465E9E2260D probe 13 step 77 2011-03-18 12:49:27 [22986]: pkcs11: 08CC Dlookup try hashmap[13] hash 465E9E2260D value 0x8a52a0 2011-03-18 12:49:27 [22986]: pkcs11: 08CC Dfound hashmap[13] value 0x8a52a0 2011-03-18 12:49:27 [22986]: pkcs11: 08CC DNFC__free_object, objdata 0x890fb0 handle 0x0461 2011-03-18 12:49:27 [22986]: pkcs11: 08CC Ddelete_nfkmkey 2011-03-18 12:49:27 [22986]: pkcs11: 08CC DOnly delete half of key pair, privblob.len 1136 pubblob.len 476 2011-03-18 12:49:27 [22986]: pkcs11: 08CC DDelete private key 2011-03-18 12:49:27 [22986]: pkcs11: 08CC DAnd the matching recovery data 2011-03-18 12:49:27 [22986]: pkcs11: 08CC DNFKM_recordkey appname pkcs11 keyident ucb7e2e031bf94c1a22fd05627ae352481a610-19434597a848accd73417c20 3221596829f5f748 objpriv.len 0 objpub.len 476 2011-03-18 12:49:27 [22986]: pkcs11: 08CC Dunload key 2011-03-18 12:49:27 [22986]: pkcs11: 08CC DNFC__destroy_key 0x7fff78f14234 2011-03-18 12:49:27 [22986]: pkcs11: 08CC D
Re: ip6.arpa help
On Mar 18, 2011, at 5:07 AM, mattias.o.anders...@gavle.se wrote: Hi, I work for a small ISP in Sweden and we recently starting to provide IPv6 for customers. I have a problem thou with the reverse DNS lookups for IPv6. I don’t have a good way of doing this, maybe someone can help. When we deliver IPv6 service to a customer they get at least a /64, which you all know is A LOT of addresses. This is impossible to generate unique PTR records for every address. The way we solved this is to use “* PTR customer.domain.com.” so that all addresses in the /64 will get the same reverse lookup. But if a customer need a unique PTR for a mailserver I cant use both “*PTR customer.domain.com.” and “5.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0 PTR mail.domain.com.” in the same zone-file, the * will be ignored. Is this how it should be or am I doing it wrong? Instead maybe Bind can dynamically generate a answer for a reverse lookup request instead of storing all PTRs in the zone-file? Are there any good information, maybe RFC, how reverse DNS should be done in IPv6. Then I don’t mean how to register a ip6.arpa and edit your zone-file in bind. I mean how you solve the problem with generate 2^64 unique PTR records for a single customer without filling your hard drive. =) Cheers // Mattias Andersson ATT1..c How about just 16 records per such server? A lot less than 2^64, and the extra records could be generated by script. 5.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0 PTR mail.domain.com. 5.2.0.0.0.0.0.0.0.0.0.0.0.0.0.* PTR customer.domain.com. 5.2.0.0.0.0.0.0.0.0.0.0.0.0.* PTR customer.domain.com. 5.2.0.0.0.0.0.0.0.0.0.0.0.* PTR customer.domain.com. ... 5.2.* PTR customer.domain.com. 5.* PTR customer.domain.com. I believe that the serving of * is determined by RFC, so while BIND could have its own mechanism to generate records on the fly, it can't/shouldn't do something different with *. I suspect that IPV6 PTR records might fall by the wayside for the general end user, especially since mainstream IPV6 practices are still being formed and are likely tend toward what is practical. Automatically-generated PTR records have limited value, and *just might* make DNSSEC quite a challenge. Some other, more practical method may well be devised for ISPs to show what address space they are making use of. (For example, the powers-that-be could choose to provide two top-level PTR domains for IPV6: one for full records, and the other for subnet-wide wildcards.) John ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Stub zone vs forward zone
On Mon, Mar 14, 2011 at 09:16:13PM -0400, Kevin Darcy wrote: As a general rule, use type forward zones only if you have some connectivity issue you need to work around, e.g. trying to resolve Internet names from behind a restrictive firewall. On 18.03.11 10:15, Marc Haber wrote: So, a type forward zone is the right thing to do for the reverse DNS zones of RFC1918 networks that are reachable via a VPN link. I wouldn't say so. You need forward zone, if you: - don't know which servers provide the zone, so you need to query recursive servers - want to fall back to standard resolution if forward servers are unreachable. Otherwise stub or static-stub zones will do what you want. However, my setup using a type forward zone doesn't work, and bind does not even try querying the forwarders listed in the type forward zone statement when I try to obtain a PTR record for an IP on these nets. do you have recursion enabled? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. We are but packets in the Internet of life (userfriendly.org) ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: ip6.arpa help
Hello, This was shared at RIPE61 and is pertinent to this discussion. It presents different approaches toward managing IPv6 PTR records for large subnets: http://ripe61.ripe.net/presentations/139-Ripe-61-rDNS-kzorba-freedman.pdf Thanks, Mark -Original Message- From: bind-users-bounces+mark.persiko=level3@lists.isc.org [mailto:bind-users-bounces+mark.persiko=level3@lists.isc.org] On Behalf Of Eivind Olsen Sent: Friday, March 18, 2011 7:07 AM To: bind-users Subject: Re: ip6.arpa help Den 18. mars 2011 kl. 10.07 skrev mattias.o.anders...@gavle.se mattias.o.anders...@gavle.se: Are there any good information, maybe RFC, how reverse DNS should be done in IPv6. Then I don't mean how to register a ip6.arpa and edit your zone-file in bind. I mean how you solve the problem with generate 2^64 unique PTR records for a single customer without filling your hard drive. =) I'm in a similar situation, and no, I don't know of a nice and easy way of doing this with current software. Pre-generating reverse records for any possible IPv6 address in your prefix(es) isn't going to work. Adding it to your own services/servers such as email servers etc, that's easy. But how can you know which of the 2^64 addresses your customer is going to be using? I've been toying with some ideas, not sure which one would actually work the best way: - don't add any IPv6 reverse records for customers - you could take the overhead of letting your customers either ask for specific reverse records to be implemented (through customer service? self service web interface?) - if your customers get assigned addresses from DHCPv6, you might consider letting it update the zones for you - in theory you could delegate the responsability for reverse records in the customers prefix to them, but I doubt many customers would actually bother running their own nameservers for this. - perhaps some alternative nameserver software is capable of generating the reverse records on the fly, based on some template, if there's not a specific record already defined? -- Regards Eivind Olsen eiv...@aminor.no ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: ip6.arpa help
You could just put the customer zones on a separate nameserver and let the clients dynamically update the zones. Windows will do this automatically. Named has 6to4-self and tcp-self which use TCP as the authenticator. 6to4-self lets any machine in the /48 update records for any other machine in the /48. tcp-self just lets the machine update its records. Adding 56-self and 60-self would be relatively straight forward. Named also has external match. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
key DNSKEY for areas zone .eu
hi bind network hi guru of bind is there a special key DNSKEY for areas zone .eu or should we be satisfied keys included in the tarball of bind thanks for your return -- gpg --keyserver pgp.mit.edu --recv-key 092164A7 http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x092164A7 signature.asc Description: Ceci est une partie de message numériquement signée ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: key DNSKEY for areas zone .eu
On Sat, 19 Mar 2011, fakessh @ wrote: Subject: key DNSKEY for areas zone .eu hi bind network hi guru of bind is there a special key DNSKEY for areas zone .eu or should we be satisfied keys included in the tarball of bind There already is a DS record delagation in the root zone, so no special key configuration is required for any resolver that uses the root key already. Paul ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
