Subject: [dnsext] Name equivalence: No protocol change solution

From: Kazunori Fujiwara <[email-masked]>
Date: Fri, 10 Sep 2010 00:37:41 +0900 (JST)

The problems of BNAME and DNAME+CNAME come from co-existence of both
CNAME and BNAME/DNAME RR in an owner name.

If we introduce signaling for BNAME/DNAME+CNAME, new alias algorithm
numbers for DNSSEC are required to support DNSSEC with BNAME/DNAME+CNAME.

Then, I propose another solution for name equivalence.
Consider new DNS server which synthesize CNAME RR without BNAME/DNAME.

I introduce new pseudo RR "SNAME" which format is same as DNAME in an
input zone file. TARGET may be in same zone.
SNAME is pseudo, it does not appear in DNS protocol.

    OWNERNAME   IN   SNAME   TARGET
    TARGET      IN   NS ...
                IN   DS ...

New DNS Server answers are:

    QNAME            |          Answer
    -----------------+----------------
    OWNERNAME        |     OWNERNAME     IN CNAME TARGET
    SUB.OWNERNAME    |     SUB.OWNERNAME IN CNAME SUB.TARGET
    SUB.TARGET       |     TARGET IN NS + TARGET IN DS
    TARGET           |     TARGET IN NS + TARGET IN DS
    ...

We can sign synthesized CNAME RR using RFC 4470.
It does not need new algorithm numbers.

I wrote DNS server prototype which support NS+DS+SNAME+DNSSEC.
Only gTLD style zone is supported.

  my DNS server code is:    http://member.wide.ad.jp/~fujiwara/SNAME.pl
  Sorry, no manual.
  It requires perl and Net::DNS::SEC.

Programming takes a few hours (8 hours?) for me from v6rev.pl.

If you want production quality, you should write your programs in C or C++.

I run it in my companies server.

  TLD:      sname.dnslab.jp
  TARGET:   secure.sname.dnslab.jp
  Variants: variant[123].sname.dnslab.jp

  You can query:  (for example)
    secure.sname.dnslab.jp A/DS/NSEC
    www.variant1.sname.dnslab.jp A
    ns.variant2.sname.dnslab.jp A
    variant3.sname.dnslab.jp A/NS

dnslab.jp is registered in ISC DLV.
sname.dnslab.jp and secure.sname.dnslab.jp are signed and have chain of trust.
You can test DNSSEC via ISC DLV.

But current version may not support proof of non-existence.
# I will fix.

Please test my implementation.
It does not change DNS protocol.

If implimentations solve requirements, we should implement !!

Configuration is:
  ------------------------------------------
  server_address: 203.178.129.38
  server_port: 53
  pid_file: /var/run/SNAME.pid
  debug: 0
  reconfig_interval: 3600
  keyfile_dir: SNAME.key
  ttl: 900
  nsname: ns.sname.dnslab.jp
  forward_domainname: sname.dnslab.jp
  zone_file: SNAME.zone
  enable_dnssec: 1
  querylog: 1
  ------------------------------------------

Zone data file is:
  ------------------------------------------
  #
  secure.sname.dnslab.jp. NS ns.secure.sname.dnslab.jp.
  secure.sname.dnslab.jp. DS 26197 8 2 5F0878B02D7B59064F99C7697BBCD2B198B1ACDE648A48A98AAC8FBFF66B72CA
  ns.secure.sname.dnslab.jp. A 61.192.162.73
  #
  variant1.sname.dnslab.jp. SNAME secure.sname.dnslab.jp.
  variant2.sname.dnslab.jp. SNAME secure.sname.dnslab.jp.
  variant3.sname.dnslab.jp. SNAME secure.sname.dnslab.jp.
  ------------------------------------------

--
Kazunori Fujiwara, JPRS

---

From: Alex Bligh <[email-masked]>
Date: Thu, 09 Sep 2010 17:24:47 +0100

--On 10 September 2010 00:37:41 +0900 Kazunori Fujiwara 
<[email-masked]> wrote:

