Problems with resolving a local tld
Robert Moskowitz
rgm at htt-consult.com
Thu Feb 28 17:34:29 UTC 2013
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.5030001 at 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. IN DNSKEY 257 3 7
AwEAAfEIWjDoEesqC4NLAwNFgviq+IGbUFmnFn0/2L8UvLWMjYiGFETi
NyA4CVaaG4GMekSJM8dI0FepyIKurxAhYzyV+phS5C6MoVmnYdF27dkP
qS0pFDZ/Hpp25qTrKIUjcqvxgECP1ArXa7yyE7/xWzQjH9nk5gEnad6w
Gy41lRnv3/UPtkxw669V2Ikb1NLAB5XnAzpTc4Tm7QPRPtbN8+FKWyYW
Ie9/nYKf67vSrlwbxRFbb27GeEmnrqMtsLkSFP1zDoUbmgJs3yiVjFCD
8hRYlbOA9lgAMbOGm4tNsLOFx0vyBZEVtdh4l/YDAaklygtR+f60271X
DHWaC4U/VYrHRidg2krM+UpPhjqn3aPJFIyyKEEE66cMSlf7ROL71w==
htt. IN DNSKEY 256 3 7
AwEAAfH28LiEU7QxpCdeR6qB6sol8d3AUsKokil7nmCvT3yusSIF8iDR
lWPEzs+BeTEVoQwhlEZZm6ZqvYEihxvR72mQLzS1r0GYzE/G4Kjs3oOq
1ro4vTlO6Nk9/i8/sxbpl9jgC/3T3cHs97Whq6+PvFLQPeFa3pNqhEWl
NnHo7p47ddI5Y+XfTUmgEQjbPo36XqQQGIgFORT7G+tpB/LLd17P3F3O
vYKsXGat7z8/86118HwcYtZQx5e1AaRWm+SKk5gbGDYvATt/hGB883oz
hI6umyVhWSXTiDolEnWf2L89cedda0hf8EGKIeCjJPKAbhjgp00sPDvF
gEwnJ4xw29MIM9DgfDIaHZ0xXRNd1QQjKAqY5yseq9m8JobnoEPZdw==
htt. 43200 IN RRSIG DNSKEY 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. 43200 IN RRSIG DNSKEY 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. 7200 IN NSEC3 1 0 10 -
SK60GBPTP3OUAO9NB0GRASPVOGOJDI1M A NS SOA AAAA RRSIG DNSKEY NSEC3PARAM
I have hosts directly in this zone (as well as subzones). So medon.htt.
is defined as:
medon.htt. IN AAAA 2607:f4b8:3:1:2b0:d0ff:feb1:b82d
medon.htt. IN A 208.83.67.154
medon.htt. 43200 IN RRSIG A 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. 43200 IN RRSIG AAAA 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 indicates it should be secure
Feb 28 12:14:16 klovia named[22332]: error (no valid RRSIG) resolving
'medon.htt/DS/IN': 2607:f4b8:3:3:9254:5400:0:188#53
Feb 28 12:14:16 klovia named[22332]: error (no valid DS) resolving
'medon.htt/A/IN': 208.83.67.188#53
Feb 28 12:14:16 klovia named[22332]: validating @0xb4208b60: medon.htt
A: bad cache hit (medon.htt/DS)
Feb 28 12:14:16 klovia named[22332]: error (broken trust chain)
resolving 'medon.htt/A/IN': 2607:f4b8:3:3:9254:5400:0:188#53
Feb 28 12:14:16 klovia named[22332]: validating @0xb4208b60: medon.htt
A: bad cache hit (medon.htt/DS)
Feb 28 12:14:16 klovia named[22332]: error (broken trust chain)
resolving 'medon.htt/A/IN': 2607:f4b8:3:3:9254:5400:0:188#53
Feb 28 12:14:16 klovia named[22332]: validating @0xb4208b60: medon.htt
A: bad cache hit (medon.htt/DS)
Feb 28 12:14:16 klovia named[22332]: error (broken trust chain)
resolving 'medon.htt/A/IN': 2607:f4b8:3:3:9254:5400:0:188#53
Feb 28 12:14:16 klovia named[22332]: validating @0xb4208b60: medon.htt
A: bad cache hit (medon.htt/DS)
Feb 28 12:14:16 klovia named[22332]: error (broken trust chain)
resolving 'medon.htt/A/IN': 2607:f4b8:3:3:9254:5400:0:188#53
>
> 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?
For any zone in .com that I master on rigel, a lookup of a host in said
zone from klovia generates this message, but I still get back a valid
response. Only for my internal tld does the lookup fail.
More information about the bind-users
mailing list