Re: Problems with resolving a local tld
In message 512e31ca.5030...@htt-consult.com, Robert Moskowitz writes: For various testing reasons, I have been running a tld here of htt. It has worked of old and continues to work on my new 9.8.2 Centos servers. Problem came up from a namecaching server that 'forwards only' to my internal server. It cannot resolve any hosts in this tld and on the server forwarded to I see: On 28.02.13 12:34, Mark Andrews wrote: Well one really shouldn't be creating one's own tlds. I think we need private TLDs like we have multiple private IP ranges. There are cases where people just can not put their own domain anywhere in the DNS tree, because they simply do not have any domain seen in the public available (no company's domain, using multiple ISPs etc) -- 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. REALITY.SYS corrupted. Press any key to reboot Universe. ___ 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: Problems with resolving a local tld
Still not working even with htt. signed. See below. I guess what I need for right now is to turn off DNSSEC checking of a branch in the tree; in this case the tld htt. On 02/27/2013 08:34 PM, Mark Andrews wrote: In message 512e31ca.5030...@htt-consult.com, Robert Moskowitz writes: For various testing reasons, I have been running a tld here of htt. It has worked of old and continues to work on my new 9.8.2 Centos servers. Problem came up from a namecaching server that 'forwards only' to my internal server. It cannot resolve any hosts in this tld and on the server forwarded to I see: Well one really shouldn't be creating one's own tlds. As the instigator and a co-author of rfc 1918, I beg to differ. Many have been using internal tlds for decades for various reasons. It works fine for the client going to the servers of the zone, but my namecaching server that is forwarding to same DNS server fails. That said sign the zone and add a trust anchor (managed-keys/trusted-keys) for it. The validator won't ask the root zone for the DS records from the zone once you do that. So I cheated and used webmin for doing the signing, but it looks right: htt.INDNSKEY257 3 7 AwEAAfEIWjDoEesqC4NLAwNFgviq+IGbUFmnFn0/2L8UvLWMjYiGFETi NyA4CVaaG4GMekSJM8dI0FepyIKurxAhYzyV+phS5C6MoVmnYdF27dkP qS0pFDZ/Hpp25qTrKIUjcqvxgECP1ArXa7yyE7/xWzQjH9nk5gEnad6w Gy41lRnv3/UPtkxw669V2Ikb1NLAB5XnAzpTc4Tm7QPRPtbN8+FKWyYW Ie9/nYKf67vSrlwbxRFbb27GeEmnrqMtsLkSFP1zDoUbmgJs3yiVjFCD 8hRYlbOA9lgAMbOGm4tNsLOFx0vyBZEVtdh4l/YDAaklygtR+f60271X DHWaC4U/VYrHRidg2krM+UpPhjqn3aPJFIyyKEEE66cMSlf7ROL71w== htt.INDNSKEY256 3 7 AwEAAfH28LiEU7QxpCdeR6qB6sol8d3AUsKokil7nmCvT3yusSIF8iDR lWPEzs+BeTEVoQwhlEZZm6ZqvYEihxvR72mQLzS1r0GYzE/G4Kjs3oOq 1ro4vTlO6Nk9/i8/sxbpl9jgC/3T3cHs97Whq6+PvFLQPeFa3pNqhEWl NnHo7p47ddI5Y+XfTUmgEQjbPo36XqQQGIgFORT7G+tpB/LLd17P3F3O vYKsXGat7z8/86118HwcYtZQx5e1AaRWm+SKk5gbGDYvATt/hGB883oz hI6umyVhWSXTiDolEnWf2L89cedda0hf8EGKIeCjJPKAbhjgp00sPDvF gEwnJ4xw29MIM9DgfDIaHZ0xXRNd1QQjKAqY5yseq9m8JobnoEPZdw== htt.43200INRRSIGDNSKEY 7 1 43200 20130330032518 20130228032518 63362 htt. 1tmMcjfjyt9dy5ERAHRHgps2udBGJyJ1hVcz Hpctu1Y8TONfrjuqGcACRPpE0cHUTRSxqxZ7 WyseCQxvApd7NH93swcCKplls485p40pKLn8 7VLExwW4H76VmuBhO/IXVYaYQHDgw9fOcwRN 91eSzM6qjvQZX4yNR8ErFYGrQzGX/NBvAz5K ngGa1a3UO33QSZJ0NA5lv9NzBp1bNxAdSjpv mAsE7xjnMFfQgxAixbyalCIJ/adrt2OScaRt gx6i/42u9B1Uni2OKVlyQ3fuWU2BqpAR3QXv 8r89Zl7CdB/F0Jepdi2wi2hh/XqcOEf+Ef6i HSROR2Bo/X8ILlirM5ZA1u3aVAXqB6bxqDv1 H5FYFPZocuxF4Glcc//XzQvu htt.43200INRRSIGDNSKEY 7 1 43200 20130330032518 20130228032518 1470 htt. o7PY4emvDvdoYjSyXh1zsDLshKt9p+3N6TNt YX93emC8vVhZtU1GozQ51E6tCucnOro+Z8DR WK2xyDdBFABTfwJne8duVmclzuQnvC87ocYB lNq5v1SRta0IBkTras4wYNRn29J5bTUumfv/ Q4MPl4QAqZzOTQ+LAjAfqFqnbKb3OFktSrUL G/OoUfAyv8gku4eR+CU1I4TAtJOzAQl8h1yu XIhph60EI2351nGHo6HAFGcIPyDYKIzKu4jg gD9NJSQoJtsKP+Yddn4864ZPVT/PbRIbu26E Qumvn0eYrbD8Mn7Wjbvhz9SlZLds4nuG2O/P E3rxW7L7OIkksPkCGAgbA8jmLlc7e7jbnzk9 mUpxI1CYerpfkYmeszrHilzg Q4K4G6TITMCM3TJSB7N55OLQ9I5274S7.htt.7200INNSEC31 0 10 - SK60GBPTP3OUAO9NB0GRASPVOGOJDI1M A NS SOA RRSIG DNSKEY NSEC3PARAM I have hosts directly in this zone (as well as subzones). So medon.htt. is defined as: medon.htt.IN2607:f4b8:3:1:2b0:d0ff:feb1:b82d medon.htt.INA208.83.67.154 medon.htt.43200INRRSIGA 7 2 43200 20130330032518 20130228032518 63362 htt. slcOa3AKixrntI+OSpbYKuSXJLy5ECL5X7ky ODm9PZ7UoDXCOsl6Pn6wC4Q/eOYk5wy8yqqW IT3J6iM9K5QkR+mKe7FCpWsz2lY+eJTY0gKV Y/r/KFByGxsYtY6/zMYcR6S0f9sVCe81kaLA 8Jo/2XZJQVrEJatbXCgDB1M2qHiwMwJ7SrGY /h29OHkZNUmiD9+mcU1V31492OVLRvj/kht5 fKVsGOLMdhqi3RjpSC6inTHhIMQO8wU5B0aV ZMqQBg07Rhn78wlRJ8e1KU9yVz+CoRkVogzR QS4TzKgqGN6ekKYHDiWAnRvaCpYdeZoEg/bh q4eiKNXLWUPEDxdmyLRwc1hSjxzVomsJ/GUh fdyNvBOQn8/ebAiUZhTgO7GT medon.htt.43200INRRSIG 7 2 43200 20130330032518 20130228032518 63362 htt. FQShruERtC/WxILDeeQyFhX6cFRm7nHoFeb8 q8gIhaIexF8tZ38JP5GqSclcxn4wyN02AAzz WY9S1OCpVV/F6AtYKhDyutb6HJ6pUcnIivYh BO/uJ3blKFrMLbN6xklKv7LIXa1NHgscd9Cj 6MHdao9RLrJIcVOV0lSLQU+8ciXX0rWFliop ZMT+2IQ3AxcPw9f20W6SMHrR5f5adnnwvH2W KmGie6jq6p+e3f2oae+sem/EzYcKfFFzsrKN uTX7LAz3DKUxoJynfLbBvk72AS/RsSq3sB8/ mhp65POqUgSrBn+pWw/pl2aykZIXrlBO4reW 4LU20l06RkBkjb7xGZYzC3izR3+UPd0wIspw 0tZ8wPW59+5x4mWvav8V3dVb When I do 'host medon.htt.' on my DNS server, rigel, it works. When I go over to the namecaching server, kovia, it fails: Host medon.htt not found: 2(SERVFAIL) Feb 28 12:14:16 rigel named[786]: error (chase DS servers) resolving 'htt/DS/IN': 208.83.67.188#53 Feb 28 12:14:16 klovia named[22332]: validating @0xb421ba30: htt SOA: got insecure response; parent indicates it should be secure Feb 28 12:14:16 klovia named[22332]: error (no valid RRSIG) resolving 'medon.htt/DS/IN': 208.83.67.188#53 Feb 28 12:14:16 klovia named[22332]: validating @0xb421ba30: htt SOA: got insecure response; parent
Re: Problems with resolving a local tld
On 02/28/2013 09:34 AM, Robert Moskowitz wrote: Only for my internal tld does the lookup fail. Are you distributing the trust anchor for htt to all of the servers that are doing validation? Doug ___ 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: Problems with resolving a local tld
From: Robert Moskowitz r...@htt-consult.com Well one really shouldn't be creating one's own tlds. As the instigator and a co-author of rfc 1918, I beg to differ. Many people considered the notion in RFC 1918 harmful. See RFC 1627. (My personal view was that standardizing the notion was better because it would minimize the harm suffered and caused by those who were going to use net-10 no matter what the other self-described experts, mavens, and gurus said.) Many have been using internal tlds for decades for various reasons. It works fine for the client going to the servers of the zone, but my namecaching server that is forwarding to same DNS server fails. Many things have worked fine for decades, are popular, and are even both popular and old. Many of those old and popular things cause significant harm to their perpetrators and to others and are just plain stupid in almost all of their existing installations, such as not following BCP 38 or running open DNS resolvers. In other words, what does your private htt TLD do that could not be done at least as well as a private, secret sub-domain of one of your legitimate domains? Vernon Schryverv...@rhyolite.com ___ 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: Problems with resolving a local tld
On 02/28/2013 12:37 PM, Doug Barton wrote: On 02/28/2013 09:34 AM, Robert Moskowitz wrote: Only for my internal tld does the lookup fail. Are you distributing the trust anchor for htt to all of the servers that are doing validation? No. Of course I did not think of that! I just ASSuMEd a namecaching server would get all it needed from the forward server. Well let's figure out which of these records I need to move... ___ 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: Problems with resolving a local tld
Robert Moskowitz r...@htt-consult.com wrote: Feb 28 12:14:16 klovia named[22332]: validating @0xb421ba30: htt SOA: got insecure response; parent indicates it should be secure I think this suggests that one of the servers for htt doesn't have the signed version. Another reason not to use made-up domain names: CAs are going to stop issuing X.509 certificates for them. (It baffles me why they ever did so.) http://ssl.entrust.net/blog/?p=1831 Tony. -- f.anthony.n.finch d...@dotat.at http://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: Problems with resolving a local tld
From: Tony Finch d...@dotat.at Another reason not to use made-up domain names: CAs are going to stop issuing X.509 certificates for them. (It baffles me why they ever did so.) http://ssl.entrust.net/blog/?p=1831 That's another reason to publish your own DANE records including TLSA and SMIMEA. Also consider this comment in that announcement: This issue is particularly a problem with Microsoft Exchange users where non-FQDN names are used frequently I wish that would be enough to get Microsoft to teach Exchange to use DANE. Why am I not surprised to see that the recommended solutions of https://www.cabforum.org/Guidance-Deprecated-Internal-Names.pdf linked from that Entrust.net web page mentions DANE or DNSSEC not at all but does include some less plausible solutions? Vernon Schryverv...@rhyolite.com ___ 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: Problems with resolving a local tld
On 02/28/2013 12:57 PM, Vernon Schryver wrote: From: Robert Moskowitz r...@htt-consult.com Well one really shouldn't be creating one's own tlds. As the instigator and a co-author of rfc 1918, I beg to differ. Many people considered the notion in RFC 1918 harmful. See RFC 1627. Um, I lived that debate. RFC 1597 came first. Then there was 1627. Then the IAB called for an armistice and the gang of 4 got together with the gang of 4 and produced 1918. Postel claimed with a straight face that that number just happened to be next. Yeah right Jon; read RFC 2468... (My personal view was that standardizing the notion was better because it would minimize the harm suffered and caused by those who were going to use net-10 no matter what the other self-described experts, mavens, and gurus said.) In many ways it was bad for the internet. But is your cup half full or half empty? IPv6 thus has not been rushed and we have taken time to hopefully get it right. I wonder what situation we would have been in if we did not have registered private addresses and we had free for all address food fights and a rush for IPv6? Well this is about bind and not about IP addressing... Oh, and don't get me going on EIDs. Noel 'said' he was upset that I caved in first during the EID cabal effort. Many have been using internal tlds for decades for various reasons. It works fine for the client going to the servers of the zone, but my namecaching server that is forwarding to same DNS server fails. Many things have worked fine for decades, are popular, and are even both popular and old. Many of those old and popular things cause significant harm to their perpetrators and to others and are just plain stupid in almost all of their existing installations, such as not following BCP 38 or running open DNS resolvers. Moving to views for my DNS was such a pain, and I was grateful in the end to get there. CIDR reverse in-addr.arpa allocations such a pain, and worth getting right (and I found a few errata in Liu's book along the way). Now if I can only get my ISP to delegate my ipv6.arpa subzone, I would be happier. We live and learn to be better. Hopefully. In other words, what does your private htt TLD do that could not be done at least as well as a private, secret sub-domain of one of your legitimate domains? First it was a particular product that wanted to run in its own zone with its own dns server that I had to access from other systems; last version of it will be gone soon. Then it was a portable test lab that could work plugged in or isolated. Really now I could force things to work as a subzone; or at least I think I am nearly to that point in the upgrades. But there are some human interaction reasons for a very short fqdn for a class of testing. It has to be typed in real fast in a mobility demonstration, and it is the convenience factor for doing some testing. So it is just for testing, and if I can't get it working to this server, it will probably be OK; it works on the main server. After I complete the whole grumble grumble network upgrade. But it is PHUN! I can have my own special tld for MY use in MY network! All these stupid security layers just take the phun out of it. ;)' ___ 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: Problems with resolving a local tld
On 02/28/2013 01:14 PM, Tony Finch wrote: Robert Moskowitz r...@htt-consult.com wrote: Feb 28 12:14:16 klovia named[22332]: validating @0xb421ba30: htt SOA: got insecure response; parent indicates it should be secure I think this suggests that one of the servers for htt doesn't have the signed version. Another reason not to use made-up domain names: CAs are going to stop issuing X.509 certificates for them. (It baffles me why they ever did so.) http://ssl.entrust.net/blog/?p=1831 Day job disclaimer: I work for Verizon Enterprise Systems. We have a group that provides LOTS of server certs and is the leader in client certs and attend HIMSS next week for more announcements. But that said my personal position is: a made-up domain name should never leak, and thus why are you getting a public cert for it? run your own CA, add it to your trusted list and do what you got to do. As to why they did so? It is called money. But this is a different subject. Enough down this rat hole. ___ 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: Problems with resolving a local tld
On 02/28/2013 01:31 PM, Vernon Schryver wrote: From: Tony Finch d...@dotat.at Another reason not to use made-up domain names: CAs are going to stop issuing X.509 certificates for them. (It baffles me why they ever did so.) http://ssl.entrust.net/blog/?p=1831 That's another reason to publish your own DANE records including TLSA and SMIMEA. I have been on a thread over on the postfix list where DANE support and such is being discussed. Will get there eventually. Also consider this comment in that announcement: This issue is particularly a problem with Microsoft Exchange users where non-FQDN names are used frequently I wish that would be enough to get Microsoft to teach Exchange to use DANE. Why am I not surprised to see that the recommended solutions of https://www.cabforum.org/Guidance-Deprecated-Internal-Names.pdf linked from that Entrust.net web page mentions DANE or DNSSEC not at all but does include some less plausible solutions? ___ 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: Problems with resolving a local tld
From: Robert Moskowitz r...@htt-consult.com could work plugged in or isolated. Really now I could force things to work as a subzone; or at least I think I am nearly to that point in the upgrades. But there are some human interaction reasons for a very short fqdn for a class of testing. It has to be typed in real fast in a mobility demonstration, and it is the convenience factor for doing some testing. So it is just for testing, and if I can't get it working to With search lists in /etc/resolv.conf (and the Windows equivalent) or checking /etc/hosts (and the Windows equivalent) before DNS (while ignoring the DNS ubber alles crowds), what is the problem with short local names? I often use short names inside my network. Vernon Schryverv...@rhyolite.com ___ 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: Problems with resolving a local tld
Our experience has been they break, unexpectedly and in hard to troubleshoot ways. FQDN for the win! Vernon Schryver v...@rhyolite.com wrote: With search lists in /etc/resolv.conf (and the Windows equivalent) or checking /etc/hosts (and the Windows equivalent) before DNS (while ignoring the DNS ubber alles crowds), what is the problem with short local names? I often use short names inside my network. -- Sent from my mobile device, please excuse brevity and typos. ___ 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
Problems with resolving a local tld
For various testing reasons, I have been running a tld here of htt. It has worked of old and continues to work on my new 9.8.2 Centos servers. Problem came up from a namecaching server that 'forwards only' to my internal server. It cannot resolve any hosts in this tld and on the server forwarded to I see: htt. is mastered on my servers and home.htt is slaved off of old server (that will get upgraded later). The host I want to access is repo.home.htt. From my 'regular' DNS servers this works well, but from the namecaching server that 'forwards only' to this server I get on the caching server: Feb 27 09:52:48 klovia named[1703]: error (insecurity proof failed) resolving 'repo.home.htt//IN': 208.83.67.188#53 Feb 27 09:52:48 klovia named[1703]: error (insecurity proof failed) resolving 'repo.home.htt/A/IN': 208.83.67.188#53 and on the main server (at 208.83.67.188) I see: Feb 27 09:52:47 rigel named[9294]: error (chase DS servers) resolving 'htt/DS/IN': 208.83.67.188#53 what little research I have done directs me to htt is not signed? Of course home.htt is not either as that server is rather old (bind 9.6.2) Interestingly when 208.83.67.188 does a lookup in my regular domain I see: Feb 27 11:16:14 rigel named[9294]: error (chase DS servers) resolving 'htt-consult.com/DS/IN': 208.83.67.188#53 So what am I missing here? ___ 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: Problems with resolving a local tld
In message 512e31ca.5030...@htt-consult.com, Robert Moskowitz writes: For various testing reasons, I have been running a tld here of htt. It has worked of old and continues to work on my new 9.8.2 Centos servers. Problem came up from a namecaching server that 'forwards only' to my internal server. It cannot resolve any hosts in this tld and on the server forwarded to I see: Well one really shouldn't be creating one's own tlds. That said sign the zone and add a trust anchor (managed-keys/trusted-keys) for it. The validator won't ask the root zone for the DS records from the zone once you do that. Anything from 9.3.0 onwards can sign modern ones. If you want NSEC3 the 9.6.0 onwards. Feb 27 11:16:14 rigel named[9294]: error (chase DS servers) resolving 'htt-consult.com/DS/IN': 208.83.67.188#53 Something not fully dnssec aware in the resolution path? 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: Problems with resolving a local tld
On 02/27/2013 08:34 PM, Mark Andrews wrote: In message 512e31ca.5030...@htt-consult.com, Robert Moskowitz writes: For various testing reasons, I have been running a tld here of htt. It has worked of old and continues to work on my new 9.8.2 Centos servers. Problem came up from a namecaching server that 'forwards only' to my internal server. It cannot resolve any hosts in this tld and on the server forwarded to I see: Well one really shouldn't be creating one's own tlds. That said sign the zone and add a trust anchor (managed-keys/trusted-keys) for it. The validator won't ask the root zone for the DS records from the zone once you do that. So I get to dive into zone signing slightly before I wanted to. Well time to get my feet wet! Anything from 9.3.0 onwards can sign modern ones. If you want NSEC3 the 9.6.0 onwards. The 9.6.2 server has a bunch of cruft on it that makes it hard to muck with. It is scheduled for replacement as well, but it is last on the list. Maybe just signing the tld will 'fix' this for now. Feb 27 11:16:14 rigel named[9294]: error (chase DS servers) resolving 'htt-consult.com/DS/IN': 208.83.67.188#53 Something not fully dnssec aware in the resolution path? Probably. NetSol is my registry... Time to unlock it and move it. ___ 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