> New DNS Server answers are:

I think you are not synthesizing NS/DS records or DNAME
records for OWNERNAME (the 'copy'). The only NS/DS returned
are for TARGET. You are synthesizing a CNAME for
SUB.OWNERNAME and SUB1.SUB2.OWNERNAME even if SUB (in TARGET)
would be beyond a zone cut.

If I am right about this, and OWNERNAME and TARGET are TLDs,
doesn't that mean that the TLD operator running OWNERNAME
will have to do RFC4470 online signing for every query of
every domain name within the OWNERNAME TLD? To put it mildly,
that would be a large increase in DNS traffic, and very expensive
DNS traffic at that given the online signing requirement.

You did give me an idea though (see next message).

-- 
Alex Bligh

---

From: [email-masked]
Date: Mon, 13 Sep 2010 20:23:32 +0900 (JST)

My idea's advantages are:
    no protocol changes
    no resolver/validator changes
    no authoritative server changes
        except servers which hosts SNAME synthesis.

My idea's disadvantage is that a TLD which want to synthesize variants 
need to develop new DNS server software and it uses online signing.

If someone interests my idea, let's write internet draft with me.

I missed examples of my program.

# TLD= sname.dnslab.jp
# Registared domain name is "secure.$TLD"
# Variants are              "variant1.$TLD", "variant2.$TLD", "variant3.$TLD"
# Authoritative DNS Server is "snamens.dnslab.jp" [203.178.129.38]

1. Querying variant name for authoritative DNS server:

% dig @203.178.129.38 variant1.sname.dnslab.jp A
  returns 
;; ANSWER SECTION:
variant1.sname.dnslab.jp. 900	IN	CNAME	secure.sname.dnslab.jp.

% dig @203.178.129.38 variant1.sname.dnslab.jp A +dnssec
  returns 
;; ANSWER SECTION:
variant1.sname.dnslab.jp. 900	IN	CNAME	secure.sname.dnslab.jp.
variant1.sname.dnslab.jp. 900	IN	RRSIG	CNAME 8 4 900 20101013105101 20100913105101 63840 sname.dnslab.jp. Heh+YDhaE44mXsspBeB73SX1YpI7SYZGO+3fuKQB2UGeRWEHOHR1xbPK xAyP5c13IgfGj0sPfpc9j/XmNNOHhfAS1wxPDBjz7+lywpa69h/8BJwd 5/ZzUw+X33TUgImKupb4t7Sq2NPgrX3vZs+9/4bjqKeEGFHvxH4jBtNM Gtw=

;; AUTHORITY SECTION:
variant1.sname.dnslab.jp. 900	IN	NSEC	\000.variant1.sname.dnslab.jp. CNAME
variant1.sname.dnslab.jp. 900	IN	RRSIG	NSEC 8 4 900 20101013105101 20100913105101 63840 sname.dnslab.jp. ftgpYus+o9c0vSuBy4TM/UKe+fPXmhvhVZ8SO/KKmBr0x6GRnqK2WqZ2 BUKUCZTa/1d6D6ZsarRvJd5XZ13z9gcUNWc+7FCgQy09mGB5kD66i3YV BbGsjSgajVPxd0yBQSauxv+ECJzlCkJvpE5Uq7CUtnnWcf0r0XlqC8Qx 2Jo=

% dig @203.178.129.38 www.variant1.sname.dnslab.jp A
  returns 
;; ANSWER SECTION:
www.variant1.sname.dnslab.jp. 900 IN	CNAME	www.secure.sname.dnslab.jp.

% dig @203.178.129.38 www.variant1.sname.dnslab.jp A +dnssec
  returns 
