Subject: [dnsext] Failure to add glue MUST cause TC to be set.

From: Mark Andrews <[email-masked]>
Date: Sun, 20 Feb 2011 08:07:15 +1100

Below is a example of why TC should be set when glue cannot be added
to the answer.

We need to make it clear that adding address records here (RFC 1034,
Section 4.3.2, step 3b) is not optional unlike step 6 where they are
optional.

         b. If a match would take us out of the authoritative data,
            we have a referral.  This happens when we encounter a
            node with NS RRs marking cuts along the bottom of a
            zone.

            Copy the NS RRs for the subzone into the authority
            section of the reply.  Put whatever addresses are
            available into the additional section, using glue RRs
            if the addresses are not available from authoritative
            data or the cache.  Go to step 4.

Mark

; <<>> DiG 9.6.0-APPLE-P2 <<>> +norec +dnssec +bufsize=512 @b.gov-servers.net vwall1a.nyc.gov
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13052
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1472
;; QUESTION SECTION:
;vwall1a.nyc.gov.		IN	A

;; AUTHORITY SECTION:
nyc.gov.		86400	IN	NS	vwall1a.nyc.gov.
nyc.gov.		86400	IN	NS	vwall2a.nyc.gov.
nyc.gov.		86400	IN	NS	vwall3a.nyc.gov.
nyc.gov.		86400	IN	NS	vwall4a.nyc.gov.
rq2651faaj4nen6tfis8ju5005qccn8j.gov. 86400 IN NSEC3 1 0 8 4C44934802D3 RQDJO8PKJ2LEUMC30SGU45DDI643G497 NS
rq2651faaj4nen6tfis8ju5005qccn8j.gov. 86400 IN RRSIG NSEC3 7 2 86400 20110224160026 20110219160026 47602 gov. ZL6YdI7AOtcv5Vfs9cjOZkj6tld5+K4UfDjD2BV4ToBQQ4jhD6HS102P p2TGBP90RdjSLGpGw5OHt9ZxjCPzjWjcoM5V5PiWoGhXrmdgahfmVENE cRH9gsxJhlonz+vIfXlFTeCLgn5d3D5WxjURdGKfDK5j35JvDKb0kQ+8 CwZNXGeopE+01fgiTbIMvSqXCpXlXY/RD+fAbfuh+5e05jdIbj/53/9+ gQOHTXYd3T9jCOxrFOONuznzyvpRODJ3Sga/P+DvWzgUrVZSOKYEsAAi COTbtyCqDhfBIyNB9MxPry4oN0uet46zTjIqhvRg4JjPnfC9WFAEGDTK uolyNw==

;; Query time: 187 msec
;; SERVER: 209.112.123.30#53(209.112.123.30)
;; WHEN: Sun Feb 20 07:39:46 2011
;; MSG SIZE  rcvd: 510

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE:	+61 2 9871 4742		         INTERNET: [email-masked]
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Paul Vixie <[email-masked]>
Date: Sat, 19 Feb 2011 21:20:25 +0000

we also need to require that the parent zone contain the addresses of
child glue, since otherwise the parent authority must also be recursive
which is something i think we're trying to move away from.

---

From: [email-masked]
Date: Sun, 20 Feb 2011 07:29:16 +0000

doesn't that cause some tension - two zones being authoritative for the
same data?  and i'm not fully convinced that stripping out recursion is
a n'cessy evil.

--bill

---

From: Tony Finch <[email-masked]>
Date: Sun, 20 Feb 2011 18:48:57 +0000

On 20 Feb 2011, at 07:29, [email-masked] wrote:
> same data? 

No, because a parent zone is not authoritative for NS and glue address records at and below a delegation point.

Tony.
--
f.anthony.n.finch  <[email-masked]>  http://dotat.at/

---

From: "George Barwood" <[email-masked]>
Date: Sun, 20 Feb 2011 19:13:06 -0000

----- Original Message ----- 
From: "Mark Andrews" <[email-masked]>
To: <[email-masked]>
Sent: Saturday, February 19, 2011 9:07 PM
Subject: [dnsext] Failure to add glue MUST cause TC to be set.

> [..]

Agreed, but where exactly should the line be drawn?

If omitting any glue leads to truncation, then many (non-DNSSEC) referrals over UDP will have TC set. e.g. 

dig foo.com @a.root-servers.net

