Subject: [DNSOP] Priming query transport selection

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 13 Jan 2010 13:19:30 -0500

Draft http://tools.ietf.org/html/draft-ietf-dnsop-resolver-priming-02
says
"2.1.  Parameters of a Priming Query

    A priming query SHOULD use a QNAME of "." and a QTYPE of NS.  The
    priming query MUST be sent over UDP (section 6.1.3.2 of [RFC1123]).
    The UDP source port SHOULD be randomly selected [RFC5452].  The RD
    bit MUST NOT be set.  The resolver SHOULD also use EDNS0 [RFC2671]
    and announce and handle a reassembly size of at least 1024 octets
    [RFC3226].

    [[Do we need a fallback strategy for EDNS unfriendly environments?]]
  "

Going forward I think this is a bad recommendation.  I would like to
propose that the document take the plunge of recommending that
modern DNSSEC capable resolvers perform the priming query over TCP.

The benefit is that a single query can retrieve the signed root NS set
and all the signed glue records.
The alternative is that a resolver that really cares about DNSSEC will have
to issue up to 27 UDP queries in order to get all the records that are
related to the NS set.

Background:
26 signed glue records will require about 5K answer if each RRSet is
signed by a single 1024 bit RSA key.
This will never fit into an ENDS0 answer as number of implementations
have 4096 byte hard limit on answer size.
As of today all the root servers instances that my host reached answered a TCP
query.

Proposed replacement text:
    A priming query MUST use a QNAME of "." and a QTYPE of NS, QCLASS of IN,
    with RD bit set to 0, the source port of the query should be randomly
    selected [RFC5452].

    A DNSSEC aware resolver SHOULD sent the priming query over TCP.
    If TCP is refused a different server SHOULD be tried, after 3 tries
    the resolver SHOULD fall back on UDP.

    A DNSSEC ignorant but EDNS0 capable, resolver SHOULD issue the
    priming query over UDP, ENDS0 option MUST be included with buffer
    size of 1220 or larger.  If the UDP query times out TCP SHOULD be tried.

    An EDNS0 ignorant resolver MUST issue the priming query over UDP.

By making this change section 2.4 can be dropped, the one
on not asking for signed answers.

In section 2.2 the draft allows "pre-fetching" of the priming answer when
75% of TTL has passed. I think this should be higher more like 85%..95% or
a fixed minimum time like 6 hours.

IANA consideration section mentions TTL recommendations for the root zone, but
does not make any, I think the document should document what the current values
are and the group should pass a comment if it thinks the values are 
reasonable or
can be improved. If the values are going to change based on signature 
life times
when the root is signed then that should also be reflected in the document.

         Olafur

---

From: Jim Reid <[email-masked]>
Date: Wed, 13 Jan 2010 19:19:40 +0000

On 13 Jan 2010, at 18:19, Olafur Gudmundsson wrote:

> I would like to propose that the document take the plunge of  
> recommending that

I'm not sure it's a good idea to encourage more TCP traffic to the  
root servers or make that the default. It doesn't seem right to oblige  
servers with decent underlying transport that can handle big EDNS0  
payloads to ignore that and use TCP for their priming queries.

How about the following text instead?

Priming queries from DNSSEC-aware resolvers

A DNSSEC-aware priming query will generate a response of at least 5K.  
DNSSEC-aware resolvers making a priming query with EDNS0 SHOULD use a  
minimum buffer size of foo*. If such a priming query fails -- say  
because of fragmentation issues in the underlying network -- a DNSSEC- 
aware resolver SHOULD use TCP. If TCP is refused or times out a  
different server SHOULD be tried. After TCP failures from 3 root  
servers, the resolver SHOULD fall back on UDP and use an EDNS0 buffer  
no larger than bar*. A resolver resorting to UDP/EDNS with a buffer  
size of bar should use that combination for subsequent queries needed  
to fully validate the response to their priming query.

Priming queries from DNSSEC-ignorant resolvers

A resolver that is DNSSEC ignorant but EDNS0 capable SHOULD issue the  
priming query over UDP using ENDS0 and MUST provide a buffer size of  
1220 or larger.  If the UDP query with EDNS0 times out or fails, TCP  
SHOULD be tried.

Priming queries from DNSSEC-ignorant resolvers

