RIPE's MNAME recommendation
Hello dns-wg list! SUMMARY: In short, in a SOA RR of ours we have an MNAME that corresponds to a primary master server which has a private IP address. This is causing problems with many RIPE member registrars. PROBLEM: Using the language described in Section 2.1 of [RFC 1996], we have a primary master DNS server and two slave DNS servers. The primary master has a private [RFC 1918] IP address and the Slaves have public IP address, are named in the NS RRs for the zone and use zone transfer to recieve the zone from the primary master. Furthermore, in accordance with [RFC 1996], [RPC 1035] and [RIPE1] I have named the primary master as the original/primary source of the data for the zone. Here is an example zone file from what I'm talking about: example.com. 3600 SOA dns.private.example.com. hostmaster.example.com. ( 1999022301 ; serial YYYYMMDDnn 86400 ; refresh ( 24 hours) 7200 ; retry ( 2 hours) 3600000 ; expire (1000 hours) 172800 ) ; minimum ( 2 days) NS slave1.example.com. NS slave2.example.com. slave1 A {public-ip} slave2 A {public-ip} dns.private A 10.11.12.13 So far so good. Our zone appears to be fully RFC compliant. However, the problem arises when I try to transfer, say, the ownership of a ".de" zone using DENIC, because [RIPE1] additionally recommends that this be a valid address of the primary master, "valid" being the key word here. This is a problem, because many RIPE member registrars are indeed enforcing this policy. I gather, however, from more recent messages from Mr. Koch (who authored [RIPE1]), that the "MNAME field need not be part of the NS RRSet and need not be accessible." [ICANN-FORUM]. BTW, to my knowledge this is also neither enforced by IANA nor ICANN. Is it possible that RIPE could consider relaxing this "recommendation" that causes problems for RFC compliant zones? How do you, the DNS community, feel about this? Thank you for your attention in this matter. With kindest regards, Paul Herman Network Architect cleverbrige AG www.cleverbridge.com REFERENCES: ---------- [RFC 1035] Mockapetris,P., "Domain Names - Implementation and Specification", RFC 1035, STD 13, November 1987 [RFC 1918] Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot, E. Lear. "Address Allocation for Private Internets." February 1996 [RFC 1996] Vixie,P., "A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)", RFC 1996, August 1996 [ICANN-FORUM] http://forum.icann.org/lists/iana-del-data-comments/msg00004.html [RIPE1] Koch,P., "Recommendations for DNS SOA Values", ripe-203, http://www.ripe.net/ripe/docs/ripe-203.html , June 1999
--On den 30 september 2005 13.19.41 +0200 Paul Herman <pherman@cleverbridge.com> wrote:
Hello dns-wg list!
SUMMARY: In short, in a SOA RR of ours we have an MNAME that corresponds to a primary master server which has a private IP address. This is causing problems with many RIPE member registrars.
Is it possible that RIPE could consider relaxing this "recommendation" that causes problems for RFC compliant zones? How do you, the DNS community, feel about this?
I think not. The collateral damage of allowing this relaxation when applied to another organisation, where there are slave servers that might not be in the same routing domain[0] as the MNAME box (and thus not able to see the RFC 1918 address, because 1918 says those addresses should stay in one routing domain) would be un-nice. Basically, using RFC 1918 address space for central, critical infrastructure that might get connections from arbitrary places on the net is a bad idea. Allowing it in a policy document is even worse. -- Måns Nilsson Systems Specialist +46 70 681 7204 cell KTHNOC +46 8 790 6518 office MN1334-RIPE [0] Many texts, ripe-192 being one of the more well-written ones, explicitly talk about getting secondaries in Other Places(tm), which means that you probably, as a slave, are not seeing the same 192.168.47.11 as the other servers, if the MNAME resolves to a RFC 1918 address. This also is messy with dynamic updates.
On Sep 30, 2005, at 12:19, Paul Herman wrote:
In a SOA RR of ours we have an MNAME that corresponds to a primary master server which has a private IP address. This is causing problems with many RIPE member registrars.
the problem arises when I try to transfer, say, the ownership of a ".de" zone using DENIC, because [RIPE1] additionally recommends that this be a valid address of the primary master, "valid" being the key word here. This is a problem, because many RIPE member registrars are indeed enforcing this policy.
I gather, however, from more recent messages from Mr. Koch (who authored [RIPE1]), that the "MNAME field need not be part of the NS RRSet and need not be accessible." [ICANN-FORUM]. BTW, to my knowledge this is also neither enforced by IANA nor ICANN.
Is it possible that RIPE could consider relaxing this "recommendation" that causes problems for RFC compliant zones?
Have you looked at the agenda for the DNS WG at the upcoming RIPE meeting? This includes a discussion on updating RIPE document 203: "Recommendations on SOA values". Perhaps you could make your views known then? Or, if the WG decides to update 203, you could contribute to that effort? Please bear in mind too that 203 was published in 1999 and stealth master servers were not as common then as they are today. I am confused about your reference to "this policy". There is no RIPE- wide policy on SOA values as far as I know. RIPE document 203 is a recommendation, that's all. Of course everyone is free to use 203 (or ignore it) as guidance when forming their own local policies and procedures. So if you are having problems because of such a policy, I think it's best if you raise the issue with those who have applied that policy. Asking the WG to revisit 203 is all very well. In fact it looks as though that's already in hand. But you may still have to persuade the local policy-makers to change things if/when a revised version of 203 is produced. In short, "fixing" 203 could still mean the policies at those registrars would have to be changed. They might not even know or care about the new document.
On Fri, 30 Sep 2005, Paul Herman wrote:
Hello dns-wg list!
SUMMARY: In short, in a SOA RR of ours we have an MNAME that corresponds to a primary master server which has a private IP address. This is causing problems with many RIPE member registrars.
PROBLEM: Using the language described in Section 2.1 of [RFC 1996], we have a primary master DNS server and two slave DNS servers. The primary master has a private [RFC 1918] IP address and the Slaves have public IP address, are named in the NS RRs for the zone and use zone transfer to recieve the zone from the primary master. Furthermore, in accordance with [RFC 1996], [RPC 1035] and [RIPE1] I have named the primary master as the original/primary source of the data for the zone. Here is an example zone file from what I'm talking about:
example.com. 3600 SOA dns.private.example.com. hostmaster.example.com. ( 1999022301 ; serial YYYYMMDDnn 86400 ; refresh ( 24 hours) 7200 ; retry ( 2 hours) 3600000 ; expire (1000 hours) 172800 ) ; minimum ( 2 days) NS slave1.example.com. NS slave2.example.com. slave1 A {public-ip} slave2 A {public-ip} dns.private A 10.11.12.13
So far so good. Our zone appears to be fully RFC compliant. However, the problem arises when I try to transfer, say, the ownership of a ".de" zone using DENIC, because [RIPE1] additionally recommends that this be a valid address of the primary master, "valid" being the key word here. This is a problem, because many RIPE member registrars are indeed enforcing this policy.
I gather, however, from more recent messages from Mr. Koch (who authored [RIPE1]), that the "MNAME field need not be part of the NS RRSet and need not be accessible." [ICANN-FORUM]. BTW, to my knowledge this is also neither enforced by IANA nor ICANN.
Is it possible that RIPE could consider relaxing this "recommendation" that causes problems for RFC compliant zones? How do you, the DNS community, feel about this?
Thank you for your attention in this matter.
What the recommendation [ripe-203] says, is: (1) The DNS specification explicitly states that the primary master server be named here. (2) The value must be determined and used. ad (2) I have no idea what this means. (3) Especially it is a mistake to repeat the zone name here, unless this also leads to a valid address of the primary master. ad (3) The terms 'valid' and 'leads' are subject to broad interpretation. Does 'valid' mean 'reachable', does 'leads' mean 'globally resolvable' ? I think this is trying to reflect rfc2181, section 7.3. But, also this section does not reveal why this is a mistake. IIRC, the MNAME field is used in two parts of the DNS protocol, notify and dynamic update. For notify, the primary master determines the recipients of a notify message by determining the nameservers of the zone (the NS set in the apex) minus the name of the primary master (determined by the mname field). It does not have any impact to have a private space address for a host specified in the MNAME field, since it would not receive a notify message. For dynamic update, the requestor determines the recipient of a dynamic update message by sending it first to address of the host in the MNAME field to avoid unnecessary forwarding in slave servers, and, if that fails, try the other servers. So, if this is a zone that contains addresses of hosts, where the hosts are trying to dynamically update their addresses (or other data), you might see updates directed to the host in the MNAME field. If this, from the dyn.update host view, is not a reachable address, it will try the slave servers. I do not know if there are any other uses of the SOA MNAME field, or what future uses might be. I do not know how 'stuff breaks' by having a private space address for the host listed in the SOA MNAME field. I would, in general, try to avoid leakage of private space addresses in any way, shape or form, since I don't know what other uses of the MNAME are. But, using this recommendation as a policy and bluntly forcing it onto others, without a good explanation of why, is not a good thing. Roy
All the words were written before hidden masters were necessary or invented. Whether SOAs are used to determine recipients of NOTIFY is a local matter. I do not think there need to be standards or recommendataions about that. So the recommendation should be to put into the MNAME field the domain name of an authoritative name server that allows AXFRs and is the intended target for dynamic updates. The difficult question is what to put there if there is no such server. It is perfectly OK to not use or allow AXFR and not to use dynamic updates. I have no bright ideas here. But what should be recognised is that there may be no such server. Daniel
On Fri, 30 Sep 2005, Daniel Karrenberg wrote:
So the recommendation should be to put into the MNAME field the domain name of an authoritative name server that allows AXFRs and is the intended target for dynamic updates.
Going back to the original poster's question, Registrars (whether RIPE members or not), imho, should only be checking that the MNAME field is syntactically correct, not whether it represents a reachable host. Of course, there is nothing stopping the Registrant from temporarily changing the MNAME field to point to something 'valid' whilst interacting with the Registrar, and to put it back to their Registrar-invalid version afterwards. Apart from that, RIPE-203 is still good advice. -- Bruce Campbell
On Sep 30, 2005, at 17:24, Daniel Karrenberg wrote:
All the words were written before hidden masters were necessary or invented.
Whether SOAs are used to determine recipients of NOTIFY is a local matter. I do not think there need to be standards or recommendataions about that.
So the recommendation should be to put into the MNAME field the domain name of an authoritative name server that allows AXFRs and is the intended target for dynamic updates. The difficult question is what to put there if there is no such server. It is perfectly OK to not use or allow AXFR and not to use dynamic updates.
I have no bright ideas here. But what should be recognised is that there may be no such server.
As said on this list earlier, the fact is that software deployed do use the MNAME field to try to do dynamic update to and other kind of access. Because of this, for me the MNAME field is in reality a field of data that helps leakage of RFC 1918 addresses if the hostname in MNAME is having such an IP address. This in turn forces to fall under the category of "things that should not have RFC 1918 data". The question is then, as Daniel says, what to put in the MNAME field, as we have conflicting requirements. That it lists the hostname that is the primary master, and that it should not expose RFC 1918 addresses. My suggestion would be to put a domain name there in the domain that hosts the domain, a hostname that can receive the traffic generated by any tool that uses the mname in the SOA for something. Patrik
--On den 1 oktober 2005 12.40.09 +0200 Patrik Fältström <paf@cisco.com> wrote:
My suggestion would be to put a domain name there in the domain that hosts the domain, a hostname that can receive the traffic generated by any tool that uses the mname in the SOA for something.
In the interest of sanity, I'd suggest adding "should answer queries about said domain with the AA bit set" (in addition to swallowing/properly rejecting/processing updates and allowing/properly refusing zone transfers). That is the The Right Thing to do, IMHO, but it might be hard to get that kind of enforcement into any kind of document short of an ops memo inside one organisation. I for one require it for anything I operate. -- Måns Nilsson Systems Specialist +46 70 681 7204 cell KTHNOC +46 8 790 6518 office MN1334-RIPE
On Sat, Oct 01, 2005 at 01:49:30PM +0200, MÃ¥ns Nilsson wrote:
In the interest of sanity, I'd suggest adding "should answer queries about said domain with the AA bit set" (in addition to swallowing/properly rejecting/processing updates and allowing/properly refusing zone transfers). That is the The Right Thing to do, IMHO, but it might be hard
There's no RFC that would support this as far as I can see. At least there's no RFC that suggests that the server named in MNAME act as an additional resource to what is already in the NS RRSet. When RIPE-203 was written, NOTIFY was pretty much in use and that's what the recommendation is mostly based on. At that time some DNS server or admin tool defaulted to the zone name for MNAME and since even NOTIFY doesn't fail if you do not enter the primary master (or the root of the XFR dependency graph, as RFC 1996 puts it), people just accepted that "default" not knowing that it really needed editing. NOTIFY's MNAME use affects the secondaries and the primary master in that it limits the amount of notifications sent and tries to avoid any NOTIFYs going back to the primary master. It may also affect query load when servers do SOA additional section processing (contrary to the words in RFC 1035). At the same time, Dynamic Updates were in far less use, at least far less than today thanks to a prominent OS. Dynamic Update traffic affects more parties and sometimes is so dominant, that the MNAME is used as a dedicated "DunUpd target", e.g. by AS112. Strictly speaking, RFC 2136 only suggests to target MNAME if the name appears in the NS RRSet, but current reality is different. None of the above says or suggests that the server in MNAME be used for DNS queries from random sources or that it should serve the zone via XFR. Then, RIPE-203 explicitly targets "small and stable zones", which are more or less by definition not subject to dynamic updates (if, for a moment, we associate "dynamic updates" with "frequent updates"/DHCP; if DynUpd is used as a provisioning tool by the zone maintainer, it likely can get away even without the SOA info). So, my suggestion is to adjust the MNAME text in a way that keeps the original spirit but explicitly says that the name in MNAME 1) must resolve to an A RR(Set) 2) the address (or, to complicate matters, addresses) must be the public address of the (hidden/stealth) primary master Please remember that RIPE-203 does not try to be an exhaustive (even less so normative) explanation for all the SOA RR's parameters for most any situation. It aims at a rather large subset (maybe in the 70-80%) of zones which can live well with these defaults. -Peter
In your previous mail you wrote: So, my suggestion is to adjust the MNAME text in a way that keeps the original spirit but explicitly says that the name in MNAME 1) must resolve to an A RR(Set) => A and/or AAAA 2) the address (or, to complicate matters, addresses) must be the public address of the (hidden/stealth) primary master => I support Peter's proposal. Thanks Francis.Dupont@enst-bretagne.fr
--On den 3 oktober 2005 17.10.53 +0200 Peter Koch <pk@DENIC.DE> wrote:
In the interest of sanity, I'd suggest adding "should answer queries about said domain with the AA bit set" (in addition to swallowing/properly rejecting/processing updates and allowing/properly refusing zone transfers). That is the The Right Thing to do, IMHO,
There's no RFC that would support this as far as I can see. At least there's no RFC that suggests that the server named in MNAME act as an additional resource to what is already in the NS RRSet.
1035 says: MNAME The <domain-name> of the name server that was the original or primary source of data for this zone. I think this is supportive of the idea that questions about the zone SHOULD be answered, and that AA bit SHOULD be set.
So, my suggestion is to adjust the MNAME text in a way that keeps the original spirit but explicitly says that the name in MNAME
1) must resolve to an A RR(Set) 2) the address (or, to complicate matters, addresses) must be the public address of the (hidden/stealth) primary master
...and thus as per above SHOULD do dns? I think there is support in the text for that.
Please remember that RIPE-203 does not try to be an exhaustive (even less so normative) explanation for all the SOA RR's parameters for most any situation. It aims at a rather large subset (maybe in the 70-80%) of zones which can live well with these defaults.
Understood. -- Måns Nilsson Systems Specialist +46 70 681 7204 cell KTHNOC +46 8 790 6518 office MN1334-RIPE
On Tue, Oct 04, 2005 at 09:12:40AM +0200, MÃ¥ns Nilsson wrote:
1035 says:
MNAME The <domain-name> of the name server that was the original or primary source of data for this zone.
I think this is supportive of the idea that questions about the zone SHOULD be answered, and that AA bit SHOULD be set.
"primary" source I'd not read as the "source that's mostly asked", but in the sense the word is used in "primary master". To comply with the above definition, it's sufficient to supply the zone to at least one secondary (ususally by AXFR). So even when 1035 was not explicitly designed to support hidden primaries, it is flexible enough to allow for them. The update to 1035 in RFC 1996 makes this even clearer. -Peter
[Just replying to some random message in the thread] Excellent discussion, and I'm grateful for everyone's contribution. Two points have essentially been brought up in this thread: 1) private MNAMEs lead to RFC 1918 pollution and 2) RIPE-203 is not policy but just a recommendation. Many people commented that if the MNAME server points to a private RFC 1918 A RR then this contributes exposure of the RFC 1918 address space to the rest of the internet. While this statement is true, it is important to note that RFC 1918 pollution exists IFF the zone exposes RFC 1918 addresses via A, PTR (or AAAA?) RRs and not MNAME entries as some suggested. In fact, it surprised me that RFC 1918 addresses became such an issue in this thread, because MNAME doesn't point to an address, only a machine domain name. I am more concerned with whether MNAMEs should be required to resolve, and not what they should resolve to. ...(Appologies offered for the oversimplified "example.com" zone I presented in my original post. It is not a real zone of ours, and was merely intended to illustrate the structure of the the name server relationships. You can all rest assured that all querries to private RRs are answered only within our private network)... As to RIPE-203 being neither policy nor standard but simply a recommendation, I may have been unlucky but based upon this very MNAME issue I have had one zone flat rejected by two registrars and was told by another after some discussion quite authoritatively that although they would let it slide, DENIC wouldn't allow it and the same would go for any .CH or .AT domain. I'm currently batting 1 for 3 against. It's been my experience that the registrars typically run their web scripts on the zone and if it doesn't pass their test (which include the RIPE-203 recommendations), then your request is rejected. After you call them and finally reach someone who can help you, they point to RIPE-203, end of discussion. I have no problem trying to take this up with individual registrars but it feels like battling windmills. I have a stealth primary master with a private IP, no RFC 1918 address pollution and no dynamic updates configured for this zone at all. What is a sysadmin to do? Looking forward to what fruit the upcoming DNS WG will bear... Regards, Paul Herman Network Architect cleverbrige AG www.cleverbridge.com
On Tue, Oct 04, 2005 at 10:12:05AM +0200, Paul Herman wrote:
issue I have had one zone flat rejected by two registrars and was told by another after some discussion quite authoritatively that although they would let it slide, DENIC wouldn't allow it and the same would go for any .CH or .AT domain. I'm currently batting 1 for 3 against.
I'd recommend that for "authoritative" answers on registration policy the registry's documentation be consulted.
It's been my experience that the registrars typically run their web scripts on the zone and if it doesn't pass their test (which include the RIPE-203 recommendations), then your request is rejected. After
If that were the case it would be ill-advised. RIPE-203 clearly states its target audience *and* intentionally does not offer any intervals but instead recommends fixed values for the various SOA fields. I'm not aware of a registry that would insist on fixed particular numbers here.
you call them and finally reach someone who can help you, they point to RIPE-203, end of discussion. I have no problem trying to take this up with individual registrars but it feels like battling windmills. I
Let's please keep two issues separate: 1) potential updates to RIPE-203 due to ambuguity or changed premises 2) alleged or evidenced use of RIPE-203 as a basis for policy or policy enforcement You see to have run into a problem with (2), but that does not necessarily call for a change to RIPE-203.
have a stealth primary master with a private IP, no RFC 1918 address pollution and no dynamic updates configured for this zone at all. What is a sysadmin to do?
Pick one of the announced name servers? -Peter
Peter Koch wrote:
So, my suggestion is to adjust the MNAME text in a way that keeps the original spirit but explicitly says that the name in MNAME
1) must resolve to an A RR(Set) 2) the address (or, to complicate matters, addresses) must be the public address of the (hidden/stealth) primary master
I am curious as to what the purpose of this text would be. If that field is used for either notify or dynamic update (as Roy pointed out earlier in the thread) those are both issues that are relevant only to the operators of the name servers and/or the domain administrators in question. The AXFR issue that Daniel mentioned is also a matter of local policy. In short, without significant good reasons to the contrary (with supporting information and references included in the document), I think if 203 says anything about it at all, it should say only that what goes into that field is a matter of local policy. If the thinking on this topic is being guided by (now stale) RFC statements on this topic, it would probably be useful to consider a document in the IETF process to update this. I would also like to point out that there is an alternative that I haven't seen mentioned to having the MNAME be either a publicly routable or private address. Back when I was managing DNS for a living, I used to create a hostname called hidden-master.example.com, and have that host resolve to 127.0.0.1. That neatly solved many problems, including the overwhelming flood of traffic we were seeing on the (valid) server name that used to be listed in the MNAME field from Windows clients trying to do spurious dynamic updates. I tested this before we deployed it, and it doesn't harm the Windows clients, and it solved our problem. The only time that we had trouble with this was when we would attempt to register country-code domains at certain registries with this configuration. As long as we're talking about updating 203, I'd also like to take this opportunity to point out that the current discussion highlights some of the problems with documents of this type, namely that they are generally out of date within minutes of being published. For example, the recommendation for the MINIMUM field is woefully out of date (as I'm sure is not a surprise to most members of this list). I would also argue that the recommendations for refresh, retry, and expire are only applicable to a fairly narrow part of the bell shaped curve of DNS administration, and should not be adopted blindly without good understanding of both the needs of the domain administrators and how those values interact. I think that a lot of this information was useful at the time it was published, but 6 years is loooong time in net.years. hope this helps, Doug -- If you're never wrong, you're not trying hard enough
On Oct 4, 2005, at 09:32, Doug Barton wrote:
As long as we're talking about updating 203, I'd also like to take this opportunity to point out that the current discussion highlights some of the problems with documents of this type, namely that they are generally out of date within minutes of being published.
Although this is a diversion from the original discussion, I think it's a worthwhile topic for the WG to consider. Maybe the WG could put expiry dates on its documents? ie "This document dies in X years unless it is reviewed and updated if necessary." I'm sure Peter would have made a mental note that 203 would need to be revisited some time after it came out. [Which will explain why it's on the agenda for next week. :-)] Perhaps that could/should be formalised somehow so that some of the WG agenda planning can be done on a longer-term basis?
On Fri, Sep 30, 2005 at 01:19:41PM +0200, Paul Herman wrote:
example.com. 3600 SOA dns.private.example.com.
[...]
NS slave1.example.com. NS slave2.example.com. slave1 A {public-ip} slave2 A {public-ip} dns.private A 10.11.12.13
So far so good. Our zone appears to be fully RFC compliant. However,
RFC 1918 says that you should not leak "private" IP addresses, including reference to those addresses in DNS RRs (last paragraph in section 3). The A RR at dns.private.example.com and the reference to that name in the SOA RR do not follow this guidance.
the problem arises when I try to transfer, say, the ownership of a ".de" zone using DENIC, because [RIPE1] additionally recommends that this be a valid address of the primary master, "valid" being the key word here. This is a problem, because many RIPE member registrars are indeed enforcing this policy.
I'm not sure I understand the problem here. What do those registrars "enforce" exactly? RIPE 203 addresses the MNAME field because it was (and maybe continues to be) a common mistake to just repeat the zone name in the MNAME field, where that name does not own any A (or maybe AAAA) RR. In retrospect I'd admit that "valid" is an ambiguous term. However, leaking private address space in DNS RRs, especially in situations where it might cause traffic to go to random targets is not a good idea even today IMHO. What error(?) message do those registrars send back? Note, also, that RIPE 203 is not a normative document but a recommendation for a specific type of zone that happens to appear rather often. Without seeing the policy that "enforces" RIPE 203 it is a bit hard to say whether or not that's a good idea.
I gather, however, from more recent messages from Mr. Koch (who authored [RIPE1]), that the "MNAME field need not be part of the NS RRSet and need not be accessible." [ICANN-FORUM]. BTW, to my knowledge this
There is no inconsistency between my comment in that forum and RIPE 203. Many DNS setups use stealth primaries and even if those accept and respond to NOTIFY and Dynamic Update messages, there's no rule that the system named in the MNAME field respond to DNS queries (unless it is also announced per an NS RR). The IANA procedures draft which this comment addressed could be read in a way that thet system in the MNAME field would also be checked for SOA values and consistency.
Is it possible that RIPE could consider relaxing this "recommendation" that causes problems for RFC compliant zones? How do you, the DNS community, feel about this?
First of all, RIPE 203 is up for review at the upcoming RIPE meeting, although for a different reason (the "minTTL" field values recommendations are most likely outdated due to the widespread deployment of negative caching). Then there seems to be a mixture of policies and references to normative and non-normative documents. If I understand you correctly some registrar refuses to deal with a zone where the MNAME field refers to a name that owns an A RR carrying an RFC 1918 address. Seems not too unreasonable to me. -Peter
On 30.09 13:19, Paul Herman wrote:
example.com. 3600 SOA dns.private.example.com. <======== ... dns.private A 10.11.12.13 <=======
So far so good. Our zone appears to be fully RFC compliant.
RFC1918: "Indirect references to such addresses should be contained within the enterprise. Prominent examples of such references are DNS Resource Records and other information referring to internal private addresses. In particular, Internet service providers should take measures to prevent such leakage." Daniel (who iremebers writing the words cited above)
Hi!
example.com. 3600 SOA dns.private.example.com.
[skip]
dns.private A 10.11.12.13
This is a problem. Why should not use VIEW mechanism in BIND or same in other DNS'es to make your 10.x.x.x visible only for your 10.x.x.x clients? By the way, it makes your network more secure. -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)
participants (11)
-
Bruce Campbell -
Daniel Karrenberg -
Doug Barton -
Francis Dupont -
Jim Reid -
Max Tulyev -
Måns Nilsson -
Patrik Fältström -
Paul Herman -
Peter Koch -
Roy Arends