Is that sensible? How much glue is enough?

George

---

From: Brandon Black <[email-masked]>
Date: Sun, 20 Feb 2011 14:14:52 -0600

> records at and below a delegation point.

Isn't this really a matter of semantics?  The parent zone is
authoritative for everything beneath itself, even if it choses to use
that power of authority to give a delegation response.  e.g. the .com
servers are authoritative for www.example.com, but they choose to
delegate that answer to the NS for example.com.  If example.com's
nameservers are in-bailiwick (e.g. ns1.example.com) there's no
conflict here and the parent can (and in fact, must) provide
authoritative glue.  If example.com's nameservers are somewhere
underneath .org, there's not much point in providing the glue, as a
secure resolver wouldn't believe you anyways.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Mark Andrews <[email-masked]>
Date: Mon, 21 Feb 2011 07:31:56 +1100

> Agreed, but where exactly should the line be drawn?

What line?  If the glue doesn't fit then the referral is not complete.

> dig foo.com @a.root-servers.net

Yes.
 
> Is that sensible?

Yes.

> How much glue is enough?

Depends on the delegation.  The only safe answer is all you have.

Mark

---

From: Jim Reid <[email-masked]>
Date: Sun, 20 Feb 2011 20:44:16 +0000

On 20 Feb 2011, at 20:14, Brandon Black wrote:

> Isn't this really a matter of semantics?

Yes: zone cut semantics, not language semantics.

> The parent zone is
> delegate that answer to the NS for example.com.

Nope. Query the .com name servers for the NS records for example.com.  
They correctly return a non-authoritative answer. It's only the name  
servers for example.com that are authoritative for example.com and  
will authoritatively answer that query. In other words, it's the child  
that's responsible for the zone's authoritative NS RRset, not the  
parent. Which is how things should be when you consider what  
delegation actually means: crossing an administrative boundary from  
one authority to another.

Please think again about what you posted. The inference of what you  
say is that the root servers are authoritative for everything. That's  
clearly not true.

---

From: "George Barwood" <[email-masked]>
Date: Sun, 20 Feb 2011 20:59:19 -0000

----- Original Message ----- 
From: "Mark Andrews" <[email-masked]>
To: "George Barwood" <[email-masked]>
Cc: <[email-masked]>
Sent: Sunday, February 20, 2011 8:31 PM
Subject: Re: [dnsext] Failure to add glue MUST cause TC to be set.

> Depends on the delegation.  The only safe answer is all you have.

One suggestion that might work is that glue which matchs QNAME+QTYPE MUST be included,
but other glue can be omitted.

So an example might be ( all queries directed to root servers )
First query [www.foo.net. A]
First referral response [net NS a.gtld-servers.net]  (missing glue)
Second query [a.gtld-servers.net A]
Second referral response [net NS a.gtld-servers.net] with glue for [a.gtld-servers.net A] only.

This assumes that a resolver will send an explicit query for missing glue.
That seems plausible, because resolvers already have to cope with not all glue being present.

George

---

From: Mark Andrews <[email-masked]>
Date: Mon, 21 Feb 2011 08:07:58 +1100

In message <3764325DE7FA4B2F9B77387EBD15EAF8@local>, "George Barwood" writes:
> One suggestion that might work is that glue which matchs QNAME+QTYPE MUST
> be included, but other glue can be omitted.

This does not work in all cases where glue needs to be returned.

Zone A.net is served by servers in B.net.  Zone B.net is served by
servers in A.net.

Mark

---

From: Brandon Black <[email-masked]>
Date: Sun, 20 Feb 2011 15:15:15 -0600

> Zone A.net is served by servers in B.net.  Zone B.net is served by

That should never really work reliably though, right?  A resolver
would have to have security flaws to ever find answers in either zone,
unless by chance A.net. and B.net. shared at least a single nameserver
delegated from the net. servers, and that nameserver returned the
applicable cross-zone glue, and the resolver was smart enough to
realize its own caches entries for the A.net and B.net nameservers
referred to the same single server to trust the suspicious cross-zone
glue from.

This seems like a special case that would hardly be worth optimizing a
resolver to handle though, and authoritative servers certainly can't
*expect* those kinds of smarts in order for their zones to function at
all.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: "George Barwood" <[email-masked]>
Date: Sun, 20 Feb 2011 21:30:15 -0000