* The values for foo and bar are open for discussion. Though there  
should be some text to explain whatever values were decided. As a  
straw man, how about 8K for foo and 1220 for bar? As a number plucked  
from the air, 8K should be "big enough" to cope with larger or extra  
signatures, when there's say a rollover of 2048 bit RSA keys under  
way. [I've not done the arithmetic to check if a signed root response  
with 2 such keys will fit in 8K. So shoot me...] For bar, the number  
is even murkier. It needs to be much less than foo (obviously), so  
maybe the payload should be set to that for an unsigned UDP response?

---

From: Alex Bligh <[email-masked]>
Date: Wed, 13 Jan 2010 20:01:00 +0000

> modern DNSSEC capable resolvers perform the priming query over TCP.
...
> on not asking for signed answers.

Not sure I agree.

I think there is a good case to be made that IF the DO bit is set,
THEN the response SHOULD be made over TCP, but you are asking
that even non DNSSEC capable resolvers which would query with
DO clear make queries over TCP; in these instances the response
packet would be much smaller.

-- 
Alex Bligh

---

From: Alex Bligh <[email-masked]>
Date: Wed, 13 Jan 2010 20:01:21 +0000

> An EDNS0 ignorant resolver MUST issue the priming query over UDP.

I presume you mean DNSSEC ignorant.

-- 
Alex Bligh

---

From: Jim Reid <[email-masked]>
Date: Wed, 13 Jan 2010 20:34:49 +0000

> I presume you mean DNSSEC ignorant.

That's implicit. The language was in Olafur's original text BTW...

If a resolver doesn't speak EDNS0, it can't set the DO bit. Which  
means the authoritative server isn't supposed to send back DNSSEC- 
related RRs. Unless the resolver explicitly queries for those RRtypes.  
Which seems unlikely, particularly in the context of a priming query.  
It would be very odd for a DNS implementation to be DNSSEC-aware and  
not support EDNS0. Then again, the DNS is full of all sorts of  
weirdness and bizarre implementations.

---

From: Alex Bligh <[email-masked]>
Date: Wed, 13 Jan 2010 20:49:47 +0000

--On 13 January 2010 20:34:49 +0000 Jim Reid <[email-masked]> wrote:

> If a resolver doesn't speak EDNS0, it can't set the DO bit. Which means
> the authoritative server isn't supposed to send back DNSSEC-related RRs.
> Unless the resolver explicitly queries for those RRtypes. Which seems
> unlikely, particularly in the context of a priming query. It would be
> very odd for a DNS implementation to be DNSSEC-aware and not support
> EDNS0. Then again, the DNS is full of all sorts of weirdness and bizarre
> implementations.

I understand DNSSEC support implies EDNS0 support. What I meant was
that if the rationale for using TCP is merely that a large
packet won't fit into a normal EDNS0 window, and that
otherwise TCP is a bad thing as it creates server load, then
we should apply the injunction to use UDP (or more accurately
not use TCP) to any scenario where we know that large packet
isn't going to arrive. Current operational practice would
result in DO clear packets fitting within 4096 bytes,
so no need for TCP when DO is clear.

I thought it might be an error as the section title in your
proposed text doesn't match the section text, but that's
actually because two section titles are the same which
I think is the problem.

Thinking about it, a total prohibition (at MUST level) of using TCP
is probably a bit harsh given we don't even know they have UDP
connectivity. Perhaps "MUST issue the priming query *first*
over UDP", or use a SHOULD.

-- 
Alex Bligh

---

From: Jim Reid <[email-masked]>
Date: Wed, 13 Jan 2010 21:16:49 +0000

On 13 Jan 2010, at 20:49, Alex Bligh wrote:

> Current operational practice would result in DO clear packets  
> fitting within 4096 bytes, so no need for TCP when DO is clear.

I don't think that's always the case Alex. See the lengthy discussion  
in this list about datagram fragmentation and broken middleware boxes  
that don't grok EDNS0. [Or do EDNS0 with a 512 byte buffer size.  
Sigh.] Mind you, some of those boxes will also barf on TCP DNS traffic.

> actually because two section titles are the same which

Indeed: a stupid cut&paste error. Sorry.

> over UDP", or use a SHOULD.

SHOULD is more appropriate than a MUST IMO. If the resolver has a  
priori knowledge that UDP/EDNS0 will fail for some reason, forcing  
them to do that and then revert to TCP or whatever would be a Bad Thing.