;; ANSWER SECTION:
www.variant1.sname.dnslab.jp. 900 IN	CNAME	www.secure.sname.dnslab.jp.
www.variant1.sname.dnslab.jp. 900 IN	RRSIG	CNAME 8 5 900 20101013105148 20100913105148 63840 sname.dnslab.jp. Up3A7TbL38tlf+8Dxmwr8KAWN7ZbO54hw1sxFZuUak6hQ7mJKx3VfgVo //nigNSdhsIlvXtmVd6U26uN8JQei8PSmR3S/NM4fE1m6mFzjlDI4PCl pPmn6KvxmAdP5iNdzA8jk8VcNmZj75MZ/IGvf+HsRCFY9nogwjX/xlI8 18k=

;; AUTHORITY SECTION:
www.variant1.sname.dnslab.jp. 900 IN	NSEC	\000.www.variant1.sname.dnslab.jp. CNAME
www.variant1.sname.dnslab.jp. 900 IN	RRSIG	NSEC 8 5 900 20101013105148 20100913105148 63840 sname.dnslab.jp. PkKv5lbH2yWaS3Xt7LOpoRhlEDgVYyH87+TCx9wjmK3dX1j2xNJ5qBaN 4rfnB4SY8Sv8KzvzCa24ukuG3Au1h5NZG03k2OQG8gp6LFRaIm2Rr6WZ zt97xuGJfXuttyRMtfkz0JXFTS6E+KCF4DvXYo4nR5KTWaXA8i8yHJSK Cuw=

2. Querying for normal delegation

% dig @203.178.129.38 www.secure.sname.dnslab.jp

;; AUTHORITY SECTION:
secure.sname.dnslab.jp.	900	IN	NS	ns.secure.sname.dnslab.jp.
secure.sname.dnslab.jp.	900	IN	DS	26197 8 2 5F0878B02D7B59064F99C7697BBCD2B198B1ACDE648A48A98AAC8FBF F66B72CA

;; ADDITIONAL SECTION:
ns.secure.sname.dnslab.jp. 900	IN	A	61.192.162.73

# !! It returns DS without DO bit !!

% dig @203.178.129.38 www.secure.sname.dnslab.jp +dnssec

;; AUTHORITY SECTION:
secure.sname.dnslab.jp.	900	IN	NS	ns.secure.sname.dnslab.jp.
secure.sname.dnslab.jp.	900	IN	DS	26197 8 2 5F0878B02D7B59064F99C7697BBCD2B198B1ACDE648A48A98AAC8FBF F66B72CA
secure.sname.dnslab.jp.	900	IN	NSEC	secure\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000.sname.dnslab.jp. NS DS NSEC
secure.sname.dnslab.jp.	900	IN	RRSIG	DS 8 4 900 20101013110643 20100913110643 63840 sname.dnslab.jp. DdW3OJXK0bYk/wBgVX752PZDKWR/AqZSAXrU4ljWZpShO8cRnm6bDXIA uUkovkq2mZIttM8UGwRH97kxhxPIK+D2LhF4g44+gjYv2/3RkaH+1p3V grwDa6HfXb+bUW+Bn+rW1jUTNSoaSaisnMRqU1dCtgk1XhASbRO/yeGL Yvs=
secure.sname.dnslab.jp.	900	IN	RRSIG	NSEC 8 4 900 20101013110643 20100913110643 63840 sname.dnslab.jp. ILawgTRWxqBFF5UIaTqQ4e/PtYltEjBBUbfHPY1NLsmH9yJgSv9SCzda UyKLGnLp3z7A0lHNy9svhDLUbKPVLutxR6kCVgysbiXghnUY8qyi6t5P 4NHscv7opXS7K5MszPj8jWRGpD5jpSRRWljkxqx29QeClAiwSdzQmB/Q iCc=

;; ADDITIONAL SECTION:
ns.secure.sname.dnslab.jp. 900	IN	A	61.192.162.73

# !! It returns needless NSEC, sorry !!

3. APEX queries

% dig @203.178.129.38 sname.dnslab.jp NS +dnssec
% dig @203.178.129.38 sname.dnslab.jp SOA +dnssec
% dig @203.178.129.38 sname.dnslab.jp DNSKEY +dnssec

There are many unclear answers, but the answers are validatable.