----- Original Message ----- 
From: "Mark Andrews" <[email-masked]>
To: "George Barwood" <[email-masked]>
Cc: <[email-masked]>
Sent: Sunday, February 20, 2011 9:07 PM
Subject: Re: [dnsext] Failure to add glue MUST cause TC to be set.

> Zone A.net is served by servers in B.net.  Zone B.net is served by

So something like

But nothing will work in that case - if you make a recursive loop like this, then there is no glue
( the name server names are not "below" the cut ) and you have had it regardless. 

That's a mis-configuration, not a counter-example.

George

---

From: Mark Andrews <[email-masked]>
Date: Mon, 21 Feb 2011 09:47:41 +1100

In message <AANLkTi=cG0G1ocAqGUie1NCa+qgL=[email-masked]>, Bran
don Black writes:
> > Zone A.net is served by servers in B.net. =C2=A0Zone B.net is served by
> > servers in A.net.
> 
> That should never really work reliably though, right?

No.  It works perfectly reliably provided you follow RFC 1034.

> A resolver

Your trusting the parent to supply glue for names beneath it.  You
*have* to trust the parent when it gives you this information.
These names are all within the baliwick of the parent.

> *expect* those kinds of smarts in order for their zones to function at

Firstly, such delegations exist today.  Secondly you are not
optimising for it.  You are just returning glue that your child
zone administrators have added.

Mark

---

From: Mark Andrews <[email-masked]>
Date: Mon, 21 Feb 2011 09:58:11 +1100

In message <3D9B2A0D15F84DC6822FCF0FC6F8F214@local>, "George Barwood" writes:
> But nothing will work in that case - if you make a recursive loop like this,
> then there is no glue ( the name server names are not "below" the cut ) and
> you have had it regardless. 

Glue records are records in the parent zone to enable you to reach
the servers for the child zone.  RFC 1034 gave a obvious example
of such records.  There are less obvious examples.

> That's a mis-configuration, not a counter-example.

No. It is not a mis-configuration.

---

From: James Mitchell <[email-masked]>
Date: Mon, 21 Feb 2011 10:08:11 +1100

Whether it is a mis-configuration depends on the glue policy of the parent zone.

There would be a mis-configuration under a "narrow" policy, where glue RRs are registered if and only if the name server resides within or below the delegated (child) zone. On the other hand it would be fine under a "wide" policy, where glue RRs are registered if and only if the name server resides below the delegating (parent) zone.

Glue policy definitions came from http://tools.ietf.org/html/draft-koch-dns-glue-clarifications-04.

James

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Mark Andrews
> Sent: Monday, 21 February 2011 9:58 AM
> To: George Barwood
> Cc: [email-masked]
> > >> >> If omitting any glue leads to truncation, then many (non-DNSSEC)
> referrals
> > >> >> over UDP will have TC set. e.g.
> > >> >>

---

From: Brandon Black <[email-masked]>
Date: Sun, 20 Feb 2011 19:10:47 -0600

On Sun, Feb 20, 2011 at 4:47 PM, Mark Andrews <[email-masked]> wrote:
>> the same single server to trust the suspicious cross-zone
>> glue from.
>

Yes, I was thinking incorrectly when I wrote that, re: A.net. and
B.net.  In the terms of the glue clarification draft James linked, I
guess narrow glue is pretty much required to function if it exists,
and wide glue can work (and is often necessary in examples like your
A.net. vs B.net. one), although it does require some security policy
and management on the part of the parent registrar.  For an easy
general-case rule, you'd probably only want to allow those authorized
to make updates related to B.net.'s NS records to register other glue
address records underneath B.net. upstream, but still allow A.net.
admins to reference existing B.net. glue in their NS records.