The preferred approach might probably be along these lines:
	[1] EDNS0 + DO with a buffer of 5-8K (ish)
	[2] TCP + DO when [1] fails
	[3] EDNS0 + DO + 1.5K (ish) buffer if [2] fails
	[4] EDNS0 (no DO) with a 1.5K (ish) buffer
	[5] Vanilla UDP (no EDNS0) if [4] fails

I think it would be helpful if the guidance on priming queries was  
split into 3 categories: resolvers that speak DNSSEC, those that are  
not DNSSEC-aware but speak EDNS0 and resolvers that are ignorant of  
both protocols. They'd start at [1], [4] and [5] respectively in the  
scenario above. The optimal priming behaviour for each may well be  
different, particularly wrt EDNS0 buffer minima and maxima. It would  
be good to give an explanation for those buffer sizes too in case  
we've all forgotten about that when revisiting the issue 5-10 years  
from now.

Perhaps the recommended resolver behaviour should apply to all queries  
and not just the priming query?

---

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 13 Jan 2010 16:05:49 -0500

At 15:01 13/01/2010, Alex Bligh wrote:

>--On 13 January 2010 13:19:30 -0500 Olafur Gudmundsson <[email-masked]> wrote:
>

DNSSEC compliance requires ENDS0 see RFC4035 section 4.1 and 3.
Why not ask for signatures ?
Paranoid Validating Resolver will need them to make sure the
glue is not forged in particular if the answer over the wire different
from what the validator was bootstrapped with.

With DNSSEC validation you can ignore what section answer came from
if you can create a trust chain to the data.

         Olafur

---

From: Alex Bligh <[email-masked]>
Date: Wed, 13 Jan 2010 21:35:48 +0000

--On 13 January 2010 21:16:49 +0000 Jim Reid <[email-masked]> wrote:

> I don't think that's always the case Alex. See the lengthy discussion in
> this list about datagram fragmentation and broken middleware boxes that
> don't grok EDNS0. [Or do EDNS0 with a 512 byte buffer size. Sigh.] Mind
> you, some of those boxes will also barf on TCP DNS traffic.

Indeed - my slack language. I meant that UDP should at least be given a
go as we don't know a priori that it will fail. We pretty much do know
that for a DO set query.

> I think it would be helpful if the guidance on priming queries was split
> into 3 categories: resolvers that speak DNSSEC, those that are not
> DNSSEC-aware but speak EDNS0 and resolvers that are ignorant of both
> protocols. They'd start at [1], [4] and [5] respectively in the scenario
> above. The optimal priming behaviour for each may well be different,
> particularly wrt EDNS0 buffer minima and maxima. It would be good to give
> an explanation for those buffer sizes too in case we've all forgotten
> about that when revisiting the issue 5-10 years from now.

You've eliminated TCP fallback for non-DNSSEC supporting clients. On
e.g. small MTU dialup, (4) will not succeed in certain circumstances
(i.e. where fragments are not transmitted correctly). I think here
you are relying on [5] to work, but it seems to me reasonable for
a well behaved (but not DNSSEC supporting) client to make a TCP query
if UDP doesn't get through for whatever reason.

> and not just the priming query?

This is somewhat swimming against the tide of (e.g.)
draft-ietf-dnsext-dns-tcp-requirements and
draft-bellis-dns-recursive-discovery (unadopted, disclosure: am coauthor),
which each take the view that there's enough middlebox and fragmentation
breakage of UDP that TCP should be available as a reliable fallback.

Sure, clients should as a general rule try getting UDP to work, but
I think preventing them falling back to UDP unless they are prepared
to take the overhead of adding DO set is not right. It might have
the perverse effect of encouraging people to set DO unnecessarily.

-- 
Alex Bligh

---

From: Edward Lewis <[email-masked]>
Date: Wed, 13 Jan 2010 16:33:50 -0500

>and all the signed glue records.

I am not certain that the cost of doing TCP for this is worth the 
benefit of getting a signed priming response.  I agree with section 
2.4 - no DO bit.

What does a DNSSEC-protected priming query gain you?

Accepting any old priming query and having a root SEP configured, if 
the query is right all things work.  If the query is wrong/forged you 
won't get anywhere any how.  (Without going into the weeds here - 
what if one IP address were forged, what if it were 6, 16, or all of 
them?)

(13 name servers => 13 A records + 7 AAAA records last check)

