Problem on CNAME configuration.
Hi,
Sorry in advance for my very bad english!
I have a question (problem?) with my Bind configuration.
My Bind server is on a Debian Lenny.
I'm on a local network with domainname home.fr
I wish to create shortcut name to access an internet application.
Example:
In my browser, if I write http://myapplication/ , I wish the query go to an
external serveur server1.mydomain.com (without redirection)
Here is a part of my db.home.fr:
[...]
@ IN NS gateway.home.fr.
gatewayIN A 192.168.6.1
myapplication IN CNAME server1.mydomain.com.
[...]
Here is my options section:
options {
directory /var/cache/bind;
listen-on {
192.168.6.1/24;
127.0.0.1;
};
listen-on-v6 { none; };
version Not avaible;
allow-recursion {
192.168.6.0/24;
127.0.0.1;
};
forward only;
forwarders {
212.27.53.252;
212.27.54.252;
};
auth-nxdomain no;# conform to RFC1035
};
Here is my zone section:
zone home.fr {
type master;
file /etc/bind/db.home.fr;
allow-query {
127.0.0.1;
192.168.6.0/24;
};
};
/etc/resolv.conf on my computer:
search home.fr
nameserver 192.168.6.1 # routeur's ip where is the Bind server
/etc/resolv.conf on the Bind server
search home.fr
nameserver 127.0.0.1
#
With the commande host, it works properly:
~$ host myapplication
myapplication.home.fr is an alias for server1.mydomain.com.
server1.mydomain.com has address X.X.X.X
But in my browser, if I write http://myapplication/, the dns request failed.
Here is the bind log (192.168.6.28 is my computer):
queries: client 192.168.6.28#36728: query: myapplication.home.fr IN A +
queries: client 127.0.0.1#56888: query: myapplication IN A +
queries: client 127.0.0.1#56888: query: myapplication IN A +
I don't understand why the first request didn't respond? And why there's a
second
request without the domain name?
Thanks for your help!
Cyril.
signature.asc
Description: PGP signature
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Problem on CNAME configuration.
On Mon, Oct 05, 2009 at 02:40:07PM +0200, Cyril Gaudin - Rodacom c.gau...@rodacom.fr wrote a message of 139 lines which said: Sorry in advance for my very bad english! There is a français mailing list: dns...@cru.fr And why there's a second request without the domain name? Wild guess: the browser uses a proxy, which runs on 192.168.6.1. The proxy is doing name resolution (and uses 127.0.0.1, which is in the resolv.conf of its machine). ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Problem on CNAME configuration.
On Mon, 5 Oct 2009, Cyril Gaudin - Rodacom wrote: But in my browser, if I write http://myapplication/, the dns request failed. Here is the bind log (192.168.6.28 is my computer): queries: client 192.168.6.28#36728: query: myapplication.home.fr IN A + queries: client 127.0.0.1#56888: query: myapplication IN A + queries: client 127.0.0.1#56888: query: myapplication IN A + I don't understand why the first request didn't respond? And why there's a second request without the domain name? You may want to ask your browser users list. Some browsers dont' use the system's resolver libraries and may do DNS lookups their own way. What browser are you using? ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Problem on CNAME configuration.
Le Mon, 5 Oct 2009 14:42:47 +0100, Stephane Bortzmeyer bortzme...@nic.fr a écrit : Wild guess: the browser uses a proxy, which runs on 192.168.6.1. The proxy is doing name resolution (and uses 127.0.0.1, which is in the resolv.conf of its machine). Indeed, there is a transparent squid proxy! Maybe squid didn't append domainname in the dns request? I will look this way! Le Mon, 5 Oct 2009 09:04:41 -0500 (CDT), Jeremy C. Reed jr...@isc.org a écrit : You may want to ask your browser users list. Some browsers dont' use the system's resolver libraries and may do DNS lookups their own way. What browser are you using? In my company, we use the most common browser (firefox, ie7, ie8, chrome and safari). But I think, like Stephane said, that squid made this request. Thanks for your help! -- Cyril Gaudin Rodacom - Infrastructure Tel : 04 76 46 13 69 www.rodacom.fr signature.asc Description: PGP signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: update-policy restricting to a subnet
I take it this is not possible using update-policy? _ Nicholas Miller, ITS, University of Colorado at Boulder On Sep 30, 2009, at 11:29 AM, Nicholas F Miller wrote: Is it possible to restrict user machines to only be able to update their 'A' records on a specific subnet? We would like to allow DDNS but restrict it to specific subnets and only allow the machines to update their 'A' records. Allow-updates will not get us the record restrictions we would need to implement this and it doesn't appear that update-policy has any understanding of subnet scoping. _ Nicholas Miller, ITS, University of Colorado at Boulder ___ 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: update-policy restricting to a subnet
Not to the list but just to you. I could imagine a system having multiple views defined with only one view that allows DDNS updates. The other views would be read-only. This wouldn't be pretty, but ... In this one view that allows DDNS, you wouldn't be restricted to ONLY A records. Users would still be able to set up other records too using DDNS. I have seen this were you have an internal network that you want to allow the users, client machines, to update the DNS information using DDNS. But if they carry their laptop home and connect to the Internet, they will still try and send a DDNS update to the DNS server but it is rejected by the server because it is not coming from an internal network address. (Define subnet and internal network any way you want.) Couldn't you have your DDNS updates come from your DHCP server rather than directly from the client machines? If you can trust your DHCP server to only do what you want, then you wouldn't have to worry about anything else updating your data. For example, if you were trying to manage the example.com domain and you were wanting to allow DDNS to create a record for x.example.com with the address of 192.168.1.10, then the DHCP server for the 192.168.1.0 network could be explicitly allowed to update the DNS data, but the clients on the network wouldn't have to be allowed. And, a client on the 192.168.2.0 network still wouldn't be able to update because they did not get their address from the DHCP server on the 192.168.1.0 network. Bill Larson Nicholas F Miller nicholas.mil...@colorado.edu said: I take it this is not possible using update-policy? _ Nicholas Miller, ITS, University of Colorado at Boulder On Sep 30, 2009, at 11:29 AM, Nicholas F Miller wrote: Is it possible to restrict user machines to only be able to update their 'A' records on a specific subnet? We would like to allow DDNS but restrict it to specific subnets and only allow the machines to update their 'A' records. Allow-updates will not get us the record restrictions we would need to implement this and it doesn't appear that update-policy has any understanding of subnet scoping. _ Nicholas Miller, ITS, University of Colorado at Boulder ___ 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 -- ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
SIBLING GLUE address records (A or AAAA)
Hi, In the following example, the authoritive server for zone .xx has configured the delegations of the zones example.xx and otherexample.xx: example.xx NS ns1.example.xx example.xx NS ns2.example.xx ns1.example.xx A 11.22.33.44 ns2.example.xx A 11.22.33.55 otherexample.xx NS ns3.example.xx otherexample.xx NS ns4.example.xx the bind report these messages: ns3.example.xx has no SIBLING GLUE address records (A or ) ns4.example.xx has no SIBLING GLUE address records (A or ) because the glue records are not configured in the zone .xx, for ns3.example.xx and ns4.example.xx Are these glue records requiered ? I understand that is not. Is this right ? Regards, -- Sergio R. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: SIBLING GLUE address records (A or AAAA)
I would imagine the answer will be that they aren't required but would be helpful. Since the parent .xx is delegating to the second-level domains, if you do glue for all four DNS servers you are preventing a remote DNS server from having to go to the servers for example.xx to get the A records for the DNS servers for otherexample.xx. On Mon, Oct 5, 2009 at 3:59 PM, Sergio Ramirez srami...@seciu.edu.uywrote: Hi, In the following example, the authoritive server for zone .xx has configured the delegations of the zones example.xx and otherexample.xx: example.xx NS ns1.example.xx example.xx NS ns2.example.xx ns1.example.xx A 11.22.33.44 ns2.example.xx A 11.22.33.55 otherexample.xx NS ns3.example.xx otherexample.xx NS ns4.example.xx the bind report these messages: ns3.example.xx has no SIBLING GLUE address records (A or ) ns4.example.xx has no SIBLING GLUE address records (A or ) because the glue records are not configured in the zone .xx, for ns3.example.xx and ns4.example.xx Are these glue records requiered ? I understand that is not. Is this right ? Regards, -- Sergio R. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- -Ben Croswell ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: SIBLING GLUE address records (A or AAAA)
Thanks for the answer Ben, I agree. But the problem is if the administrator of zone example.xx decides to change the ip address of the ns3.example.xx and ns4.example.xx, the glue records will be wrong. -- Sergio R. Ben Croswell escribió: I would imagine the answer will be that they aren't required but would be helpful. Since the parent .xx is delegating to the second-level domains, if you do glue for all four DNS servers you are preventing a remote DNS server from having to go to the servers for example.xx to get the A records for the DNS servers for otherexample.xx. On Mon, Oct 5, 2009 at 3:59 PM, Sergio Ramirez srami...@seciu.edu.uy mailto:srami...@seciu.edu.uy wrote: Hi, In the following example, the authoritive server for zone .xx has configured the delegations of the zones example.xx and otherexample.xx: example.xx NS ns1.example.xx example.xx NS ns2.example.xx ns1.example.xx A 11.22.33.44 ns2.example.xx A 11.22.33.55 otherexample.xx NS ns3.example.xx otherexample.xx NS ns4.example.xx the bind report these messages: ns3.example.xx has no SIBLING GLUE address records (A or ) ns4.example.xx has no SIBLING GLUE address records (A or ) because the glue records are not configured in the zone .xx, for ns3.example.xx and ns4.example.xx Are these glue records requiered ? I understand that is not. Is this right ? Regards, -- Sergio R. ___ bind-users mailing list bind-users@lists.isc.org mailto:bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- -Ben Croswell ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: SIBLING GLUE address records (A or AAAA)
Sergio Ramirez wrote: Thanks for the answer Ben, I agree. But the problem is if the administrator of zone example.xx decides to change the ip address of the ns3.example.xx and ns4.example.xx, the glue records will be wrong. That's why is usually a good idea to use nameservers under the domain name being registered, to allow the registry to request for the corresponding glue and add it to the parent zone. Kind Regards Sebastian Castro -- Sergio R. Ben Croswell escribió: I would imagine the answer will be that they aren't required but would be helpful. Since the parent .xx is delegating to the second-level domains, if you do glue for all four DNS servers you are preventing a remote DNS server from having to go to the servers for example.xx to get the A records for the DNS servers for otherexample.xx. On Mon, Oct 5, 2009 at 3:59 PM, Sergio Ramirez srami...@seciu.edu.uy mailto:srami...@seciu.edu.uy wrote: Hi, In the following example, the authoritive server for zone .xx has configured the delegations of the zones example.xx and otherexample.xx: example.xx NS ns1.example.xx example.xx NS ns2.example.xx ns1.example.xx A 11.22.33.44 ns2.example.xx A 11.22.33.55 otherexample.xx NS ns3.example.xx otherexample.xx NS ns4.example.xx the bind report these messages: ns3.example.xx has no SIBLING GLUE address records (A or ) ns4.example.xx has no SIBLING GLUE address records (A or ) because the glue records are not configured in the zone .xx, for ns3.example.xx and ns4.example.xx Are these glue records requiered ? I understand that is not. Is this right ? Regards, -- Sergio R. ___ bind-users mailing list bind-users@lists.isc.org mailto:bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- -Ben Croswell ___ 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: Bind, dnssec, udp fragmentation woes.
In message 1254502519.14277.16.ca...@dv6d4k1-u, Nicholas Wheeler writes: On Fri, 2009-10-02 at 13:22 +1000, Mark Andrews wrote: You really want to work out what is being blocked, EDNS?, responses bigger that 512 bytes? DNSSEC? fragmented responses? With a clean path all of these should succeed but only the last one won't have tc set. This does a plain DNS query, a EDNS query that limits the response to 512 bytes, a DNSSEC query that limits the response to 512 bytes, a DNSSEC query that limits the response to something that would not normally be fragmented but exceeds 512 bytes, a DNSSEC query that will normally be fragmented. =20 % dig soa se @192.36.133.107 +norec +ignore=20 % dig soa se @192.36.133.107 +norec +ignore +bufsize=3D512 The above two work, the below four do not work (connection timed out; no servers could be reached).=20 (note: I replaced se with my domain.tld, and the @ with my server). % dig dnskey se @192.36.133.107 +norec +ignore +bufsize=3D1200 % dig dnskey se @192.36.133.107 +norec +ignore +bufsize=3D512 +dnssec % dig dnskey se @192.36.133.107 +norec +ignore +bufsize=3D1200 +dnssec % dig dnskey se @192.36.133.107 +norec +ignore +bufsize=3D4096 +dnssec =20 Mark Thanks for the help, but I don't know what this implies, other than nothing dnssec-related with udp works ;) It means you have a device in the path that doesn't like UDP answer bigger that 512 bytes *and* also doesn't like having DO set. ; DiG 9.3.6-P1 dnskey se @192.36.133.107 +norec +ignore +bufsize=512 +dnssec ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 52624 ;; flags: qr aa tc ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;se.IN DNSKEY ;; Query time: 334 msec ;; SERVER: 192.36.133.107#53(192.36.133.107) ;; WHEN: Tue Oct 6 09:16:58 2009 ;; MSG SIZE rcvd: 31 Now what you need to do is use a packet sniffer to see which devices are blocking the queries/responses (there may be more than one). You may also want to talk to the manufactures first. They should be able to tell you how to configure your boxes to work correctly to support DNSSEC. As things are curently configured you won't get DNSSEC working. You may need to upgrade firmware or even replace some boxes. The IP330 was introduced in 1999 so it may not have firmware that handles DNSSEC properly. Mark Thanks, --=20 Nicholas Wheeler Systems Administrator Development Infostructure --=-4uanAoS33Xc7mxoOFN+w Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkrGMHQACgkQ8xWIEdi0CHEavwCdGACm3VOyfctcd/IfmiW2upIK Q2YAnAhSkPdnAgvPqzJg6Nzod4EKNuXc =//Z9 -END PGP SIGNATURE- --=-4uanAoS33Xc7mxoOFN+w-- --===2355657698356755570== Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users --===2355657698356755570==-- -- 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: SIBLING GLUE address records (A or AAAA)
In message hadipa$o6...@sepe.rau.edu.uy, Sergio Ramirez writes: Hi, In the following example, the authoritive server for zone .xx has configured the delegations of the zones example.xx and otherexample.xx: example.xx NS ns1.example.xx example.xx NS ns2.example.xx ns1.example.xx A 11.22.33.44 ns2.example.xx A 11.22.33.55 otherexample.xx NS ns3.example.xx otherexample.xx NS ns4.example.xx the bind report these messages: ns3.example.xx has no SIBLING GLUE address records (A or ) ns4.example.xx has no SIBLING GLUE address records (A or ) because the glue records are not configured in the zone .xx, for ns3.example.xx and ns4.example.xx Are these glue records requiered ? I understand that is not. Is this right ? Regards, -- Sergio R. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users Whether SIBLING GLUE is needed or not depends on what other glue there is. Take this example. The sibling glue is required for the delegation to work. otherexample.xx NS ns3.example.xx otherexample.xx NS ns4.example.xx example.xx NS ns1.otherexample.xx example.xx NS ns2.otherexample.xx There are even more complicated examples that require out of zone glue to work. Working out which glue is accepted is a trade-off between being able to track down bad data and having a delegation work. Named accepts and returns glue that is under the parent. Bad glue is then traceable. 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