4. DNSSEC validation using ISC DLV

% dig @validator www.variant1.sname.dnslab.jp A +dnssec
returns AD=1 answer.

;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 2, ADDITIONAL: 3

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;www.variant1.sname.dnslab.jp.  IN      A

;; ANSWER SECTION:
www.variant1.sname.dnslab.jp. 900 IN    CNAME   www.secure.sname.dnslab.jp.
www.variant1.sname.dnslab.jp. 900 IN    RRSIG   CNAME 8 5 900 20101013110958 20100913110958 63840 sname.dnslab.jp. gRoc9jFDyr//qBm+/0/UvP1E2X9BFNam3b1dFo8jGnBP8TIbxC1peGyX kBDUHovB8VNK1Laow8U0mYYUm+uFpWUJYmHBmBK364uPCeTK4HoU2mIT FeEAsBBW0TJqKEwmM3yYUb/VsWPAGydqPij0B8Yg3ih54me5Z6ItRif0 Xnw=
www.secure.sname.dnslab.jp. 3600 IN     A       192.2.0.1
www.secure.sname.dnslab.jp. 3600 IN     RRSIG   A 8 5 3600 20101013062440 20100913062440 58683 secure.sname.dnslab.jp. iPmlOb14WOoPNGzX4msgY/fsBidAzs78c1yEHfFBXBljwdsZR3oGpYIP 6kfuXjhpbjSk9rtC9Qcv9VbTcCz+Ma++mW3lbqWE2r7TMR9ItEtWqyxB bMA43pyVg+3fHdHY4p6SlAVeCbeoTASzWYzIcS2uAeNP0aYffBHI6QL1 +y5Zq/TSYhdKoDcbFtJI/eaU4NEXGCyJn8KqDFMgjnLr/Nn1jWUKM7jJ 0Fk9AEGtZn3BfD4lziCBmtPRR3eiJIrB1YOGlFuiLlpuEIXabIcSkMjL FUw0zL+1N1zNTsjCTPuiRN+SIh6KPhGoacXD0Wnrzx0CIYGXx2oIJcsd b3wzyw==

You can test:

% dig @validator ns.variant1.sname.dnslab.jp A +dnssec

...

But my program has many problems:
  non-existing name results SERVFAIL...
  variant1's DNSKEY results SERVFAIL...
  ...
I will fix them later.

--
Kazunori Fujiwara, JPRS <[email-masked]>

> From: Kazunori Fujiwara <[email-masked]>

---

From: [email-masked]
Date: Mon, 13 Sep 2010 20:38:46 +0900 (JST)

> From: Alex Bligh <[email-masked]>
> records for OWNERNAME (the 'copy').

Adding NS/DS with synthesized CNAME is OK, but not necessary.
Resolvers follow CNAME.

# Adding NS/DS with CNAME is very easy.

> The only NS/DS returned

if SUB.TARGET is zone cut, querying SUB1.SUB2.OWNERNAME is synthesized
"SUB1.SUB2.OWNERNAME CNAME SUB1.SUB2.TARGET" and the resolver can resolve
SUB1.SUB2.TARGET.

if SUB.TARGET is zone cut, querying SUB1.SUB.OWNERNAME is synthesized
"SUB1.SUB.OWNERNAME CNAME SUB1.SUB.TARGET" and the resolver can
resolve SUB1.SUB.TARGET even if SUB.TARGET is zone cut.

> If I am right about this, and OWNERNAME and TARGET are TLDs,

I intended that OWNERNAME and TARGET are second level domain name within 
a TLD which supports variant resolution.

> every domain name within the OWNERNAME TLD?

the TLD's DNS server has to do RFC 4470 online signing for every query.

> To put it mildly,

In my opinion, DNS traffic will not change because CNAME is cachable.

Online signing requirement is not so hard, I think.
Recent PC's CPU can sign 10000 RRs / sec (1024bit RSA).
Or using accelerator card solves performance problem.
We can write new DNS server and new online signer.

My program is very slow because it is written by perl.