Besides the warm and fuzzy feeling, what do you gain? (Keep in mind 
all of the TCP traffic it would take to get warm and fuzzy.)

>Why not ask for signatures ?

Same reason it is no longer fashionable to include keys in signed 
responses - signatures are a big load.  Yes, you'll know sooner if a 
server's IP address is a problem, but you'd figure it out before it 
mattered anyway (if you ever use that server).
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.

---

From: Alex Bligh <[email-masked]>
Date: Wed, 13 Jan 2010 21:36:46 +0000

> I think preventing them falling back to UDP unless they are prepared
                                          ^^^ - TCP

-- 
Alex Bligh

---

From: Jim Reid <[email-masked]>
Date: Wed, 13 Jan 2010 21:53:16 +0000

On 13 Jan 2010, at 21:35, Alex Bligh wrote:

> You've eliminated TCP fallback for non-DNSSEC supporting clients.

So add that to the list:
	[6] TCP (no EDNS0) if [5] fails.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 13 Jan 2010 16:57:43 -0500

At 16:33 13/01/2010, Edward Lewis wrote:
>the query is right all things work.  If the query is wrong/forged 
>you won't get anywhere any how.  (Without going into the weeds here 
>- what if one IP address were forged, what if it were 6, 16, or all of them?)
>

Well having TCP used for all priming queries would make me feel better
as TCP traffic is harder to forge.

But seriously DNSSEC signed and validated data should protect the
the resolver from going to the forged addresses.
Yes someone can forge the answer and DoS the resolver into believing that
nothing works.
The situation is "." and root-servers.net. zones are hosted on the
root servers, thus the same servers will get all follow-up questions
about signed address sets as the priming query.
Resolvers like to ask the "close" servers for information thus it
is almost certain that over time the resolver will send a question
to all root servers.

Based on this I think one TCP connection is better than 14-27
UDP ones. (Resolver that only supports one transport should never
ask for the address records it will not use).
We can even take this one step further and ask both priming questions
over the same TCP connection that is NS and DNSKEY.

Ed in my mind this is straight forward engineering question,
which approach is better as in cheaper/faster/safer.

>mattered anyway (if you ever use that server).

This is totally different.
Adding DNSKEY to "random" answers was an "optimization" in trading
off answer size vs delay in first verification for a zone.
The choice made by early RFC's and implementations was the wrong
one for the Internet we have today, where UDP fragments have high
chance of not getting through.

         Olafur

---

From: Jaap Akkerhuis <[email-masked]>
Date: Wed, 13 Jan 2010 23:02:10 +0100

I was about to ask the same question.

    

I think that this is also discussed in Koch's priming draft.

	jaap

---

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 13 Jan 2010 17:41:14 -0500

>Sigh.] Mind you, some of those boxes will also barf on TCP DNS traffic.

EDNS0 RFC restricts EDNS0 to 4096 bytes, number of implementations
will not send more even if client ask for it. Firewalls will
enforce this.

>them to do that and then revert to TCP or whatever would be a Bad Thing.

We are talking about the priming query, assume no prior knowledge
only hints that the resolver is configured with i.e. the SBELT.

>         [5] Vanilla UDP (no EDNS0) if [4] fails

1 is not an option

>and not just the priming query?

No the priming query is different from all other queries.
Yes there should be guidance on fall back for ENDS0 and that
should be discussed in the ENDS0bis document context.

         Olafur

---

From: Jaap Akkerhuis <[email-masked]>
Date: Thu, 14 Jan 2010 00:10:32 +0100

So let's forget about dnssec an do everything over TCP?

So you wasn't serious? 

    
    
But then I expect some decent answers and not some handwaving and flip-flopping
between being serious and not.

	jaap

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 13 Jan 2010 15:16:51 -0800

> will not send more even if client ask for it. Firewalls will

