Problems with resolving a local tld

[Robert Moskowitz]

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/AAAA/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?

[Mark Andrews]

In message <512E31CA...@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

[Robert Moskowitz]

On 02/27/2013 08:34 PM, Mark Andrews wrote:
> In message <512E31CA...@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.

[Matus UHLAR - fantomas]

>In message <512E31CA...@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.

[Robert Moskowitz]

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...@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.

[Doug Barton]

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

[Vernon Schryver]

> 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 Schryver v...@rhyolite.com

[Robert Moskowitz]

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...

[Tony Finch]

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.

[Vernon Schryver]

> 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 Schryver v...@rhyolite.com

[Robert Moskowitz]

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. ;)'

[Robert Moskowitz]

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.

[Robert Moskowitz]

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.

[Vernon Schryver]

> 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 Schryver v...@rhyolite.com

[Phil Mayers]

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.