Re: forward name resolution OK, but reverse doesn't work ...
The root servers no longer serve arpa or in-addr.arpa.
See the following for where to transfer these zones from
now. http://seclists.org/nanog/2011/Feb/1453
Mark
In message 4dfb848a.1080...@vr-web.de, Thomas Schweikle writes:
This is a MIME-formatted message. If you see this text it means that your
E-mail software does not support MIME-formatted messages.
--===3481814819935306570==
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol=application/pgp-signature;
boundary==_vrwf203-17994-1308329101-0001-2
This is a MIME-formatted message. If you see this text it means that your
E-mail software does not support MIME-formatted messages.
--=_vrwf203-17994-1308329101-0001-2
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: quoted-printable
Hi!
I am having some problem with my nameserver:
It resolves forward:
!user@ks1:~$ host google.com
!google.com has address 74.125.79.147
!google.com has address 74.125.79.99
!google.com has address 74.125.79.104
!google.com mail is handled by 50 alt4.aspmx.l.google.com.
!google.com mail is handled by 10 aspmx.l.google.com.
!google.com mail is handled by 20 alt1.aspmx.l.google.com.
!google.com mail is handled by 30 alt2.aspmx.l.google.com.
!google.com mail is handled by 40 alt3.aspmx.l.google.com.
But not reverse:
!user@ks1:~$ host 74.125.79.99
!Host 99.79.125.74.in-addr.arpa not found: 2(SERVFAIL)
Main configuration (partly shorted):
!options {
!directory /var/tmp/named;
!pid-file/var/run/named/named.pid;
!dump-file /var/run/named/named_dump.db;
!statistics-file /var/run/named/named.stats;
!listen-on { any; };
!#listen-on-v6 { any; };
!recursion yes;
!auth-nxdomain no;
!};
!
!// slave to root name servers
!zone . {
! type slave;
! file /var/cache/named/root/root.slave;
! masters { 192.5.5.241; };
! notify no;
!};
!
!zone arpa {
! type slave;
! file /var/cache/named/root/arpa.slave;
! masters { 192.5.5.241; };
! notify no;
!};
!
!zone in-addr.arpa {
! type slave;
! file /var/cache/named/root/in-addr.arpa.slave;
! masters { 192.5.5.241; };
! notify no;
!};
!
!// RFC 1912 (and BCP 32 for localhost)
!zone localhost {
! type master;
! file /etc/named/master/localhost-forward.db;
!};
!
!zone 127.in-addr.arpa {
! type master;
! file /etc/named/master/localhost-reverse.db;
!};
localhost-forward.db:
!$TTL 3h
!localhost. SOA localhost. nobody.localhost. 42 1d 12h 1w 3h
!; Serial, Refresh, Retry, Expire, Neg. cache TTL
!
!NS localhost.
!
!A 127.0.0.1
!::1
localhost-reverse.db:
!$TTL 3h
!@ SOA localhost. nobody.localhost. 42 1d 12h 1w 3h
!; Serial, Refresh, Retry, Expire, Neg. cache TTL
!
!NS localhost.
!
!1.0.0 PTR localhost.
!
!1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0\
! PTR localhost.
The server has AFAIS all root servers available:
!$ORIGIN .
!$TTL 86400 ; 1 day
!@ IN SOA a.root-servers.net.\
! nstld.verisign-!grs.com. (
!2011061700 ; serial
!1800 ; refresh (30 minutes)
!900; retry (15 minutes)
!604800 ; expire (1 week)
!86400 ; minimum (1 day)
!)
!RRSIG SOA 8 0 86400 2011062400 (
!2011061623 34525 .
!kKIgiv5epNOi/mWtHYtH/Zwj6O6pV+wB09rnMiaTrYRk
!HKqH7CCBdnIei6Kc1ghTRgdPwzrpgxzB3VHH/IfjEGbM
!3sNGzMOYFtykMD1xjE93hBUU08yd1ojchWW2AXayGEJZ
!5UOkaiA7cN3txThTtd1/r+k1zR5pvL+S6Pt7TTE=3D )
!$TTL 518400 ; 6 days
!NS a.root-servers.net.
!NS b.root-servers.net.
!NS c.root-servers.net.
!NS d.root-servers.net.
!NS e.root-servers.net.
!NS f.root-servers.net.
!NS g.root-servers.net.
!NS h.root-servers.net.
!NS i.root-servers.net.
!NS j.root-servers.net.
!NS k.root-servers.net.
!NS l.root-servers.net.
!NS m.root-servers.net.
!RRSIG NS 8 0 518400 2011062400 (
!2011061623 34525 .
! KgMPA/Ucp/cFQHQ36kFe8lhVV6ckJx8Zk8Mm2aiKIxOB
! v9fsM3qYyGOOqnNUGPr7V0X604r5xaePysUNy0iET+Ga
! 9WPmPeEX9438srt54qEDCBeCqn5Zbjo1lOVTrykAvtBI
!
Re: I can't resolve one domain: nhs.uk
Yay! I fixed it! It was a problem with my router. I went to the Netgear website, downloaded the latest firmware and BING! It's working now: andy:~$ dig nhs.uk ; DiG 9.8.0-P2 nhs.uk ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 39092 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 ;; QUESTION SECTION: ;nhs.uk.IN A ;; ANSWER SECTION: nhs.uk. 3200IN A 217.64.234.65 ;; AUTHORITY SECTION: nhs.uk. 171957 IN NS nsa.nhs.uk. nhs.uk. 171957 IN NS nsb.nhs.uk. ;; Query time: 36 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sat Jun 18 01:41:00 2011 ;; MSG SIZE rcvd: 76 Sorry for the noise Andy ___ 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: Resign a signed zone
In message banlktimo8lzvrqunvchctigkgzzb295...@mail.gmail.com, rams writes: Hi , Can we resign a signed zone with out key files? Please clarify me. No. The key files contain the private parts of the public/private key pair. Thanks, Ramesh -- 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: forward name resolution OK, but reverse doesn't work ...
Am 18.06.2011 02:54, schrieb Mark Andrews: The root servers no longer serve arpa or in-addr.arpa. See the following for where to transfer these zones from now. http://seclists.org/nanog/2011/Feb/1453 Arr! Seems I'd overlooked that ... :-( I've corrected my config file. Now it works again! Thanks for directing me to the right paper! -- Thomas ___ 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: forward name resolution OK, but reverse doesn't work ...
On 6/17/2011 12:44 PM, Thomas Schweikle wrote:
!zone in-addr.arpa {
! type slave;
! file /var/cache/named/root/in-addr.arpa.slave;
! masters { 192.5.5.241; };
! notify no;
!};
You're configuring you server to be authoritative for the reverse DNS
zone. It's only going to have the reverse records that it get in the
master zone from 192.5.5.241. Since your server thinks it knows
everything, it won't bother to check with google for their records.
--
Dave
___
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: forward name resolution OK, but reverse doesn't work ...
Am 17.06.2011 23:29, schrieb Eivind Olsen:
Thomas Schweikle wrote:
But not reverse:
!user@ks1:~$ host 74.125.79.99
!Host 99.79.125.74.in-addr.arpa not found: 2(SERVFAIL)
...
!zone in-addr.arpa {
! type slave;
! file /var/cache/named/root/in-addr.arpa.slave;
! masters { 192.5.5.241; };
! notify no;
!};
You seem to have set up slaving of the in-addr.arpa from 192.5.5.241
(f.root-servers.net), but that's not one of the authoritative servers for
in-addr.arpa.
Remove the slaving of in-addr.arpa from your configuration. Or check if
it's possible / allowed to slave it from any of the 6 in-addr.arpa
nameservers: [a-f].in-addr-servers.arpa
I'm guessing your logs also have entries about being unable to do zone
transfers of in-addr.arpa.
This was one of the problems --- no errors within logs at all. But I
could fix the whole thing now with given servers in the announcement
letter. All OK again. Hopefully next time I do not miss such an
announcement!
--
Thomas
___
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
Views and no answers ...
Hi!
I have set up a view for one site. It is bound to change answers as
necessary for different IP-ranges. It works as far as I could see.
But with one ip-range there is a problem ...
I can query internal addresses:
!user@kvm2~# host intweb.example.de
!intweb.example.de has address 192.168.180.46
But external ones do not work:
!user@kvm2:~# host google.com
!user@kvm2:~#
The host I am trying on has address 192.168.112.4 and I've set up my
view as:
!view ex {
!match-clients { 192.168.112.0/23; };
!recursion yes;
!
!include /etc/named/master/rootns.conf;
!include /etc/named/master/localhost.conf;
!include /etc/named/master/empty.conf;
!
!zone example.de. {
!type master;
!allow-transfer { key mskey; };
!notify no;
!file /etc/named/zhz/fwd.example;
!};
!zone mgm.example.de. {
!type master;
!allow-transfer { key mskey; };
!notify no;
!file /etc/named/zin/fwd.example.mgm;
!};
!
!zone 1.168.192.in-addr.arpa. {
!type master;
!allow-transfer { key mskey; };
!notify no;
!file /etc/named/zin/rev.192.168.1;
!};
!zone 112.168.192.in-addr.arpa. {
!type master;
!allow-transfer { key mskey; };
!notify no;
!file /etc/named/zin/rev.192.168.112;
!};
!zone 113.168.192.in-addr.arpa. {
!type master;
!allow-transfer { key mskey; };
!notify no;
!file /etc/named/zin/rev.192.168.113;
!};
!zone 180.168.192.in-addr.arpa. {
!type master;
!allow-transfer { key mskey; };
!notify no;
!file /etc/named/zin/rev.192.168.180;
!};
!zone 181.168.192.in-addr.arpa. {
!type master;
!allow-transfer { key mskey; };
!notify no;
!file /etc/named/zin/rev.192.168.181;
!};
!
!zone hz.example.de. {
!type master;
!allow-transfer { key mskey; };
!file /var/lib/named/fwd.example.hz;
!allow-update { key examplekey; };
!};
!zone in.example.de. {
!type master;
!allow-transfer { key mskey; };
!file /var/lib/named/fwd.example.in;
!allow-update { key examplekey; };
!};
!zone no.example.de. {
!type master;
!allow-transfer { key mskey; };
!file /var/lib/named/fwd.example.no;
!allow-update { key examplekey; };
!};
!
!zone 1.168.192.in-dyn.arpa. {
!type master;
!allow-transfer { key mskey; };
!file /var/lib/named/rev.192.168.1;
!allow-update { key examplekey; };
!};
!zone 112.168.192.in-dyn.arpa. {
!type master;
!allow-transfer { key mskey; };
!file /var/lib/named/rev.192.168.112;
!allow-update { key examplekey; };
!};
!zone 113.168.192.in-dyn.arpa. {
!type master;
!allow-transfer { key mskey; };
!file /var/lib/named/rev.192.168.113;
!allow-update { key examplekey; };
!};
!zone 180.168.192.in-dyn.arpa. {
!type master;
!allow-transfer { key mskey; };
!file /var/lib/named/rev.192.168.180;
!allow-update { key examplekey; };
!};
!zone 181.168.192.in-dyn.arpa. {
!type master;
!allow-transfer { key mskey; };
!file /var/lib/named/rev.192.168.181;
!allow-update { key examplekey; };
!};
!};
Any idea why the server resolves internal names, but no external
ones to this view, while it does answer internal and external names
to an other view (same setup, only a different view-line)?
!view no {
!match-clients { 127.0.0.1/8; 192.168.180.0/23; };
!recursion yes;
![... same as above ...]
I've set up query logging, but this just tells me queries are
correctly processed. But not why no answer was sent.
--
Thomas
signature.asc
Description: OpenPGP digital signature
___
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: forward name resolution OK, but reverse doesn't work ...
On 18/06/2011 02:54, Mark Andrews wrote: Actually, the root name servers still serve ARPA. They only dropped IN-ADDR.ARPA earlier this year. However, anyone who runs the kind of configuration that Thomas has should be more vigilant. I would even recommend against slaving the root zone and the arpa zone. Such configurations are best left to experts. Regards, Anand Buddhdev RIPE NCC The root servers no longer serve arpa or in-addr.arpa. See the following for where to transfer these zones from now. http://seclists.org/nanog/2011/Feb/1453 Mark ___ 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
nameserver registration
Greetings, given my domain name is example.net, and my NS servers for example.net are: ns1.example.com ns2.example.com But, example.com itself's NS servers are the registrator's (for example, godaddy's). Under this case, I don't need any glue for ns[1-2].example.com. But why I still need to register them in the .com NS servers? Thanks. ___ 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
DNSSEC Key Rollover Questions
Assume that bind 9.8.0 is in operation. A zone is configured with auto-dnssec maintain, and the zone signing keys K and its successor K' are published. Further assume that the activation time for K has passed and the zone is properly signed with K. Now suppose that the activation time for K' arrives. Should I expect bind to generate RRSIG records with K' right away? Now suppose that the deactivation date for K arrives one day later. Should I expect bind to remove RRSIG records for K right away? Or only after the signature expiration times of those signatures? Jeffry A. Spain Network Administrator Cincinnati Country Day School 6905 Given Road, Cincinnati, OH 45243-2898, USA Phone +1 (513) 979-0299; Fax +1 (513) 527-7632 (UTC-4) ___ 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: nameserver registration
That is weird. When I use my own NSes under my own domain, I need to reg them to .org NSes, when I use my registrars NSes I don't. There does not seem to be any technical reason for your scenario (imho). Regards -Sven P.S.: A direct glue of course could reduce the lookup path length and save resources. On Sat, June 18, 2011 16:30, Jorg W. wrote: Greetings, given my domain name is example.net, and my NS servers for example.net are: ns1.example.com ns2.example.com But, example.com itself's NS servers are the registrator's (for example, godaddy's). Under this case, I don't need any glue for ns[1-2].example.com. But why I still need to register them in the .com NS servers? Thanks. ___ 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: nameserver registration
On 06/18/11 09:30, Jorg W. wrote: Greetings, given my domain name is example.net, and my NS servers for example.net are: ns1.example.com ns2.example.com But, example.com itself's NS servers are the registrator's (for example, godaddy's). Under this case, I don't need any glue for ns[1-2].example.com. But why I still need to register them in the .com NS servers? Thanks. You are wrong. You do need glue records. Glue records registers the ip address of your name server(s) with the root name servers. In this case the glue records are associated with ns1 and ns2.example.com. The name servers need to be registered with the domain registrar for example.com and forwarded as glue records to the root name servers for .com. Godaddy is a domain name registrar and does not run any root name servers. However, it is the responsibility of the domain name registrars to make sure proper glue records are maintained for any/all name servers used with a domain registered with them. Lyle Giese LCR Computer Services, Inc. ___ 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: nameserver registration
On Sat, June 18, 2011 18:24, Lyle Giese wrote: On 06/18/11 09:30, Jorg W. wrote: Greetings, given my domain name is example.net, and my NS servers for example.net are: ns1.example.com ns2.example.com But, example.com itself's NS servers are the registrator's (for example, godaddy's). Under this case, I don't need any glue for ns[1-2].example.com. But why I still need to register them in the .com NS servers? Thanks. You are wrong. You do need glue records. Glue records registers the ip address of your name server(s) with the root name servers. Afaik you usually only glue at NSes that completely delegate and not necessarily at root servers, but at the parent zone where the delegation takes place. In this case the glue records are associated with ns1 and ns2.example.com. The name servers need to be registered with the domain registrar for example.com and forwarded as glue records to the root name servers for .com. Godaddy is a domain name registrar and does not run any root name servers. However, it is the responsibility of the domain name registrars to make sure proper glue records are maintained for any/all name servers used with a domain registered with them. When godaddys NSes resolve for example.net and they are glued to their parent zone, you don't need to glue them to example.net's parent zone (.net servers). That makes only sense if you want to reduce the number of lookups. On the downside you need to keep those additional glues in sync. If I ask .net for example.net it will tell me to ask godaddy's NSes. Assuming they are under .com, .com will be asked and delegates (with glue records) to godaddy, and I can finally ask godaddy's NS what I want to know. If there was additional glue for godaddy's NSes in .net for example.net, the difference is: .net can tell me, you need to ask godaddy's NS named XYZ and btw, save your time, you can find it at: IP. It is not necessarily needed though. Lyle Giese LCR Computer Services, Inc. ___ 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 -Sven ___ 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: nameserver registration
On Sat, June 18, 2011 18:34, Lyle Giese wrote: On 06/18/11 10:21, Sven Eschenberg wrote: That is weird. When I use my own NSes under my own domain, I need to reg them to .org NSes, when I use my registrars NSes I don't. There does not seem to be any technical reason for your scenario (imho). Regards -Sven P.S.: A direct glue of course could reduce the lookup path length and save resources. On Sat, June 18, 2011 16:30, Jorg W. wrote: Greetings, given my domain name is example.net, and my NS servers for example.net are: ns1.example.com ns2.example.com But, example.com itself's NS servers are the registrator's (for example, godaddy's). Under this case, I don't need any glue for ns[1-2].example.com. But why I still need to register them in the .com NS servers? Thanks. When using someone's name servers, it is THEIR responsibility to make sure proper glue records are generated. When it's your name servers, you are required to register them. You are right, I didn't catch the glue was supposed to be in .com wehere the NSes are, which are someone else's - doh - I expect that someone who providers nameservers takes care of gluing them appropriately, so it can work. My domain is lcrcomputer.com. if I use ns1 and ns2.lcrcomputer.com as my name servers and do not have glue records for them in the .com root servers, how is anyone going to find the name servers for my domain? You are absolutely right, a small misreading in the scenario, my .org servers are of course glued in .org, if I had used all the NSes of the registrar (in .net, .com whatsoever), those of course would be glued in their corresponding parent zones. I expected that to be obvious and clear, as I said, I misread the scenario in the end and assumed that provided NSes are properly glued by their operators. But in the example given, whoever owns example.com needs to create the glue records by registering ns1 and ns2.example.com as name servers. And if the owner of example.net does not make sure the name servers they want to use are not registered, then they should not be wondering why others will have trouble resolving example.net. Agreed at some point we need glue and wherever a full delegation of a subzone is done, we need to have glue, no doubt ;-). Lyle Giese LCR Computer Services, Inc. ___ 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 Regards -Sven ___ 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: nameserver registration
On 6/18/2011 12:24 PM, Lyle Giese wrote: On 06/18/11 09:30, Jorg W. wrote: Greetings, given my domain name is example.net, and my NS servers for example.net are: ns1.example.com ns2.example.com But, example.com itself's NS servers are the registrator's (for example, godaddy's). Under this case, I don't need any glue for ns[1-2].example.com. But why I still need to register them in the .com NS servers? Thanks. You are wrong. You do need glue records. Glue records registers the ip address of your name server(s) with the root name servers. Only TLDs/ccTLDs (com., org., xxx., etc.) insert name servers and glue into the root name servers. All second level domains (example.com., example.net., etc.) insert name servers and glue into their parent TLD/ccTLD's name servers. To be clear: name servers are NS records glue records are A/ records that point to IPv4/IPv6 addresses for hostnames that are name servers. In this case the glue records are associated with ns1 and ns2.example.com. The name servers need to be registered with the domain registrar for example.com and forwarded as glue records to the root name servers for .com. Root in DNS terms is .. Better to say to the authoritative DNS servers for .com. or just TLD/ccTLD name servers. Godaddy is a domain name registrar and does not run any root name servers. However, it is the responsibility of the domain name registrars to make sure proper glue records are maintained for any/all name servers used with a domain registered with them. All domains, at every level, have to configure their records such that the tree can be walked from root to their domain. Follow the .s. For: this.long.chain.example.com. com. must be delegated by . example.com. must be delegated by com. chain.example.com. must be delegated by example.com. long.chain.example.com. must be delegated by chain.example.com. this.long.chain.example.com. must be delegated by long.chain.example.com. The wikipedia article on DNS is quite good: http://en.wikipedia.org/wiki/Domain_Name_System In the particular case of the OP - example.net. has name servers under example.com. To make lookups for records under example.net., resolvers walk the tree from . to net. and get NS records - ns1.example.com. and ns2.example.com. You can't insert glue records into net. for name servers that exist under com., so now resolvers walk the tree from . to com. to get the name servers for example.com. which in the OP's case are - GoDaddy name servers. If there are no glue records in com. for ns1.example.com. and ns2.example.com., then resolvers will just ask the authoritative name servers for example.com. (which in the OP's case are - GoDaddy name servers) for the A/ records for ns1.example.com. and ns2.example.com. If the GoDaddy name servers provide A/ records for ns1.example.com. and ns2.example.com., then resolution works and everyone is happy. Glue is only required if that is the only way to traverse the tree to get to the IP addresses for the name servers for a domain. Can someone point to an RFC or BCP that says that *all* name servers *must* have glue present in their parent? -DMM ___ 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: nameserver registration
On 06/18/11 10:26, David Miller wrote: All domains, at every level, have to configure their records such that the tree can be walked from root to their domain. Follow the .s. For: this.long.chain.example.com. com. must be delegated by . example.com. must be delegated by com. chain.example.com. must be delegated by example.com. long.chain.example.com. must be delegated by chain.example.com. this.long.chain.example.com. must be delegated by long.chain.example.com. The wikipedia article on DNS is quite good: http://en.wikipedia.org/wiki/Domain_Name_System In the particular case of the OP - example.net. has name servers under example.com. To make lookups for records under example.net., resolvers walk the tree from . to net. and get NS records - ns1.example.com. and ns2.example.com. You can't insert glue records into net. for name servers that exist under com., so now resolvers walk the tree from . to com. to get the name servers for example.com. which in the OP's case are - GoDaddy name servers. In theory, you can insert glue records anywhere above the zone in question. See RFC 2181, section 5.4.1. As an example, glue for the servers adns1.berkeley.edu and adns2.berkeley.edu exist in the root zone. If there are no glue records in com. for ns1.example.com. and ns2.example.com., then resolvers will just ask the authoritative name servers for example.com. (which in the OP's case are - GoDaddy name servers) for the A/ records for ns1.example.com. and ns2.example.com. If the GoDaddy name servers provide A/ records for ns1.example.com. and ns2.example.com., then resolution works and everyone is happy. Glue is only required if that is the only way to traverse the tree to get to the IP addresses for the name servers for a domain. A registrar can't know this a priori, and more importantly, can't know that it will always be the case with a particular domain and/or NS RRs. Registrars therefore have to require registered DNS servers when a registrant wants a new domain. Can someone point to an RFC or BCP that says that *all* name servers *must* have glue present in their parent? I doubt such an RFC exists. RFC 1912, section 2.3 does a nice job of summing up where glue is necessary and where it isn't, but that doesn't take into account NS records that are in zones that are completely outside the administration of the registrar and/or registrant. michael ___ 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: nameserver registration
On Jun 18 2011, Michael Sinatra wrote: In theory, you can insert glue records anywhere above the zone in question. See RFC 2181, section 5.4.1. As an example, glue for the servers adns1.berkeley.edu and adns2.berkeley.edu exist in the root zone. For fj, hk, and xn--j6w193g. These are examples of what some of the BIND documentation calls sibling glue. Of course, at the root zone level, *all* NS records need either required glue or sibling glue, because every single one of them is somewhere under the root zone. At least, until the aliens contact us and we get the Internet spliced into the Galactinet .. Also, the required glue + sibling glue desideratum is not always enough. Consider foo.com. NS ns1.bar.net. foo.com. NS ns2.bar.net. and bar.net. NS ns1.foo.com. bar.net. NS ns2.foo.com. Neither seems to to need glue in either com or net, but without either the domains cannot be resolved. This was a significant issue when VeriSign changed the way the *.gltd-servers.net responded last year. -- Chris Thompson Email: c...@cam.ac.uk ___ 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: nameserver registration
On 06/18/11 15:23, Chris Thompson wrote: On Jun 18 2011, Michael Sinatra wrote: In theory, you can insert glue records anywhere above the zone in question. See RFC 2181, section 5.4.1. As an example, glue for the servers adns1.berkeley.edu and adns2.berkeley.edu exist in the root zone. For fj, hk, and xn--j6w193g. These are examples of what some of the BIND documentation calls sibling glue. You forgot au :) And I now recall that the subject of sibling glue has been discussed on this list a couple years ago. Of course, at the root zone level, *all* NS records need either required glue or sibling glue, because every single one of them is somewhere under the root zone. At least, until the aliens contact us and we get the Internet spliced into the Galactinet .. Also, the required glue + sibling glue desideratum is not always enough. Consider foo.com. NS ns1.bar.net. foo.com. NS ns2.bar.net. and bar.net. NS ns1.foo.com. bar.net. NS ns2.foo.com. Neither seems to to need glue in either com or net, but without either the domains cannot be resolved. This was a significant issue when VeriSign changed the way the *.gltd-servers.net responded last year. That's a good example (dare I say the canonical one?). I was thinking of even simpler cases, such as where you are at least a layer below SLD. Consider: baz.org. NS ns1.dns.podunk.edu. baz.org. NS ns2.dns.podunk.edu. and dns.podunk.edu. NS ns1.dns.podunk.edu. dns.podunk.edu. NS ns2.dns.podunk.edu. In theory, you should only need glue in podunk.edu, but podunk.edu isn't under the control of any registry (or registrar for that matter). If the registrar for baz.org wants to be sure that things are going to work--and that they will stay working--then you need appropriate glue at a higher level. Because registrars (and even registries) can't always control the immediate parent of the NS, they require registration of the nameserver to allow for glue to be placed at higher levels. michael ___ 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: nameserver registration
2011/6/19 Michael Sinatra mich...@rancid.berkeley.edu: On 06/18/11 15:23, Chris Thompson wrote: Of course, at the root zone level, *all* NS records need either required glue or sibling glue, because every single one of them is somewhere under the root zone. At least, until the aliens contact us and we get the Internet spliced into the Galactinet .. So, every nameserver's hostname with their IP addresses must exist in root zone (the .) ? Also, the required glue + sibling glue desideratum is not always enough. Consider foo.com. NS ns1.bar.net. foo.com. NS ns2.bar.net. and bar.net. NS ns1.foo.com. bar.net. NS ns2.foo.com. Neither seems to to need glue in either com or net, but without either the domains cannot be resolved. This was a significant issue when VeriSign changed the way the *.gltd-servers.net responded last year. That's a good example (dare I say the canonical one?). I was thinking of even simpler cases, such as where you are at least a layer below SLD. Consider: baz.org. NS ns1.dns.podunk.edu. baz.org. NS ns2.dns.podunk.edu. and dns.podunk.edu. NS ns1.dns.podunk.edu. dns.podunk.edu. NS ns2.dns.podunk.edu. In theory, you should only need glue in podunk.edu, but podunk.edu isn't under the control of any registry (or registrar for that matter). If the registrar for baz.org wants to be sure that things are going to work--and that they will stay working--then you need appropriate glue at a higher level. Because registrars (and even registries) can't always control the immediate parent of the NS, they require registration of the nameserver to allow for glue to be placed at higher levels. The answer above is excellent, thanks. And, is there a way to know how my nameservers are registered in any level of zone? Jorg. ___ 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: nameserver registration
2011/6/19 David Miller dmil...@tiggee.com: In the particular case of the OP - example.net. has name servers under example.com. To make lookups for records under example.net., resolvers walk the tree from . to net. and get NS records - ns1.example.com. and ns2.example.com. You can't insert glue records into net. for name servers that exist under com., so now resolvers walk the tree from . to com. to get the name servers for example.com. which in the OP's case are - GoDaddy name servers. If there are no glue records in com. for ns1.example.com. and ns2.example.com., then resolvers will just ask the authoritative name servers for example.com. (which in the OP's case are - GoDaddy name servers) for the A/ records for ns1.example.com. and ns2.example.com. If the GoDaddy name servers provide A/ records for ns1.example.com. and ns2.example.com., then resolution works and everyone is happy. Glue is only required if that is the only way to traverse the tree to get to the IP addresses for the name servers for a domain. Thanks, that's what I wanted to know. ___ 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: nameserver registration
On Sat, Jun 18, 2011 at 4:22 PM, Michael Sinatra mich...@rancid.berkeley.edu wrote: Consider: baz.org. NS ns1.dns.podunk.edu. baz.org. NS ns2.dns.podunk.edu. and dns.podunk.edu. NS ns1.dns.podunk.edu. dns.podunk.edu. NS ns2.dns.podunk.edu. In theory, you should only need glue in podunk.edu, but podunk.edu isn't under the control of any registry (or registrar for that matter). If the registrar for baz.org wants to be sure that things are going to work--and that they will stay working--then you need appropriate glue at a higher level. Unfortunately, that won't work. It violates the principle of glue. From RFC 1034 (emphasis on the last sentence): In particular, if the name of the name server is itself in the subzone, we could be faced with the situation where the NS RRs tell us that in order to learn a name server's address, we should contact the server using the address we wish to learn. To fix this problem, a zone contains glue RRs which are not part of the authoritative data, and are address RRs for the servers. These RRs are only necessary if the name server's name is below the cut, and are only used as part of a referral response. Even if referring servers return such RRs, they are considered out-of-bailiwick, and resolvers should resolve the names, rather than trust the additional RRs. i.e., .org servers should not be handing out RRs under .edu. Hence the dependencies, which can get long and complicated, but they're part of the DNS. Casey ___ 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