We should have some additional numbers for this with the new run (we just released an updated version of Netalyzr, http://netalyzr.icsi.berkeley.edu )  Among the new tests is a detailed check for actual DNS MTU rather than advertised DNS MTU.

Basically, you can't RELY on UDP packets over 1500B being received by DNS resolvers when requested, but it works a large amount of the time.

So basically, I'd have the model of "Try at EDNS4000, fallback to EDNS1280, fallback to TCP", and cache whether the resolver needs to do this for all authorities (because its side is fragment-broken) or just particular remote authorities.

---

From: [email-masked]
Date: Thu, 14 Jan 2010 08:38:58 +0000

> will not send more even if client ask for it. Firewalls will

RFC 2671 enforces no such limit - the strict limit is 65535, and §4.5.5 
has a hint that 4K might be a reasonable amount of state to maintain for 
fragment reassembly.

I seem to recall that BIND, however, will not permit the EDNS0 buffer size 
to be configured above 4096.  I'm not in a position to double check that 
right now, though.

Ray

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 14 Jan 2010 17:58:00 +0200

> to be configured above 4096.  I'm not in a position to double check that 

Please do not start talking about enforcing some fixed limit that we will laugh about 10 years from now... And if you talk about a limit, pick something very large (like 65535 that seems to be already chosen).

It is enough problems with the 512 limit of today. I do not want to have the same problems when we pass 4096.

Implementations should be free to choose an implementation limit smaller if they want to (and signal that in the EDNS0 size), but please do not say that "max value on EDNS0 size will forever be 4096" or something similar.

Be careful with the wording...

   Patrik

---

From: [email-masked]
Date: Thu, 14 Jan 2010 16:36:13 +0000

> 	[6] TCP (no EDNS0) if [5] fails.

	dnssec is just the first extention to reliably tickle the size/frag
	issues with large UDP responses.  Whatever you blokes come up w/ please
	don't make it feature specific.

--bill

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 14 Jan 2010 08:40:10 -0800

> Be careful with the wording...

Except that EDNS0 MTU is closely coupled with the UDP protocol and its unreliable nature: this message MTU is irrelevant for TCP or another reliable protocol.

It is highly unlikely that the network's MTU will expand beyond 1500B:  There is too much Ethernet, and >1500B MTUs don't really benefit things anyway, because the overhead reductions of going to a higher MTU are near zero (Amdahl's law).  

Which means the number of fragments which ALL need to be received correctly goes up linearly with the size of the message.

Even WITH a larger MTU, bit-errors become more common.  So, even at a minimum, you'd expect many more failures, dropped packets, etc, with a 40,000B datagram than a 4000B datagram.  And DNS over UDP is already unreliable enough, at least when you consider it all the way to the end host with a reasonable timeout on lookups.

Thus given the nature of the UDP protocol, it is highly unlikely that you'd ever want to do ~10K+ byte UDP datagrams.

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 14 Jan 2010 19:14:11 +0200

> Please do not start talking about enforcing some fixed limit that we will laugh about 10 years from now... And if you talk about a limit, pick something very large (like 65535 that seems to be alre…

Let me clarify (and send excuses to Ray) that my comment was not directed against what he said, but supporting him, and instead argue against what some others have suggested -- a fixed low number.

   Patrik -- with left foot in mouth

---

From: Sebastian Castro <[email-masked]>
Date: Fri, 15 Jan 2010 09:30:32 +1300

> has a hint that 4K might be a reasonable amount of state to maintain for

The text in RFC 2671, presented as a hint, could deal to similar issues
with the TCP transport for DNS (working to change SHOULD for MUST).

> 
> I seem to recall that BIND, however, will not permit the EDNS0 buffer
> size to be configured above 4096.  I'm not in a position to double check
> that right now, though.
> 

>From BIND ARM 9.7.0

----------------------
edns-udp-size
	Sets the advertised EDNS UDP buffer size in bytes to control the size
of packets received.
	Valid values are 1024 to 4096 (values outside this range will be
silently adjusted)
----------------------

> Ray
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: [email-masked]
Date: Fri, 15 Jan 2010 08:14:25 +0000

> with the TCP transport for DNS (working to change SHOULD for MUST).

Can you elaborate on what you mean?

I presume you're aware of my draft-ietf-dnsext-dns-tcp-requirements ?

> From BIND ARM 9.7.0

Yes, that's the one.  I was sat on a train with a flakey 3G connection 
when I sent the last message so couldn't check it, but that confirms my 
recollection.

I've already submitted to ISC that the choice of value should be left 
entirely to the sysadmin, and not restricted to an arbitrary lower value 
by their software.

kind regards,

Ray

-- 
Ray Bellis, MA(Oxon) MIET
Senior Researcher in Advanced Projects, Nominet
e: [email-masked], t: +44 1865 332211

---

From: Simon Leinen <[email-masked]>
Date: Fri, 15 Jan 2010 14:13:26 +0100

> on not asking for signed answers.

After reading the entire discussion, I support Olafur's suggestion in
this form.  It's simple enough, and it falls back gracefully if TCP
somehow fails to work.

As for whether we should "encourage more TCP usage of DNS": I really
believe that this is a non-issue.  Priming queries from sane
implementations that follow the specs are NOT what we should be worried
about.  Sure, TCP requires more resources than UDP, especially as
implemented in today's nameservers.  That's why it is important to have
a fallback to UDP for priming: Otherwise it would be too easy for an
attacker to stop resolving nameservers in their tracks during startup.

As to Ed's point that how priming works is not that relevant, especially
with DNSSEC at the root: That's probably true.  But I also sympathize
with Olafur's desire for a warm fuzzy feeling about priming.  Plus, it
would provide a nice opportunity to log issues with TCP queries early
on, with a high chance for server operators to actually notice.
-- 
Simon.

---

From: Florian Weimer <[email-masked]>
Date: Fri, 15 Jan 2010 13:20:29 +0000

> 	[5] Vanilla UDP (no EDNS0) if [4] fails

DO is rather pointless because the priming response cannot be
validated anyway (even if ROOT-SERVERS.NET were secure, which is
currently not planned).

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

---

From: Jim Reid <[email-masked]>
Date: Fri, 15 Jan 2010 14:05:02 +0000

> validated anyway (even if ROOT-SERVERS.NET were secure, which is

It's not pointless. Validating the priming response requires two  
operations. The first of these is checking the signature over the root  
zone's NS RRset. Which won't be returned unless the DO bit is set.  
[Let's avoid the rat-hole of a DNSSEC-aware resolver iteratively  
querying for DNSKEYs, RRSIGs and so on.] The second operation involves  
validating the address records in root-servers.net. Which will also be  
most efficiently done by setting the DO bit on those queries.

---

From: Florian Weimer <[email-masked]>
Date: Fri, 15 Jan 2010 14:23:59 +0000

* Jim Reid:

> querying for DNSKEYs, RRSIGs and so on.]

I'm not sure this narrow perspective is helpful.  Given the amount of
work required to validate the priming response (which resolvers aren't
required to do until they see a client query for ./IN/NS, similar to
what happens with all the other NS RRsets), it really doesn't matter
if you send a DO=0 query first, to get the addresses (in the
additional section), and then a DO=1 query, to get the signature on
the NS RRset (in the answer section).

---

From: "George Barwood" <[email-masked]>
Date: Fri, 15 Jan 2010 16:42:00 -0000

----- Original Message ----- 
From: "Olafur Gudmundsson" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, January 13, 2010 6:19 PM
Subject: [DNSOP] Priming query transport selection

> As of today all the root servers instances that my host reached answered a TCP

Why would glue records be signed? That's not normal in DNSSEC, AFAIK.
Querying the IANA testbed

dig ns . @ns.iana.org. +dnssec

signs only the NS RRset, which seems reasonable.
Is the testbed not representative in some way?

[ Worried I'm saying something stupid - haven't thought about DNSSEC recently ]
George

---

From: "George Barwood" <[email-masked]>
Date: Sat, 16 Jan 2010 11:17:56 -0000

> Why would glue records be signed? That's not normal in DNSSEC, AFAIK.

To correct my statement, the following query shows that glue records may be signed

dig soa se @a.ns.se + dnssec

wich has a response size of  2944 bytes. However, most of this is Additional Section RRSIGS, and

dig soa se @a.ns.se + dnssec +bufsize=700

shows that the "vital" data is much smaller, and truncation will not ocur for 
an EDSN0 buffer size of say 1400 bytes. The same will apply for the priming query.

The question then is "is the additional RRSIG data useful" ?

My answer is "probably not".

DNS data can be broadly classified as 

"User data" ( e.g. A record for www.google.com )
"Name server data" ( e.g. NS records, and the associated A and AAAA records )
"Signature data" ( e.g. RRSIG, DS and DNSKEY records )

In order to obtain validated User data, a client needs 

(1) The record itself ( www.google.com A 1.2.3.4 )
(2) An RRSIG record  www.google.com RRSIG ..... )
(3) The appropriate chain of signed DNSKEY / DS records.

It's not necessary for the "name server data" to be signed at all, that data
is merely used to locate servers where the essential secure data is located.

It might be argued that having signatures for the "Name server data" increases
some warm fuzzy feeling, and prevents some Denial of Service attacks.
But DNSSEC is not designed to prevent "Denial of Service" attacks.
Some "Denial of Service" attacks may be prevented by using stronger
transport, but generally I don't think these attacks are too much of a concern.

There is a particular type of Denial of Service attack that might be prevented
by signing "Name server data". For example, suppose a particular root server
has been compromised, and is issuing bad data. If the client checks the signature
of the "name server data", it can detect the bad data, and try another root server.

So, as I see it, the question is whether it's worth preventing a certain class
of Denial of Service attacks ( and also accidents where a name server is
mis-behaving ).

I think this is up to recursive resolver. Some resolvers may choose to validate
"Name server data", at a small cost in performance, others may choose not to
( or adopt hybrid strategies : assume name server data is ok until a failure occurs,
and then back up and start checking, or check as a background activity ).

Therefore I would argue that the priming query transport need not be specified
in the standard.

George

---

From: Jim Reid <[email-masked]>
Date: Sat, 16 Jan 2010 13:25:25 +0000

> dig soa se @a.ns.se + dnssec

No it doesn't. The name servers for .se are authoritative for the  
address records for *.ns.se. And ns.se isn't delegated either. The A  
and AAAA records for *.ns.se in this response are not glue. They would  
be glue if they were in a referral response from a server for .se's  
parent.

> My answer is "probably not".

So authoritative servers shouldn't volunteer helpful/relevant data in  
the Additional Section of a response, should they? If the server's got  
additional data that might benefit the client -- like an A or AAAA  
record for a hostname in the RDATA of an answer -- it makes sense for  
the server to include it provided there's room for that data in the  
response. That also applies to any RRSIG(s) over that additional data,  
assuming of course the client had set the DO bit.

---

From: "George Barwood" <[email-masked]>
Date: Sat, 16 Jan 2010 14:54:52 -0000

----- Original Message ----- 
From: "Jim Reid" <[email-masked]>
To: "George Barwood" <[email-masked]>
Cc: "IETF DNSOP WG" <[email-masked]>
Sent: Saturday, January 16, 2010 1:25 PM
Subject: signing glue and additional data

> be glue if they were in a referral response from a server for .se's  

Ok, you can argue over the definition of what a glue record is.
From the client's point of view, the A record is not authoritative
( although a valid RRsig could prove the A record is authoritative? ).
I was using "glue" here in the weaker sense : "An A record for an in-zone
NS record included in the additional section".

> assuming of course the client had set the DO bit.

It's not clear. You can argue that it's best to include as much additional data
as possible, to minimize the number of transactions. On the other hand if this is at the
expense of a lot of wasted bandwidth, or might cause failures or vulnerabilities for EDNS0
packets > MTU, maybe it's not a good policy. It does depend on whether
the resolver is bothering to validate "Name server data" immediately.

This partly goes back to the question I raised at

http://ops.ietf.org/lists/namedroppers/namedroppers.2009/msg02647.html

where I argued that servers should by default limit EDNS0 responses to ~1500 bytes,
to mitigate amplification attacks and avoid UDP fragmentation problems.

Regards,
George

---

From: Sebastian Castro <[email-masked]>
Date: Mon, 18 Jan 2010 10:05:14 +1300

> I presume you're aware of my draft-ietf-dnsext-dns-tcp-requirements ?

Yes, I'm aware of your draft and I meant to support Patrik Falstrom
comment: we have to be very careful with the wording if we don't want to
 be working in future years to update/correct the limit for UDP buffer
size in EDNS.

> entirely to the sysadmin, and not restricted to an arbitrary lower value

Cheers
Sebastian Castro
NZRS

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 18 Jan 2010 09:46:00 -0500

> Ok, you can argue over the definition of what a glue record is.

Indeed, there was an I-D floating about that offered to do exactly
that.  It's expired, though:

http://tools.ietf.org/html/draft-koch-dns-glue-clarifications-03

Perhaps someone should take that up?

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Roy Arends <[email-masked]>
Date: Mon, 18 Jan 2010 11:01:08 -0500

> Perhaps someone should take that up?

I've wrote an article about this about 4 years ago, here's the yeast of it:

GLUE RECORDS

The concept of glue records (address records such as A and AAAA) exists _solely_ in zones and are related to delegations. The term is not used to refer to address records that appear in DNS requests and responses. Glue records are useful to a resolver so it can locate the delegated nameserver. I'll try to explain the terminology involved and the process of determining which records are called glue. Glue addresses are related to delegation point NS records. 

We need three properties of a delegation point NS record to determine if an associated address is glue:

  APEX: the name of the zone that contains the delegation point NS record.
  NSOWNER: the ownername (left hand side) of the delegation NS record.
  NSDNAME: the NSDNAME (right hand side) of the delegation NS record.

All these properties are fully qualified domain names.

We can describes 4 classes of NSDNAME:

  1) offtree: NSDNAME is not a subdomain of, nor equal to the APEX.
  2) authoritative: NSDNAME is a subdomain of APEX, and, NSDNAME is not equal to nor a subdomain of any NSOWNER.
  3) in-bailiwick: NSDNAME is a subdomain of APEX, and, NSDNAME is equal to or a subdomain of NSOWNER.
  4) sibling: NSDNAME is a subdomain of APEX, and, NSDNAME is equal to or a subdomain of some other NSOWNER.

