Re: Strange CNAME issue
Thanks for your response. I didn't know about the +trace option in dig. After some more searching, I believe you are correct about the long responses being related. The responses that fail all seem to exceed 512-bytes. Why this would happen in multiple locations is a mystery but perhaps our firewalls are configured similarly. I'll look into the firewall settings on my end, but since there may be other devices out there configured similarly I'll need to try and reduce my CNAMES to find into a 512-byte response or switch them to A records. -seren On Jan 20, 2010, at 1:48 AM, Niall O'Reilly wrote: seren wrote: Hi, I've run into some strange issues with BIND and CNAMES. The examples you show indicate strange issues only with whatever name server code is running on your localhost. Nothing in your examples actually identify this as BIND. We're using BIND9 (on Ubuntu) internally and have our external DNS hosted by NetworkSolutions. Occasionally I'll be able to create a CNAME in NetworkSolutions that BIND is unable to resolve. Using dig I notice it's doing a query for an A record, This is the record type use by dig in default of a specific type on the command line. and in most cases this works even if the entry is a CNAME. In the cases where it fails, I see either a timeout error or a SERVFAIL. Your local instance of named is respectively either not responding, or reporting an error. Have you looked in your logs for more information? Have you tried 'dig +trace'? If I then do a dig query specifying a CNAME, I get a quick successful result and subsequent queries to BIND succeed, until the record expires from the cache. The records that fail don't seem to have anything in common besides them all being CNAMES and longer names seeming to fail more. Both BIND9 and two windows-based DNS servers fail with the exact same records, however Google (8.8.8.8) and several other public DNS services resolve them fine. I think you need to ask what's different between (on the one hand) your BIND9 and windows-based name servers and (on the other) name servers which you tell us work: if not in the configuration, then in the environment. Are all of your failing name servers behind the same firewall? If so, does the firewall allow DNS queries and responses over TCP as well as UDP? Does the firewall perhaps break long responses? I ask because I've noticed some truncation and fallback to TCP when I use 'dig +trace' to query for one of the names you've mentioned as failing. Best regards, Niall O'Reilly University College Dublin IT Services ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Strange CNAME issue
In message a9981203-ca2a-4ba2-b95b-08d992178...@mellmo.com, seren writes: Thanks for your response. I didn't know about the +trace option in dig. = After some more searching, I believe you are correct about the long = responses being related. The responses that fail all seem to exceed = 512-bytes. Why this would happen in multiple locations is a mystery but = perhaps our firewalls are configured similarly. I'll look into the = firewall settings on my end, but since there may be other devices out = there configured similarly I'll need to try and reduce my CNAMES to find = into a 512-byte response or switch them to A records. -seren Some filewall vendors / operators think that all UDP DNS responses are = 512 bytes of payload. This has not be the case offically for over a decade now with EDNS, and was never one in practice as there have always been servers that sent larger responses as long as I've been working with DNS, ~20 years now. Some filewall vendors / operators think that TCP DNS is only used for AXFR. This has *never* been the case. One or both of these may be the problem. 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
Re: Strange CNAME issue
seren wrote: Hi, I've run into some strange issues with BIND and CNAMES. The examples you show indicate strange issues only with whatever name server code is running on your localhost. Nothing in your examples actually identify this as BIND. We're using BIND9 (on Ubuntu) internally and have our external DNS hosted by NetworkSolutions. Occasionally I'll be able to create a CNAME in NetworkSolutions that BIND is unable to resolve. Using dig I notice it's doing a query for an A record, This is the record type use by dig in default of a specific type on the command line. and in most cases this works even if the entry is a CNAME. In the cases where it fails, I see either a timeout error or a SERVFAIL. Your local instance of named is respectively either not responding, or reporting an error. Have you looked in your logs for more information? Have you tried 'dig +trace'? If I then do a dig query specifying a CNAME, I get a quick successful result and subsequent queries to BIND succeed, until the record expires from the cache. The records that fail don't seem to have anything in common besides them all being CNAMES and longer names seeming to fail more. Both BIND9 and two windows-based DNS servers fail with the exact same records, however Google (8.8.8.8) and several other public DNS services resolve them fine. I think you need to ask what's different between (on the one hand) your BIND9 and windows-based name servers and (on the other) name servers which you tell us work: if not in the configuration, then in the environment. Are all of your failing name servers behind the same firewall? If so, does the firewall allow DNS queries and responses over TCP as well as UDP? Does the firewall perhaps break long responses? I ask because I've noticed some truncation and fallback to TCP when I use 'dig +trace' to query for one of the names you've mentioned as failing. Best regards, Niall O'Reilly University College Dublin IT Services ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