The case I was confusing this with (re: optimization, etc) was the
case where there was no immediate common parent domain to host the
cross-zone glue (e.g. A.net. NS ns1.B.org. + B.org. NS ns1.A.net.).
In the special case that the org. and net. nameservers shared IP
addresses (and were in fact the same namservers) and handed out
cross-zone glue addresses for those cases, a smart enough resolver
might figure it out and believe them based on the shared nameserver
IPs ("I already know 192.0.2.3 is authoritative for org. from earlier,
and now during a query for A.net to the same IP address, I'm seeing
B.org. glue records and it's ok to believe them"), but a dumber
resolver would be unable to see records in either domain if it
implemented a sane basic security model (bailiwick of QNAME).  I think
we have to assume the simpler resolver behavior rather than try to
construct schemes that rely on the "smarter" behavior, right?

The optimization part is on the authoritative servers' part.  Should
an authoritative server ever serve glue that's outside the bailiwick
of the delegation's parent zone, just because it knows those glue
addresses are part of other "unrelated" zones it serves, and a
resolver might be smart enough to figure out the relationship?  I
think the answer is no, it's not worth serving that glue.  Most
resolvers are going to send you a second query for it anyway based on
the simple bailwick of QNAME security model.

In general I think the smartest policy in light of all of this is to
always put the NS names for a zone beneath that zone itself, even if
the IPs refer to 3rd-party nameservers, but it certainly doesn't have
to be a requirement to function.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 21 Feb 2011 10:15:42 +0900

> No. It is not a mis-configuration.

For example, "org." and "info." are configured so.

						Masataka Ohta

---

From: Brandon Black <[email-masked]>
Date: Sun, 20 Feb 2011 19:22:09 -0600

On Sun, Feb 20, 2011 at 2:44 PM, Jim Reid <[email-masked]> wrote:
> Nope. Query the .com name servers for the NS records for example.com. They
> correctly return a non-authoritative answer. It's only the name servers for
> example.com that are authoritative for example.com and will authoritatively
> answer that query. In other words, it's the child that's responsible for the
> zone's authoritative NS RRset, not the parent. Which is how things should be
> when you consider what delegation actually means: crossing an administrative
> boundary from one authority to another.
>
> Please think again about what you posted. The inference of what you say is
> that the root servers are authoritative for everything. That's clearly not
> true.

IMHO, this is where it's semantics.  The root servers are
authoritative for everything, that's why we believe their delegation
answers.  The AA-bit is just part of how the protocol signals
delegation of authority.  Yes, the child is responsible for its own NS
records while the parent delegates, but the parent can take away the
delegation at any time and serve the child's zone data directly.

This does come into play in the glue issues.  You can trust glue data
which falls within the delegating (parent) zone , but you can't
necessarily trust other glue records that might come in a response.
This is much like a corporate hierarchy model: the CEO is
authoritative for everything, but delegates decisions throughout a
hierarchy of lower level managers.  The fact that Joe the VP of Sales
is responsible for all Sales decisions doesn't take away the CEO's
authority over everything the company does.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Mark Andrews <[email-masked]>
Date: Mon, 21 Feb 2011 12:42:01 +1100

In message <[email-masked]>, Bran
don Black writes:
> > Your trusting the parent to supply glue for names beneath it. =C2=A0You

There is something to be said for the argument up to here ...
 
> to be a requirement to function.

but this section is a really, really bad idea and defeats the whole
purpose of having NS records be names not addresses.

If you don't want to handle loops then the rule is that "nameservers
MUST be listed as nameservers for the zone they live in" not
"nameservers MUST live in the zones they serve".  People always
seem to want to go one step too far.

		foo.net NS ns1.foo.net
		foo.net NS ns2.foo.net
		ns1.foo.net A 1.2.3.4
		ns2.foo.net A 1.2.3.5
		bar.net NS ns1.foo.net
		bar.net NS ns2.foo.net
		xxx.net NS ns1.foo.net
		xxx.net NS ns2.foo.net
		yyy.net NS ns1.foo.net
		yyy.net NS ns2.foo.net
		zzz.net NS ns1.foo.net
		zzz.net NS ns2.foo.net

Mark

---

From: Jay Ashworth <[email-masked]>
Date: Sun, 20 Feb 2011 20:44:15 -0500 (EST)

----- Original Message -----
> From: "Brandon Black" <[email-masked]>

> > say is

You appear to be suggesting that the AA bit on the glue records in a 
parent zone *can be set*, merely by changing something in the parent
zone file.

I don't believe that to be true; TTBOMK, *the name server* makes that 
choice (to not set AA), *precisely because the parent server is not
considered to be authoritative for objects within its children's 
zones*.

I don't think that it's physically possible to make a parent server set
the AA bit on that glue, though I'd be happy to be proven wrong.  I don't
operate many parent zones.  :-)