An NSDNAME is the hostname of the nameserver. Nameservers’ addresses are stored in A or AAAA records. If NSDNAME is of class 1 or 2, the corresponding addresses are NOT glue. 
In class 1, the addresses are not even in the zonefile. 
In class 2, the addresses are in the zone, and are authoritative data. Note that for the root zone, class 1 simply does not exist, since the entire dns tree are subdomains of root.

If NSDNAME is in class 3 or 4, the corresponding addresses are glue addresses.

GLUE TYPES

In class 3 (’in-bailiwick’) it is required to have that address in the zone. As an example, assume the following NS record:

  alpha.tld. NS ns1.alpha.tld.

The alpha.tld zone resides on nameserver ns1.alpha.tld. A resolver can’t reach alpha.tld without the address of ns1.alpha.tld. To resolve ns1.alpha.tld, it needs to reach alpha.tld. To route around this chicken and egg problem, the tld zone needs to have an address for ns1.alpha.tld. So, class 3 ‘in-bailiwick’ requires glue. We call this glue ‘in-bailiwick glue’.

In class 4 (’sibling’), it is not required to have that address in the zone, unless there are circular dependencies. As an example of a circular dependency, assume the following NS records:

  foo.tld. NS ns1.bar.tld.
  bar.tld. NS ns1.foo.tld.

