WG Agenda for RIPE50
The WG Agenda for RIPE50 is now being compiled. Please send details of any suggestions or contributions to the WG chairs: dns-wg-chair@ripe.net. Thanks. Note that a new structure for RIPE meetings will be tried in Stockholm. Reports from other meetings -- eg IETF, CENTR -- are supposed to now go in the extended plenary at the start of the week. Detailed technical and policy discussions are intended for the WG sessions at the end of the week. At this time it's too early to say when the WG will meet and for how long. The meeting plan won't be finalised until there's a better idea of what's on the agendas of each WG. So it will help us to help you by letting us know what should be on the WG agenda in Stockholm.
There's an item on the agenda that I'd like to potentially add to... # H. Using In-Bailiwick Nameservers in .ARPA: # Improving Reverse DNS Lookup Performance # Masato Minda, JPRS # # In June 2004, the JP TLD carried out a change in handling of the way glue # records. Although this change was technically correct, some domains # encountered difficulties in name resolution. # # This presentation explains the problem with old BIND implementations and # suggests recommended way to configure nameservers in .ARPA domain. This # configuration of DNS will improve reverse DNS lookup performance. I have seen this presentation in January at a NANOG (or at least an earlier version of it) and commented then that there is some good reason for this, even if it costs the RIRs the need to support glue data. For one - it makes the reverse map lookup path a bit more direct. However, the benefit isn't overwhelming because of short cuts taken when looking up the "slash-8".in-addr.arpa zones. E.g., if you tcpdump the DNS queries from an empty caching server, you might see this when you omit repeated queries, formerr's, etc: dig +norec -x 209.173.57.182 @l.root-servers.net dig +norec chia.arin.net @i.root-servers.net dig +norec chia.arin.net @i.gtld-servers.net The first is the query, with a referral to the 209.in-addr.arpa zone. The second is the attempt to get the address for chia, one of the servers. The third is a query to .net, and you get back a hybrid answer... ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8051 ;; flags: qr; QUERY: 1, ANSWER: 1, AUTHORITY: 8, ADDITIONAL: 8 ;; QUESTION SECTION: ;chia.arin.net. IN A ;; ANSWER SECTION: chia.arin.net. 172800 IN A 192.5.6.32 ;; AUTHORITY SECTION: the rest is a normal referral... This is a good crutch - and is a counter to "in-baliwick" server requirements. This crutch comes at a price though - the A record here is obtained from the host objects registered, not via DNS. (It looks like a cached answer, but it's not really.) That's all good, no "flash point problem." Until we get to DNSSEC though. This answer will be RRSIG-less. I suspect that this might become an issue. Maybe? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying.
On Thu, 5 May 2005, Edward Lewis wrote:
There's an item on the agenda that I'd like to potentially add to...
<snip>
The third is a query to .net, and you get back a hybrid answer...
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8051 ;; flags: qr; QUERY: 1, ANSWER: 1, AUTHORITY: 8, ADDITIONAL: 8 ;; QUESTION SECTION: ;chia.arin.net. IN A ;; ANSWER SECTION: chia.arin.net. 172800 IN A 192.5.6.32 ;; AUTHORITY SECTION: the rest is a normal referral...
This is a good crutch - and is a counter to "in-baliwick" server requirements. This crutch comes at a price though - the A record here is obtained from the host objects registered, not via DNS. (It looks like a cached answer, but it's not really.)
That's all good, no "flash point problem."
Until we get to DNSSEC though. This answer will be RRSIG-less. I suspect that this might become an issue. Maybe?
It will become an issue, unless resolvers understand that referrals with glue in answer section are exactly that: referrals, and not answers. Roy
On Thu, 5 May 2005, Roy Arends wrote:
On Thu, 5 May 2005, Edward Lewis wrote:
There's an item on the agenda that I'd like to potentially add to...
<snip>
The third is a query to .net, and you get back a hybrid answer...
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8051 ;; flags: qr; QUERY: 1, ANSWER: 1, AUTHORITY: 8, ADDITIONAL: 8 ;; QUESTION SECTION: ;chia.arin.net. IN A ;; ANSWER SECTION: chia.arin.net. 172800 IN A 192.5.6.32 ;; AUTHORITY SECTION: the rest is a normal referral...
This is a good crutch - and is a counter to "in-baliwick" server requirements. This crutch comes at a price though - the A record here is obtained from the host objects registered, not via DNS. (It looks like a cached answer, but it's not really.)
That's all good, no "flash point problem."
Until we get to DNSSEC though. This answer will be RRSIG-less. I suspect that this might become an issue. Maybe?
It will become an issue, unless resolvers understand that referrals with glue in answer section are exactly that: referrals, and not answers.
Might be a topic for ietf dnsop or dnsext: Convince authoritative name server vendors to put glue where glue belongs: additional section. There is also the problem of combined server-resolver installations, that have out-of-bailiwick glue cached, and respond with that glue in the answer section. Roy
Roy Arends wrote:
Convince authoritative name server vendors to put glue where glue belongs: additional section.
There is also the problem of combined server-resolver installations, that have out-of-bailiwick glue cached, and respond with that glue in the answer section.
if it originates from the cache, it's not glue. Glue is what is maintained in the context of the delegating zone. Apart from that: yes. -Peter
On Thu, 5 May 2005, Peter Koch wrote:
Roy Arends wrote:
Convince authoritative name server vendors to put glue where glue belongs: additional section.
There is also the problem of combined server-resolver installations, that have out-of-bailiwick glue cached, and respond with that glue in the answer section.
if it originates from the cache, it's not glue. Glue is what is maintained in the context of the delegating zone. Apart from that: yes.
concur roy
On Thu, 5 May 2005, Roy Arends wrote:
There is also the problem of combined server-resolver installations, that have out-of-bailiwick glue cached, and respond with that glue in the answer section.
<proto police hat on> There is no such thing as in-bailiwick glue or out of bailiwick glue. The term "GLUE RECORDS" is defined in rfc-1033 (yeah, dusted off): If the name server host for a particular domain is itself inside the domain, then a 'glue' record will be needed. A glue record is an A (address) RR that specifies the address of the server. Glue records are only needed in the server delegating the domain, not in the domain itself. in-bailiwick glue is a pleonasm while out-of-bailiwick glue is an oxymoron. <proto police hat off> Roy
At 17:18 +0200 5/5/05, Roy Arends wrote:
<proto police hat on>
Before this spins into a debate on the correctness of the answers (I privately label them "hybrid" cache/referrals), I want to make two points: 1) This action may or may not be completely compliant with the protocol but it has been an operational boon. Don't get me wrong - the messages are valid with respect to the protocol. The way in which the data is obtained may not be what is expected, but is fully compliant with the protocol. I.e., the answer comes back with the AA bit off and the RA bit is also off. DNS does not define what that "means" - it could be that the server is recursive, but recursion is not available to the querier. (It could be ACL'd out by IP address, for example.) Defining the answers as "in-baliwick" is hard. The servers in this example are authoritative for .com and .net. To the server, the baliwick is any domain under .com and .net, regardless of the query. OTOH, the only queries that fall into this category are asking for names in .com and .net. I.e., you don't see a .biz name here - for many reasons. Keep in mind that just because the IETF has defined it, doesn't mean it's operationally valid. The IETF tries, but sometimes misses the mark. Without this crutch, no BIND prior to 8.something would have worked (getting lost in reverse map queries) and the number of queries sent would have been much higher. 2) This is another case of DNSSEC exposing corner cases that DNS was able to live with. Like "* NS", until DNSSEC, these cases could exist without heartburn, but when push comes to shove in the "signed by the authorized party" era, we find that these cases exist. ("* DNAME" isn't in this category for other reasons, even in non DNSSEC is causes heartburn. Sorry - that's a different discussion on another list.) I may be painting this scenario in an unfair light calling it a "corner case" but it qualifies because this is "ersatz caching." It works now because as long as the host objects are in line with what's really in DNS, it's okay. Problems don't pop up until the DNS is changed and the registration isn't. This will happen when the zone gets signed. Retrieval of the RRSIG's for all registered host objects is probably not going to happen. I'm sure there is a way "out" of this. For one, without DNSSEC, the answer coming from a non-authoritative server is lower in credibility than an answer from an authoritative one. Perhaps a validator can recognize hybrid answers and realize not to "panic" when it lacks the RRSIG, instead "following" the referral half of the message. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying.
Roy Arends wrote:
<proto police hat on>
<protopolice division="internal affairs">
There is no such thing as in-bailiwick glue or out of bailiwick glue.
The term "GLUE RECORDS" is defined in rfc-1033 (yeah, dusted off):
That's probably using illegal evidence, 1033 has no formal status. </protopolice>
If the name server host for a particular domain is itself inside the domain, then a 'glue' record will be needed. A glue record is an A (address) RR that specifies the address of the server. Glue records are only needed in the server delegating the domain, not in the domain itself.
in-bailiwick glue is a pleonasm while out-of-bailiwick glue is an oxymoron.
There are different glue policies in place. DE is using a strict one (matching your definition above), while COM/NET apply a less strict (in fact IIRC even a combined one). The paragraph cited above is correct, but it doesn't limit glue to that case. But this is all only about differentiating between servers below the delegating or the delegated domain. The presentation is in fact about "trustworthy additional information". But let's wait until tomorrow ... -Peter
participants (4)
-
Edward Lewis -
Jim Reid -
Peter Koch -
Roy Arends