So: people-who-do: is my supposition/assertion above correct?  If it is,
is it reasonable to draw from it the inference that I do (IE, that Jim is
correct and Brandon's not)?

I'm sure Albitz & Liu would tell me, but I do fancy stuff with DNS
insufficiently frequently for me to know where it is...

Cheers,.
-- jra

---

From: Jim Reid <[email-masked]>
Date: Mon, 21 Feb 2011 02:43:22 +0000

On 21 Feb 2011, at 01:22, Brandon Black wrote:

> IMHO, this is where it's semantics.

The protocol specs say otherwise. Please read Section 6 of RFC2181. If  
you wish to continue an angels on pinhead debate about linguistic  
semantics of "authoritative" or what you mean by that, let's stop  
wasting each other's time and stop now.

> The root servers are authoritative for everything, that's why we  
> believe their delegation answers.

No they are not. The root servers are authoritative for the root  
zone*. Which largely holds pointers to where we can find authoritative  
data about other names in the DNS. The root zone cannot be  
authoritative for those pointers (delegations) because they live  
beneath the zone cuts for the TLDs.

I'm not sure what you mean by "believe delegation answers". No, please  
don't try to explain... But you seem to be wrong about that too. The  
root servers may well tell us there's a delegation for .brandon. But a  
resolving name server won't "believe" that until it gets an  
authoritative answer from one of the .brandon name servers, confirming  
the TLD's existence. And hopefully validates all of that with DNSSEC.

The word "authoritative" has a well defined meaning in the DNS  
protocol. You seem to want to use it in a different context. Which is  
fine: words can mean whatever you want them to mean. However please  
don't do that in this forum with technical terms which have carefully  
defined meanings when used for the DNS protocol. This list is for DNS  
protocol geeks after all.

*Well, OK, they also authoritatively serve root-servers.net.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Brandon Black <[email-masked]>
Date: Sun, 20 Feb 2011 22:00:23 -0600

On Sun, Feb 20, 2011 at 8:43 PM, Jim Reid <[email-masked]> wrote:
>> The root servers are authoritative for everything, that's why we believe
>> their delegation answers.
>
> No they are not. The root servers are authoritative for the root zone*.
> Which largely holds pointers to where we can find authoritative data about
> other names in the DNS. The root zone cannot be authoritative for those
> pointers (delegations) because they live beneath the zone cuts for the TLDs.
>
> I'm not sure what you mean by "believe delegation answers". No, please don't
> try to explain... But you seem to be wrong about that too. The root servers
> may well tell us there's a delegation for .brandon. But a resolving name
> server won't "believe" that until it gets an authoritative answer from one
> of the .brandon name servers, confirming the TLD's existence. And hopefully
> validates all of that with DNSSEC.

Fine, I won't use the word Authoritative in way that doesn't conform
to the specifications, that's fair.

The only way the resolver knows to believe the answer from the
.brandon name servers is based on glue it believed from the root
server.  One way or another, you cannot avoid the fact that the root
servers control .brandon's resolution, directly or indirectly.  The
root servers make a poor example though, because they're universal.
Let's look at example.com. vs example.org. again, assuming the root
delegates com. and org. to different sets of nameservers.

If the org. nameservers answer www.example.org. with:

example.org. NS ns1.example.com.
ns1.example.com. A 192.0.2.1

I thought it was part of avoiding cache poisoning, etc, that org.
nameservers are not to be believed for glue outside of its authority,
and that the resolver should query ns1.example.com. separately.  Or is
it the view of the RFCs that ns1.example.com. is basically
functionally a "temporary" name that ties those two response RRs
together just to be used once to contact 192.0.2.1 for this one
delegation and never cached, and that this doesn't need to be
independently verified through the com. servers?  I was under the
impression this is why it matters whether example.org.'s nameserver
glue is or isn't within org., and hence my whole point about why this
matters for glue.  An un-snarky correction on this would be
appreciated :P
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Jay Ashworth <[email-masked]>
Date: Sun, 20 Feb 2011 23:09:18 -0500 (EST)

[ SPECULATION AHEAD ]

----- Original Message -----

> nameservers are not to be believed for glue outside of its authority,

I believe that you're not supposed to *cache* them.  But you *have* to 
believe the parent glue, as it's the only way you *have* to locate the
zone servers for the subdomain, is it not?

root -> .org -> example.org
             ^^ that right there is the referral we're talking about.

> and that the resolver should query ns1.example.com. separately. 

If you don't believe the IP addresses that .org hands you for example.org's
zone servers, where else are you going to ask?

> Or is it the view of the RFCs that ns1.example.com. is basically

It is just a "temporary name", I suppose, and if you have an authoritative
locally cached copy of the pointer to the zone server, I suppose it might
override what you're handed... but then you wouldn't trace the whole
chain, anyway, would you?

I suspect that, orthogonal to the questions about zone cut semantics, 
exactly how the resolvers work is implementation-defined... as Apple
taught us a decade or more ago...

Cheers,
-- jra

---

From: Olafur Gudmundsson <[email-masked]>
Date: Sun, 20 Feb 2011 23:56:37 -0500

On 20/02/2011 3:44 PM, Jim Reid wrote:
> servers for example.com that are authoritative for example.com and will
> authoritatively answer that query. In other words, it's the child that's
> responsible for the zone's authoritative NS RRset, not the parent. Which
> is how things should be when you consider what delegation actually
> means: crossing an administrative boundary from one authority to another.
>
> Please think again about what you posted. The inference of what you say
> is that the root servers are authoritative for everything. That's
> clearly not true.
>

In RCF103x with RFC2181 clarification the  world it was simple:
Parent zone is authoritative for the existence of delegation, child 
servers are authoritative for content.

==> Everything but the presence of NS records is hint/glue in parent 
servers.

But we could not keep it simple forever in the DNSSEC world thus this 
amendment:
Parent is Authoritative for the contents DS record and NSEC/NSEC3 
records at delegation that prove if the delegation exists and if there 
is a trust path from parent to child.

	Olafur

---

From: Florian Weimer <[email-masked]>
Date: Mon, 21 Feb 2011 08:53:42 +0000

> ; <<>> DiG 9.6.0-APPLE-P2 <<>> +norec +dnssec +bufsize=512 @b.gov-servers.net vwall1a.nyc.gov

This query is in direct violation of RFC 3226, so it is not a
particularly compelling example.

I agree there is a protocol problem.  But you need to find something
else to deal with the case above, like fallback to DO=0 to get the
referral---which would be even bettr than TCP fallback from a
performance perspective.

-- 
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
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Tony Finch <[email-masked]>
Date: Mon, 21 Feb 2011 10:29:38 +0000

> construct schemes that rely on the "smarter" behavior, right?

Until about a year ago the gtld-servers.net nameserver which host .com and
.net handed out cross-TLD glue. There were a number of domains which
relied on this fact in order to work correctly - and they did pretty much
work, which implies that resolvers are not "dumber" according to the
criteria above. But as part of the preparation for DNSSEC this behaviour
was tidied up.

http://verisigninc.com/en_GB/products-and-services/domain-name-services/domain-information-center/frequently-asked-questions/dns-behavior-changes/

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Biscay, FitzRoy: Westerly, backing southerly for a time, 5 to 7, occasionally
gale 8, decreasing 4 later in south Fitzroy. Very rough or high. Rain or
showers. Moderate or good, occasionally poor.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Tony Finch <[email-masked]>
Date: Mon, 21 Feb 2011 10:32:33 +0000

On Mon, 21 Feb 2011, Mark Andrews wrote:
> Brandon Black writes:

What problems does it cause other than reducing the opportunities to
re-use cached NS records?

Tony.

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Mon, 21 Feb 2011 17:34:14 +0100

Hi Brandon, Jay,

> chain, anyway, would you?

It is not 'temporary', but 'lower ranked', and this is defined in
RFC2181.  Where you find that the data from the example.org is preferred
over this data.  But until you have that data, this is what you use (to
get there, as Jay infers).

Best regards,
   Wouter

---

From: Michael Graff <[email-masked]>
Date: Mon, 21 Feb 2011 10:55:31 -0600

> is that the root servers are authoritative for everything. That's

Actually, I think he's right technically, but not operationally.  The
root could return an auth answer for www.example.com if it wanted to,
and AFAIK resolvers would and should believe it.

It's a matter of policy and current use that we don't do that in the root.

- --Michael

---

From: Joe Abley <[email-masked]>
Date: Mon, 21 Feb 2011 13:30:29 -0500

> *Well, OK, they also authoritatively serve root-servers.net.

... and ARPA (except J) and IN-ADDR.ARPA (except J, M, for another couple of weeks).

Joe

---

From: "George Barwood" <[email-masked]>
Date: Mon, 21 Feb 2011 20:04:00 -0000

----- Original Message ----- 
From: "Masataka Ohta" <[email-masked]>
To: <[email-masked]>
Sent: Monday, February 21, 2011 1:15 AM
Subject: Re: [dnsext] Failure to add glue MUST cause TC to be set.

> For example, "org." and "info." are configured so.

No.

org and info share name servers, but they each have 4 "in-zone" name server names below the cut.

A query (to root servers) for <anything>.org allows a recursor to learn the A/AAAA records for half the name servers, a subsequent query for <anything>.info to learn the A/AAAA records for the other half.

The root name servers also serve additional records for the other half as well as glue, which allows a recursor with sufficiently sophisticated bailiwick checking to learn all the A/AAAA records on the first query.

George

---

From: "George Barwood" <[email-masked]>
Date: Mon, 21 Feb 2011 20:30:10 -0000

----- Original Message ----- 
From: "Mark Andrews" <[email-masked]>
To: "George Barwood" <[email-masked]>
Cc: <[email-masked]>
Sent: Sunday, February 20, 2011 10:58 PM
Subject: Re: [dnsext] Failure to add glue MUST cause TC to be set.

> No. It is not a mis-configuration.

RFC1034 says

  To fix this problem, a zone contains "glue" RRs which are not
  part of the authoritative data, and are address RRs for the servers.
  These RRs are only necessary if the name server's name is "below" the
  cut, and are only used as part of a referral response.

The second sentence rules out the mutually recursive case ( very sensibly ).

My earlier post was posted early by mistake, I meant to say

<<
So something like

ZoneA.net. NS ns1.ZoneB.net.
ZoneA.net. NS ns2.ZoneB.net.

ZoneB.net. NS ns1.ZoneA.net.
ZoneB.net. NS ns2.ZoneA.net.

I think the idea of supporting this kind of mutually recursive setup is bad.

Such zones may not be portable to a different authoritative server ( an implementation might
well choose to only accept and/or serve in-zone glue ).

And recursive resolvers with simple Bailiwick checking, or simple rules for what records
to accept from the additional section (only in-zone glue) will loop.

I'm opposed to extending the standard in this way ( of course you might dispute that it does extend
the standard, but that's my reading of the RFC1034 text above ).

George

---

From: Mark Andrews <[email-masked]>
Date: Tue, 22 Feb 2011 09:06:45 +1100

> The second sentence rules out the mutually recursive case ( very sensibly ).

No.  It just means that they failed to fully analyse the problem.

If they wanted to prevent the mutually recursive case there would
have been words to outlaw it or warn of it.  RFC 1034 contains lots
of errors this is just another one.

Mark

---

From: "George Barwood" <[email-masked]>
Date: Tue, 22 Feb 2011 08:48:06 -0000

----- Original Message ----- 
From: "Mark Andrews" <[email-masked]>
To: "George Barwood" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, February 21, 2011 10:06 PM
Subject: Re: [dnsext] Failure to add glue MUST cause TC to be set.

> No.  It just means that they failed to fully analyse the problem.

That's possible. Or they may have fully understood and chosen this form of words
to rule out the mutually recursive case in a subtle way.

I think the other possibility is they were viewing it from an operators point of view.
They were saying "this is all you need". RFC1033 has similar language.

Regardless, the RFC does not deal with this case, so it's best to avoid it.
My resolver rejects all glue that is not in-zone, and in several years of use I have not seen a problem,
so it seems that this technique is not in widespread use.

> of errors this is just another one.

I don't think you can call it an error. It is an ambiguity / omission.

Anyway, regardless, to come back to the original suggestion on when glue is essential.
If you want to support this extended form of glue, then such glue records must be included
in a referral, with TC set if there is no room. "Conventional" (in-zone) glue records can
be omitted (to avoid truncation) unless they match QNAME/QTYPE.
This rule avoids TCP fallback in common non-DNSSEC cases.

George

---

From: Joe Abley <[email-masked]>
Date: Wed, 23 Feb 2011 08:53:45 -0500

> org and info share name servers, but they each have 4 "in-zone" name server names below the cut.

No, ORG and INFO do not share nameservers.

Joe