The ‘foo’ and ‘bar’ delegation have a circular dependency. Foo resides on a server under bar, bar resides on a server under foo. A resolver can’t reach foo without the address for ns1.bar which is in the bar zone, and it can’t reach bar without the address of ns1.foo which is in the foo zone. Hence the ‘tld’ zone needs, in this specific case, address records for both ns1.foo and ns1.bar. Note that circular depenency graphs can be complex, and paths in the graph can be long. A resolver will more than likely have measures against looping and long path lengths.

Orphan Glue Phenomenon

An interesting phenomenon occurs when a delegation NS record set is removed from the zone while the glue records that reside under it, are not removed. These glue records are now class 2 (authoritative) records. We call these addresses 'orphan glue' records, though they are not glue anymore (they've been adopted) 

DNSSEC and Glue

Glue addresses are not signed. They are supposed to be signed in the zone that is authoritative for the address record. They also do not appear in NSEC or NSEC3 chains. However, when glue addresses become orphan (see 'orphan glue phenomenon') they are now authoritative data, and subsequently need to be signed. 

Wide and narrow glue policy. 

These policies determine what types of glue (class 3 or class 4) are allowed in a zone.

Wide glue policy allows both class 3 (in-bailiwick glue) and class 4 (sibling glue) to be registered in the zone. Narrow glue policy allows class 3 only. A combination of the two policies ‘case-by-case policy’ exists where sibling glue is only registered to avoid circular dependencies.

The dependency problem exists not only with missing glue. It can be that foo.tld resides on a nameserver ‘ns1.cow.moo’ and ‘cow.moo’ resides on a nameserver ‘ns1.foo.tld’. Both the moo and tld registries are not allowed (by dns-protocol) to serve off-tree addresses. So, while gluelessness can be avoided for class 4, it can not be avoided for class 1.

Kind regards,

Roy Arends
Sr Researcher
Nominet UK